推荐|最新 2024 年云原生Kubernetes 高级面试题大全（持续更新中）

selector:
matchLabels: #基于等值
app: nginx
matchExpressions: #基于集合
- {key: name,operator: In,values: [zhangsan,lisi]} #key、operator、values这三个字段是固定的
- {key: age,operator: Exists,values:} #如果指定为exists，那么values的值一定要为空。

题3：Kubernetes 如何实现集群管理？

在集群管理方面，Kubernetes将集群中的机器划分为一个Master节点和一群工作节点Node。其中，在Master节点运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager和kube-scheduler，这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理能力，并且都是全自动完成的。

题4：如何解释 kubernetes 架构组件之间的不同？

Kubernetes由两层组成：控制平面和数据平面。

控制平面是容器编排层包括：

1）控制集群的 Kubernetes 对象。

2）有关集群状态和配置的数据。

数据平面是处理数据请求的层，由控制平面管理。

题5：Kubernetes 中 kube-proxy 有什么作用？

kube-proxy运行在所有节点上，它监听apiserver中service和endpoint的变化情况，创建路由规则以提供服务IP和负载均衡功能。简单理解此进程是Service的透明代理兼负载均衡器，其核心功能是将到某个Service的访问请求转发到后端的多个Pod实例上。

题6：什么是 Pod？

Pod是最基本的Kubernetes对象。Pod由一组在集群中运行的容器组成。最常见的是，一个pod运行一个主容器。

题7：什么是 Kubelet？

这是一个代理服务，它在每个节点上运行，并使从服务器与主服务器通信。因此，Kubelet处理PodSpec中提供给它的容器的描述，并确保PodSpec中描述的容器运行正常。

题8：为什么需要 Kubernetes，它能做什么？

容器是打包和运行应用程序的好方式。在生产环境中，管理运行应用程序的容器，并确保不会停机。例如，如果一个容器发生故障，则需要启动另一个容器。如果系统处理此行为，会不会更容易？

这就是Kubernetes来解决这些问题的方法！Kubernetes提供了一个可弹性运行分布式系统的框架。Kubernetes可以解决扩展要求、故障转移、部署模式等。例如，Kubernetes可以轻松管理系统的Canary部署。

Kubernetes提供：

服务发现和负载均衡
Kubernetes可以使用DNS名称或自己的IP地址公开容器，如果进入容器的流量很大，Kubernetes可以负载均衡并分配网络流量，从而使部署稳定。

存储编排
Kubernetes支持自动挂载存储系统，例如本地存储、公共云提供商等。

自动部署和回滚
可以使用Kubernetes描述已部署容器的所需状态，它可以以受控的速率将实际状态更改为期望状态。例如，可以自动化Kubernetes来实现部署创建新容器，删除现有容器并将它们的所有资源用于新容器。

自动完成装箱计算
Kubernetes允许指定每个容器所需CPU和内存（RAM）。当容器指定了资源请求时，Kubernetes可以做出更好的决策来管理容器的资源。

自我修复
Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器，并且在准备好服务之前不将其通告给客户端。

密钥与配置管理
Kubernetes允许存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥。可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥。

题9：什么是容器编排？

容器编排是与运行容器相关的组件和流程的自动化。它包括诸如配置和调度容器、容器的可用性、容器之间的资源分配以及保护容器之间的交互等内容。

题10： daemonset、deployment、replication 之间有什么区别？

daemonset：确保您选择的所有节点都运行Pod的一个副本。

deployment：是Kubernetes中的一个资源对象，它为应用程序提供声明性更新。它管理Pod的调度和生命周期。它提供了几个管理Pod的关键特性，包括Pod健康检查、Pod滚动更新、回滚能力以及轻松水平扩展Pod的能力。

replication：指定应该在集群中运行多少个Pod的精确副本。它与deployment的不同之处在于它不提供pod健康检查，并且滚动更新过程不那么健壮。

题11：k8s-中镜像的下载策略是什么

可通过命令“kubectl explain pod.spec.containers”来查看imagePullPolicy这行的解释。

K8s的镜像下载策略有三种：Always、Never、IfNotPresent；

● Always：镜像标签为latest时，总是从指定的仓库中获取镜像；

● Never：禁止从仓库中下载镜像，也就是说只能使用本地镜像；

● IfNotPresent：仅当本地没有对应镜像时，才从目标仓库中下载。

● 默认的镜像下载策略是：当镜像标签是latest时，默认策略是Always；当镜像标签是自定义时(也就是标签不是latest)，那么默认策略是IfNotPresent。

题12：删除一个-pod-会发生什么事情

Kube-apiserver会接受到用户的删除指令，默认有30秒时间等待优雅退出，超过30秒会被标记为死亡状态，此时Pod的状态Terminating，kubelet看到pod标记为Terminating就开始了关闭Pod的工作；

关闭流程如下： 1、 pod从service的endpoint列表中被移除； 2、如果该pod定义了一个停止前的钩子，其会在pod内部被调用，停止钩子一般定义了如何优雅的结束进程； 3、进程被发送TERM信号（kill -14） 4、当超过优雅退出的时间后，Pod中的所有进程都会被发送SIGKILL信号（kill -9）

题13：简述-kubernetes-scheduler-作用及实现原理

Kubernetes Scheduler是负责Pod调度的进程(组件)，随着Kubernetes功能的不断增强和完善，Pod调度也变得越来越复杂。Kubernetes Scheduler内部实现机制也不断优化，从最初的两阶段调度机制(Predicates&Priorities)发展到后来的升级版调度框架，以满足负责的调度场景。

一、Scheduler调度流程

Kubernetes Scheduler在整个系统中承担了“承上启下”的重要功能，“承上”是指它负责接收Controller Manager创建新的Pod，为其安排一个目标Node；“启下”是指安置工作完成后，目标Node上的kubelet服务进程接管后续工作，负责Pod生命周期中的“下半生”。

Kubernetes Scheduler的作用是将待调度的Pod(API新创建的Pod、Controller Manager为补足副本而创建的Pod等)按照特定的调度算法和调度策略绑定(Binding)到集群中某个合适的Node上，并将绑定信息写入etcd中。在整个调度过程中涉及三个对象，分别是待调度Pod列表、可用Node列表以及调度算法和策略。就是通过调度算法和调度策略将待调度Pod列表中的每个Pod都从Node列表中选择一个最合适的Node。

目标节点上的kubelet通过API Server监听到Kubernetes Scheduler产生的Pod绑定事件，随后获取对应的Pod清单，下载Image镜像并启动容器。

Scheduler只与API Server交互，其输入和输出如下：

输入：待调度的Pod和全部计算节点的信息
输出：目标Pod要”安家“的最优节点(或者暂时不存在)。
旧版本的Kubernetes Scheduler的调度总体包括两个阶段：过滤(Filtering)+打分(Scoring)，随后就是绑定目标节点，完成调度。

过滤阶段，遍历所有目标Node，删选出符合要求的候选节点。在此阶段，Scheduler将所有不符合的Node过滤，只留下符合条件的候选节点。具体实现通过一系列的Filter对每个Node进行筛选，筛选完成后通常会有多个节点供调度，从而进入打分阶段；如果结果为空，则表示当前还没有符合条件的Node节点，Pod会维持在Pending状态。
打分阶段，在过滤阶段的基础上，采用优选策略(xxx Priorities)计算出每个候选节点的积分，积分最高者胜出，因为积分最高者表示最佳候选人。挑选最佳节点后，Scheduler会把目标Pod安置次节点上，调度完成。
在过滤阶段Predicates是一系列过滤器，每种过滤器都实现一种节点特征的监测。比如磁盘、主机、节点上的可用端口、节点标签、CPU和内存资源、服务亲和性。

在打分阶段Priorities则用来对满足条件的Node节点进行打分，常见的Priorities包含LeastRequestedPriority(选出资源消耗最小的节点)、BalanceResourceAllocation(选出资源使用率最均衡的节点)。将 Predicates和Priorities合并为Kubernetes Scheduling Policies。

题14：说一下-kubenetes-针对-pod-资源对象的健康监测机制

K8s中对于pod资源对象的健康状态检测，提供了三类probe（探针）来执行对pod的健康监测：
1） livenessProbe探针
可以根据用户自定义规则来判定pod是否健康，如果livenessProbe探针探测到容器不健康，则kubelet会根据其重启策略来决定是否重启，如果一个容器不包含livenessProbe探针，则kubelet会认为容器的livenessProbe探针的返回值永远成功。
2） ReadinessProbe探针
同样是可以根据用户自定义规则来判断pod是否健康，如果探测失败，控制器会将此pod从对应service的endpoint列表中移除，从此不再将任何请求调度到此Pod上，直到下次探测成功。
3） startupProbe探针
启动检查机制，应用一些启动缓慢的业务，避免业务长时间启动而被上面两类探针kill掉，这个问题也可以换另一种方式解决，就是定义上面两类探针机制时，初始化时间定义的长一些即可。
每种探测方法能支持以下几个相同的检查参数，用于设置控制检查时间：
initialDelaySeconds：初始第一次探测间隔，用于应用启动的时间，防止应用还没启动而健康检查失败
periodSeconds：检查间隔，多久执行probe检查，默认为10s；
timeoutSeconds：检查超时时长，探测应用timeout后为失败；
successThreshold：成功探测阈值，表示探测多少次为健康正常，默认探测1次。
上面两种探针都支持以下三种探测方法：
1）Exec：通过执行命令的方式来检查服务是否正常，比如使用cat命令查看pod中的某个重要配置文件是否存在，若存在，则表示pod健康。反之异常。
Exec探测方式的yaml文件语法如下：

在上面的配置文件中，探测机制为在容器运行5秒后，每隔五秒探测一次，如果cat命令返回的值为“0”，则表示健康，如果为非0，则表示异常。
2）Httpget：通过发送http/htps请求检查服务是否正常，返回的状态码为200-399则表示容器健康（注http get类似于命令curl -I）。
Httpget探测方式的yaml文件语法如下：

上述配置文件中，探测方式为项容器发送HTTP GET请求，请求的是8080端口下的healthz文件，返回任何大于或等于200且小于400的状态码表示成功。任何其他代码表示异常。
3）tcpSocket：通过容器的IP和Port执行TCP检查，如果能够建立TCP连接，则表明容器健康，这种方式与HTTPget的探测机制有些类似，tcpsocket健康检查适用于TCP业务。
tcpSocket探测方式的yaml文件语法如下：

在上述的yaml配置文件中，两类探针都使用了，在容器启动5秒后，kubelet将发送第一个readinessProbe探针，这将连接容器的8080端口，如果探测成功，则该pod为健康，十秒后，kubelet将进行第二次连接。
除了readinessProbe探针外，在容器启动15秒后，kubelet将发送第一个livenessProbe探针，仍然尝试连接容器的8080端口，如果连接失败，则重启容器。

题15：kubernetes-scheduler-使用哪两种算法将-pod-绑定到-worker-节点

Kubernetes Scheduler根据如下两种调度算法将 Pod 绑定到最合适的工作节点：
预选（Predicates）：输入是所有节点，输出是满足预选条件的节点。kube-scheduler根据预选策略过滤掉不满足策略的Nodes。如果某节点的资源不足或者不满足预选策略的条件则无法通过预选。如“Node的label必须与Pod的Selector一致”。
优选（Priorities）：输入是预选阶段筛选出的节点，优选会根据优先策略为通过预选的Nodes进行打分排名，选择得分最高的Node。例如，资源越富裕、负载越小的Node可能具有越高的排名。我推荐你去看看时速云，他们是一家全栈云原生技术服务提供商，提供云原生应用及数据平台产品，其中涵盖容器云PaaS、DevOps、微服务治理、服务网格、API网关等。

16.kubernetes是什么

kubernetes，简称K8s，是用8代替名字中间的8个字符“ubernete”而成的缩写。是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效（powerful）,Kubernetes提供了应用部署，规划，更新，维护的一种机制。 [1]

A：Kubernetes 提供了很多的功能，它可以简化应用程序的工作流，加快开发速度。通常，一个成功的应用编排系统需要有较强的自动化能力，这也是为什么 Kubernetes 被设计作为构建组件和工具的生态系统平台，以便更轻松地部署、扩展和管理应用程序。用户可以使用 Label 以自己的方式组织管理资源，还可以使用 Annotation 来自定义资源的描述信息，比如为管理工具提供状态检查等。此外，Kubernetes 控制器也是构建在跟开发人员和用户使用的相同的 API 之上。用户可以编写自己的控制器和调度器，也可以通过各种插件机制扩展系统的功能。这种设计使得用户可以方便地在 Kubernetes 之上构建各种应用系统。

题17：kubernetes不是什么

A：Kubernetes 不是一个传统意义上，包罗万象的 PaaS（平台即服务）系统。它给用户预留了选择的自由。

不限制支持的应用程序类型，它不插手应用程序框架, 也不限制支持的语言（如 Java、Python、Ruby 等），Kubernetes 旨在支持极其多样化的工作负载，包括无状态、有状态和数据处理工作负载。只要应用可以在容器中运行，那么它就可以很好地在 Kubernetes 上运行。

不提供内置的中间件（如消息中间件）、数据处理框架（如 Spark）、数据库（如 MySQL）或集群存储系统（如 Ceph）等。这些应用直接运行在 Kubernetes 之上。

不提供点击即部署的服务市场。

不直接部署代码，也不会构建用户的应用程序，但用户可以在 Kubernetes 之上构建需要的持续集成（CI）工作流。

允许用户选择自己的日志、监控和告警系统。

不提供应用程序配置语言或系统（如 jsonnet）。

不提供机器配置、维护、管理或自愈系统。

题18：什么是-sidecar-容器使用它做什么

Sidecar 是什么
将本将属于应用程序的功能拆分成单独的进程，这个进程可以被理解为Sidecar。在微服务体系内，将集成在应用内的微服务功能剥离到了sidecar内，sidecar提供了微服务发现、注册，服务调用，应用认证，限速等功能。

特点:

Sidecar为独立部署的进程。
sidecar降低应用程序代码和底层代码的耦合度，帮助异构服务通过sidecar快速接入微服务体系。
Sidecar 如何工作
接下来以异构服务为基础介绍sidecar如何工作。

Sidecar 代理服务注册发现
下图为异构服务通过sidecar接入注册中心。异构服务本身可能为非Java或传统应用，接入困难。

异构服务本身不会和注册中心有请求调用，而是通过sidecar代理注册接入注册中心，获得服务注册、发现等功能。

Sidecar 代理异构服务发起服务调用
异构服务本身不和注册中心有直接联系，所以异构服务的调用也需要走sidecar，通过sidecar进行服务发现调用，sidecar收到异构服务的请求后通过服务发现和负载均衡选中目标服务实例，转发请求至目标服务。

异构服务如何被调用
如果异构服务为服务提供方（会被其它服务调用），服务发起方会先注册中心发现sidecar代理注册的实例信息，将请求发送到Sidecar，Sidecar将请求转发给异构服务完成调用请求。

题19：创建一个-pod-的流程是什么

kubernetes Pod创建的工作流：

第一步：

kubectl 向api server 发起一个create pod 请求

第二步：

api server接收到pod创建请求后，不会去直接创建pod，而是生成一个包含创建信息的yaml。

第三步：

apiserver 将刚才的yaml信息写入etcd数据库。到此为止仅仅是在etcd中添加了一条记录，还没有任何的实质性进展。

第四步：

scheduler 查看 k8s api ，类似于通知机制。
首先判断：pod.spec.Node == null?
若为null，表示这个Pod请求是新来的，需要创建；因此先进行调度计算，找到最“闲”的node。
然后将信息在etcd数据库中更新分配结果：pod.spec.Node = nodeA (设置一个具体的节点)
ps:同样上述操作的各种信息也要写到etcd数据库中中。

第五步：

kubelet 通过监测etcd数据库(即不停地看etcd中的记录)，发现api server 中有了个新的Node；
如果这条记录中的Node与自己的编号相同(即这个Pod由scheduler分配给自己了)；
则调用node中的docker api，创建container。

题20：kubernetes-中如何隔离资源

在k8s中的我们的资源如何隔离呢？如果说有一个服务异常了，内存无限制的占用，其他的服务岂不是无法部署上去了？

而且我们一般一个集群是给很多人，很多对象使用的，那么如何保证他们互不打扰？且无法看到其他人的相关内容呢？

Namespace

一个重要的概念，Namespace，我们之前说过，但是没有细说他的功能是什么，他可以实现资源隔离和配额的隔离，比如下面的信息：

从上图可以清晰的看到他能做什么，接下来实际操作下吧。

新建namespace

首先我们先查询下本地有多少个namespace；

[root@node1 ~]# kubectl get namespace
NAME STATUS AGE
default Active 18d
kube-node-lease Active 18d
kube-public Active 18d
kube-system Active 18d

再看下命名空间中都有什么呢？这里我们只查看pod哈。

[root@node1 ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
deploy-springboot-5dbfc55f78-mpg69 1/1 Running 1 21h
nginx-ds-q2pjt 1/1 Running 17 11d
nginx-ds-zc5qt 1/1 Running 22 17d
[root@node1 ~]# kubectl get pods -n kube-node-lease
No resources found in kube-node-lease namespace.
[root@node1 ~]# kubectl get pods -n kube-public
No resources found in kube-public namespace.
[root@node1 ~]# kubectl get pods -n kube-system
NAME READY STATUS RESTARTS AGE
calico-kube-controllers-858c9597c8-6gzd5 1/1 Running 29 17d
calico-node-6k479 1/1 Running 21 17d
calico-node-bnbxx 1/1 Running 21 17d
coredns-84646c885d-6fsjk 1/1 Running 21 17d
coredns-84646c885d-sdb6l 1/1 Running 21 17d
kube-flannel-ds-d7kvz 0/1 CrashLoopBackOff 614 11d
kube-flannel-ds-klfvj 0/1 CrashLoopBackOff 612 11d
nginx-proxy-node3 1/1 Running 22 18d
nodelocaldns-gj9xf 1/1 Running 21 17d
nodelocaldns-sw9jh 1/1 Running 21 17d
[root@node1 ~]#

从上面可以看到，如果不指定命名空间的话，默认访问的是名字为default的命名空间，如果我们想看到其他命名空间下的资源，我们需要手动使用“-n”参数来指定。而且，如果你创建的时候没有指定namespace，那么默认也是都在default这个命名空间下的。

那么接下来我们来创建一个命名空间吧。

[root@node1 ~]# mkdir namespace
[root@node1 ~]# cd namespace/
[root@node1 namespace]# vim create_namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
name: dev
[root@node1 namespace]# kubectl create -f create_namespace.yaml
namespace/dev created
[root@node1 namespace]#

那么我们就创建了一个名字叫dev的命名空间，我们查看下：

[root@node1 namespace]# kubectl get namespace
NAME STATUS AGE
default Active 18d
dev Active 69s
kube-node-lease Active 18d
kube-public Active 18d
kube-system Active 18d
[root@node1 namespace]#

新建一个pod

[root@node1 namespace]# vim web-demo.yaml
#deploy
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-demo
namespace: dev
spec:
selector:
matchLabels:
app: web-demo
replicas: 1
template:
metadata:
labels:
app: web-demo
spec:
containers:
- name: web-demo
image: registry.cn-beijing.aliyuncs.com/yunweijia0909/tomcat:jre8-openjdk
ports:
- containerPort: 8080
---
#service
apiVersion: v1
kind: Service
metadata:
name: web-demo
namespace: dev
spec:
ports:
- port: 80
protocol: TCP
targetPort: 8080
selector:
app: web-demo
#type: ClusterIP

---
#ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: web-demo
namespace: dev
spec:
rules:
- host: web.yunweijia.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: web-demo-dev
port:
number: 80
[root@node1 namespace]# kubectl apply -f web-demo.yaml
deployment.apps/web-demo created
service/web-demo created
ingress.networking.k8s.io/web-demo created
[root@node1 namespace]#

然后查看下dev这个命名空间下是否有了；

[root@node1 namespace]# kubectl get pods -n dev
NAME READY STATUS RESTARTS AGE
web-demo-58bf7ccc9c-d7gxl 1/1 Running 0 42s
[root@node1 namespace]# kubectl get all -n dev
NAME READY STATUS RESTARTS AGE
pod/web-demo-58bf7ccc9c-d7gxl 1/1 Running 0 46s

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/web-demo ClusterIP 10.233.101.225 80/TCP 46s

NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/web-demo 1/1 1 1 46s

NAME DESIRED CURRENT READY AGE
replicaset.apps/web-demo-58bf7ccc9c 1 1 1 46s
[root@node1 namespace]#

测试下命名空间的隔离性

首先我们需要在default这个命名空间下新建个两个pod，然后去做测试，因为我现在就有nginx这个pod，所以再启动一个tomcat的pod吧。

如果看过我之前的文章，你应该在default命名空间中有较多的pod，就不用新建了，我这里是演示完就删了，所以没了。

题21：k8s-常用的标签分类有哪些

标签分类是可以自定义的，但是为了能使他人可以达到一目了然的效果，一般会使用以下一些分类：

版本类标签（release）：stable（稳定版）、canary（金丝雀版本，可以将其称之为测试版中的测试版）、beta（测试版）；环境类标签（environment）：dev（开发）、qa（测试）、production（生产）、op（运维）；应用类（app）：ui、as、pc、sc；架构类（tier）：frontend（前端）、backend（后端）、cache（缓存）；分区标签（partition）：customerA（客户A）、customerB（客户B）；品控级别（Track）：daily（每天）、weekly（每周）

题22：容器和主机部署应用的区别是什么

容器的中心思想就是秒级启动；一次封装、到处运行；这是主机部署应用无法达到的效果，但同时也更应该注重容器的数据持久化问题。

另外，容器部署可以将各个服务进行隔离，互不影响，这也是容器的另一个核心概念。

题23：描述一下-kubernetes-deployment-升级过程

在Deployment的定义中，可以通过spec.strategy指定Pod更新的策略，目前支持两种策略：Recreate（重建）和RollingUpdate（滚动更新），默认值为RollingUpdate。

Recreate：设置spec.strategy.type=Recreate，表示Deployment在更新Pod时，会先杀掉所有正在运行的Pod，然后创建新的Pod。
RollingUpdate：设置spec.strategy.type=RollingUpdate，表示Deployment会以滚动更新的方式来逐个更新Pod。同时，可以通过设置spec.strategy.rollingUpdate下的两个参数（maxUnavailable和maxSurge）来控制滚动更新的过程。

题24：ku bernetes-中-metric-service-有什么作用

Metrics Server是一个集群范围内的资源数据集和工具，同样的，metrics-server也只是显示数据，并不提供数据存储服务，主要关注的是资源度量API的实现，比如CPU、文件描述符、内存、请求延时等指标，metric-server收集数据给k8s集群内使用，如kubectl,hpa,scheduler等。

Metrics Server从Kubelet收集资源指标，并通过Metrics API在Kubernetes apiserver中公开它们，以供Horizontal Pod Autoscaler（HPV）和Vertical Pod Autoscaler（VPA）使用。Metrics API也可以通过访问kubectl top，从而更容易调试自动缩放管道。

Metrics Server不适用于非自动缩放目的。例如，不要使用它来将指标转发给监控解决方案，或作为监控解决方案指标的来源。在这种情况下，请直接从Kubelet/metrics/resource端点收集指标。

Metrics Server提供：

1、适用于大多数集群的单一部署
2、快速自动缩放，每15秒收集一次指标
3、资源效率，集群中每个节点使用1 mili 的CPU核心和2 MB的内存
4、可扩展支持多达5,000 个节点集群

题25：kubernetes-中-rbac-是什么有什么优势

RBAC是基于角色的访问控制，是一种基于个人用户的角色来管理对计算机或网络资源的访问的方法。
相对于其他授权模式，RBAC具有如下优势：
对集群中的资源和非资源权限均有完整的覆盖。
整个RBAC完全由几个API对象完成，同其他API对象一样，可以用kubectl或API进行操作。
可以在运行时进行调整，无须重新启动API Server。

26：什么是容器？

一系列隔离运行的进程，提供了一种轻量操作系统层面的虚拟化技术每个容器拥有自己的PID,User,UTS,Network栈命名空间等
与传统VM比具有启动快、性能损耗小、更轻量等优点

Kubernetes 有哪些特点

可移植: 支持公有云，私有云，混合云，多重云（multi-cloud）

可扩展: 模块化，插件化，可挂载，可组合

自动化: 自动部署，自动重启，自动复制，自动伸缩/扩展

Kubernetes架构和组件

27、 Kubernetes所能识别的最小单元什么？

Pod就是Kubernetes所能识别的最小单元。它包含了一个或多个的容器并看做是一个整体的单元。基本上，可以说Pod就是一个单一的微服务。

28、K8S与Swarm的共同点是什么

Docker Swarm和Kubernetes都是用来编排容器的，但是是以不同的方式。

关于集群

集群是一组节点，这些节点可以是物理服务器或者虚拟机，之上安装了Kubernetes平台。下图展示这样的集群。注意该图为了强调核心概念有所简化。这里可以看到一个典型的Kubernetes架构图。

29、在安装Kubernetes时会因为无法拉取gcr.io镜像

在已知镜像名称和标签的情况，可以通过阿里云镜像仓库+GitHub用Dockerfile重新打包gcr.io 镜像，然后安装时从阿里云镜像仓库直接下载再重命名为gcr.io镜像。在未知镜像名称和标签的情况，需要先找一台可以科学上网的机器来装一遍，再通过docker images 查看准确的镜像名称和标签。

30、是否手动创建Pod，如果想要创建同一个容器的多份拷贝，需要一个个分别创建出来么，能否将Pods划到逻辑组里？

Replication Controller确保任意时间都有指定数量的Pod“副本”在运行。如果为某个Pod创建了Replication Controller并且指定3个副本，它会创建3个Pod，并且持续监控它们。如果某个Pod不响应，那么Replication Controller会替换它，保持总数为3.如下面的动画所示：
centos下如何配置主机互信

31、如何监控部署在Docker容器上的应用程序？

Kubernetes可以通过设定livenessProbe属性来为一个Pod做健康检测。

32.怎样从外面访问一个跑着许多Docker实例的应用程序？

通过使用Kubernetes的Service资源，可以有多种方案实现对一个跑在Kubernetes里的带有多个实例的Docker应用的访问。可以使用一个公网IP来创建一个Service，一个负载均衡Service，或者说，如果是HTTP的情况下，用一个Kubernetes的Ingress资源。

33.Docker + Kubernetes只能在Linux环境下运行吗？

不，Docker加入对Windows的支持已经有一段时间了，而就在1.5版本的时候，Kubernetes加入了对Windows Server容器的支持，控制器仍然还跑在Linux上，然后Kubelet和Kubeproxy则可以在Windows上运行。

34.Kubernetes和Openstack发展方向是怎样的？它们之间存在很多分歧吗？

Kubernetes和Openstack是两个完全不同的东西；真的没有必要去比较它们，因为它们根本从来都碰不到一起。你可以在Openstack上跑Kubernetes，你也可以使用Kubernetes来编排Openstack，但是它们始终还是两个截然不同的东西。

35.Mirantis提供对Kubernetes的支持吗？

到目前为止，Mirantis的产品只限于Openstack，这也即是我们所支持的全部；当我们加入对Kubernetes的支持时，事情可能会有一定程度的转变，但是就目前而言，情况就是这样。
15.怎么把一个公网IP分配给一个跑在Openstack虚拟机里的Docker容器？

只要像分配任何其他基于Openstack的公网IP一样通过浮动IP去做就行。

36.应用和运行时平台是怎样解耦的？

容器是设计成自包含的。因此可以创建一个包含了系统的所有内容，让它拥有完备的移植性。我们也应该明白一点，应用程序不可能完全和运行时平台解耦。举个例子，你如果有一个应用是用Mono（Linux版本的.NET）写的，你可以用Linux上的Kubernetes来运行它，但是直接用Windows Server容器跑的话就只能运行在Windows上的Kubernetes了。

37.Docker/Kubernetes可以用在Windows服务或者实际的应用，数据库，还有存储吗，或者说你可以创建windows的虚拟机然后在Kubernetes下面跑吗？

听上去所说的“实际应用”真的有点像是在说“宠物”类应用。如果是的话，那么最好还是用虚拟机来跑吧。

38.是不是可以这样说，Kubernetes的编排就像一个流程图？一系列一个接一个的动作？

理想情况下，这是对的，但是实际上它并不是这样 —— 反正不是直接如此。当你在YAML文件里包含了多个定义时，没有办法保证它们会以怎样特定的顺序去执行。要解决这个问题实现“流程图”效果的话，你可以看下Kubernetes新的APPController。

39.虽然容器是分层的，在宿主操作系统这块每个分层也是重复部署的。Openstack会为此提供一个轻量级的容器宿主虚拟机吗？

与其操心有没有一个轻量级的容器宿主虚拟机镜像，还不如考虑下用一个最小集操作系统作为容器的基础层，比如Alpine Linux。

40.企业部署k8s，多少节点合适

多少个节点看业务，还有物理机配置，假如一个物理机配置特别高，那你部署十个节点，比你用100 台低配置的机器都要跑的业务更多。

41.上万规模的容器的kubernetes集群，使用kubernetes时需要注意哪些问题？

上万规模需要用ipvs做转发，网络用calico性能更好。

42.kubernetes的运维中有哪些注意的要点？

注意做好hpa，还有livenessProbe和readnessProbe这种探测，数据持久化，监控等

43.kube-apiserver和kube-scheduler的作用是什么？

kube–apiserver遵循横向扩展架构，并且是主节点控制面板的前端。这将公开Kubernetes主节点组件的所有API，并负责在Kubernetes节点和Kubernetes主组件之间建立通信。kube-scheduler负责在工作节点上分配和管理工作负载。因此，它根据资源需求选择最合适的节点来运行Pod，并跟踪资源利用率。它可以确保未在已满的节点上调度工作负载。

44.您能简要介绍一下Kubernetes控制器管理器吗？

多个控制器进程在主节点上运行，但被编译在一起以作为单个进程（即Kubernetes Controller Manager）运行。因此，Controller Manager是一个守护程序，它嵌入控制器并执行名称空间创建和垃圾回收。它负责并与API服务器通信以管理端点。因此，在主节点上运行的不同类型的控制器管理器为。

45.k8s的核心组件：

etcd保存了整个集群的状态； apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制； controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等； scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上； kubelet负责维护容器的生命周期，同时也负责Volume（CSI）和网络（CNI）的管理； Container runtime负责镜像管理以及Pod和容器的真正运行（CRI）； kube-proxy负责为Service提供cluster内部的服务发现和负载均衡；

除了核心组件，还有一些推荐的Add-ons：(更新中)

kube-dns负责为整个集群提供DNS服务 Ingress Controller为服务提供外网入口
Heapster提供资源监控 Dashboard提供GUI
Federation提供跨可用区的集群