K8S面试题总结_nfs cifs csi

面试题目都是网上找的，块引用内的为结合黑马k8s教程比较理解的内容

1、kubenetes针对pod资源对象的健康监测机制?

答：提供了三类probe（探针）来执行对pod的健康监测：
1)liveness Probe探针：存活性探针，可以根据用户自定义规则来判定pod是否健康，用于判断容器是否处于Running状态，如果不是，kubelet就会杀掉该容器，并根据重启策略做相应的处理。如果容器不包含该探针，那么kubelet就会默认返回值都是success;

2)Readiness Probe探针：就绪性探针，同样是可以根据用户自定义规则来判断pod是否健康，容器服务是否可用（Ready），如果探测失败，控制器会将此pod从对应service的endpoint列表中移除，从此不再将任何请求调度到此Pod上，直到下次探测成功;

3)startup Probe探针: 启动检查探针，应用一些启动缓慢的业务，避免业务长时间启动而被上面两类探针kill掉，这个问题也可以换另一种方式解决，就是定义上面两类探针机制时，初始化时间定义的长一些即可;

备注：每种探测方法能支持以下几个相同的检查参数，用于设置控制检查时间：initialDelaySeconds：初始第一次探测间隔，用于应用启动的时间，防止应用还没启动而健康检查失败；

periodSeconds：检查间隔，多久执行probe检查，默认为10s；

timeoutSeconds：检查超时时长，探测应用timeout后为失败；

successThreshold：成功探测阈值，表示探测多少次为健康正常，默认探测1次。

2、pod的重启策略是什么？

restartPolicy，上面讲述了pod的健康检测机制，一旦容器的探测出现了问题，kubernetes就会对容器所在的pod进行重启，具体的重启规则就是由重启策略决定的。pod的重启策略分为以下三种：

Always ：容器失效时，自动重启该容器，这也是默认值。
OnFailure ： 容器终止运行且退出码不为0（异常）时重启
Never ： 不论状态为何，都不重启该容器

重启策略适用于pod对象中的所有容器，首次需要重启的容器，将在其需要时立即进行重启，随后再次需要重启的操作将由kubelet延迟一段时间后进行，且反复的重启操作的延迟时长以此为10s、20s、40s、80s、160s和300s，300s是最大延迟时长。（防止重启失败时，所有的资源都浪费在重启上。）

退出状态码为0时包含两种状态，一种是正常完成后返回值0，（一次性的pod完成后）；第二种 手动指定 exit 0；其余pod对象错误的时候，会重启。

3、DaemonSet资源对象的特性？

 答：DaemonSet这种资源对象会在每个k8s集群中的节点上运行，并且每个节点只能运行一个pod，这是它和deployment资源对象的最大也是唯一的区别。所以，在其yaml文件中，不支持定义replicas，除此之外，与Deployment、RS等资源对象的写法相同,一般使用的场景有
在去做每个节点的日志收集工作；监控每个节点的的运行状态;

DaemonSet控制器的特点：

• 每当向集群中添加一个node节点时，指定的 Pod 副本也将添加到该节点上
• 当node节点从集群中移除时，Pod 也就被垃圾回收了

4、删除一个Pod会发生什么事情？

4.1，回答这个问题首先要了解一下pod的生命周期

1. pod创建过程
2. 运行初始化容器（init container）过程 （顺序执行，前一个成功，后一个开始）
3. 运行主容器（main container）
   1. 容器启动后钩子（post start）
   2. 容器的存活性探测（liveness probe）、就绪性探测（readiness probe）
   3. 容器终止前钩子（pre stop）
4. pod终止过程

在整个生命周期中，Pod会出现5种状态（相位），分别如下：

1. 挂起（Pending）：apiserver已经创建了pod资源对象，但它尚未被调度完成或者仍处于下载镜像的过程中
2. 运行中（Running）：pod已经被调度至某节点，并且所有容器都已经被kubelet创建完成
3. 成功（Succeeded）：pod中的所有容器都已经成功终止并且不会被重启
4. 失败（Failed）：所有容器都已经终止，但至少有一个容器终止失败，即容器返回了非0值的退出状态
5. 未知（Unknown）：apiserver无法正常获取到pod对象的状态信息，通常由网络通信失败所导致

4.2 然后介绍一下pod的创建过程

1. 用户通过kubectl命令或者其他api客户端提交需要创建的pod信息给apiserver
2. apiServer开始生成pod对象的信息，并将信息存入etcd中，然后返回确认信息给客户端（这里是直接返回确认信息，不用等待其他过程的执行）
3. apiServer开始反应etcd中pod对象的变化，其他组件使用watch机制来跟踪检查apiServer上的变动
4. scheduler发现有新的pod对象要创建，开始为pod分配主机并将结果信息更新给apiServer
5. node节点上的kubelet也在监听apiserver节点，kubelet发现有pod调度过来，开始启动容器，并将结果在返回给apiserver
6. apiserver将接受到的pod信息更新到etcd中。

4.3，pod的终止过程（删除一个pod）

1. 用户向apiserver发送删除pod对象的命令；apiserver中的pod对象信息会随着时间进行更新，宽限期内（默认30s）pod被认为dead （给容器停止一定的时间）
2. pod被标记为terminating状态
3. kubelet在监听到pod转变为terminating状态的同时启动pod的关闭过程
4. 端点控制器监听到pod对象的关闭行为时，会将其从所有匹配到此端点的service资源端点列表中移除
5. 如果当前pod对象定义了preStop钩子处理器，则会在标记为terminating后立即以同步的方式启动执行。（没有定义则没有此步骤）
6. pod对象中的容器进程收到停止信号，在宽限期结束后，如果pod中还存在运行的进程，那么pod对象会收到立即终止的信号。（强杀）
7. kubelet请求apiserver将此pod资源的宽限期设置为0从而完成删除操作，此时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）;

5、请详述kube-proxy原理?      

kubernetes中，pod是应用程序的载体，我们可以根据pod的ip和端口号去访问应用程序，但是pod的ip是不固定的，一般情况下是无法通过pod的ip去访问服务的。为了解决这个问题，kubernetes提供了serveice资源，service会对提供同一个服务的多个pod进行聚合（通过selector标签）,提供一个统一的入口地址，来访问pod中的服务。

service其实只是一个概念，真正起作用的是kube-proxy服务进程，每个node节点上都运行一个kube-proxy服务进程，创建service的时候会通过apiserver向etcd中写入service的信息，kube-proxy进行会监听service的变动，然后将最新的service信息转换成对应的访问规则。

kube-proxy现在支持的三种模式：

1、userspace模式 

userspace模式下，kube-proxy会为每个service创建一个监听端口，发向cluster IP的请求被iptables规则重定向到kube-proxy监听的端口上，然后kube-proxy根据LB算法选择一个可以提供服务的pod并建立连接，将请求转发到这个pod上。

这种模式，进行请求转发处理时，会增加内核和用户之间的数据拷贝，效率低，但是稳定

2、iptables模式

iptables模式下，kube-proxy为service后端的每个pod创建对应的iptables规则，将直接发向cluster IP的请求重定向到一个pod 的ip上。

该模式下kube-proxy只负责创建iptables规则，优点是效率高，但是不能提供灵活的负载均衡策略，而后端pod不可用时，也无法重试。

3、ipvs模式

 ipvs模式和iptables类似，kube-proxy监控Pod的变化并创建相应的ipvs规则。ipvs相对iptables转发效率更高。除此以外，ipvs支持更多的LB算法

 答：集群中每个Node上都会运行一个kube-proxy服务进程，他是Service的透明代理兼均衡负载器，其核心功能是将某个Service的访问转发到后端的多个Pod上。kube-proxy通过监听集群状态变更，并对本机iptables做修改，从而实现网络路由。 而其中的负载均衡，也是通过iptables的特性实现的。从V1.8版本开始，用IPVS（IP Virtual Server）模式，用于路由规则的配置，主要优势是：1）为大型集群提供了更好的扩展性和性能。采用哈希表的数据结构，更高效；2）支持更复杂的负载均衡算法；3）支持服务器健康检查和连接重试；4）可以动态修改ipset的集合；

6、flannel 和 ovs 网络的区别？

看下面的答案总结的：

1. flannel 能够感知k8s中service对象的变化，然后动态的维护自己的路由表，很方便的实现pod之间的通信，但是无法实现多租户的隔离和限制pod的网络流量
2. ovs需要手动的维护路由表，但是支持租户隔离。

        答：1）配置是否自动化：OpenvSwitch（ovs）作为开源的交换机软件，相对比较成熟和稳定，支持各种网络隧道和协议，经历了大型项目 OpenStack 的考验，而 flannel 除了支持建立覆盖网络来实现 Pod 到 Pod 之间的无缝通信之外，还跟 docker、k8s 的架构体系紧密结合，flannel 能感知 k8s 中的 service 对象，然后动态维护自己的路由表，并通过 etcd 来协助 docker 对整个 k8s 集群的 docker0 网段进行规范，而 ovs ，这些操作则需要手动完成，假如集群中有 N 个节点，则需要建立 N(N-1)/2 个 Vxlan 或者 gre 连接，这取决于集群的规模，如果集群的规模很大，则必须通过自动化脚本来初始化，避免出错。2）是否支持隔离：flannel 虽然很方便实现 Pod 到 Pod 之间的通信，但不能实现多租户隔离，也不能很好地限制 Pod 的网络流量，而 ovs 网络有两种模式：单租户模式和多租户模式，单租户模式直接使用 openvswitch + vxlan 将 k8s 的 pod 网络组成一个大二层，所有的 pod 可以互相通信访问，多租户模式以 Namespace 为维度分配虚拟网络，从而形成一个网络独立用户，一个 Namespace 中的 pod 无法访问其他 Namespace 中的 pod 和 svc 对象；

7、k8s集群外流量怎么访问Pod？

service的ip地址只有集群内部才可以访问，如果希望将service暴露给外部使用，需要用到NodePort类型的service，工作原理就是将service的端口映射到Node的一个端口上，然后通过NodeIP:NodePort来访问service。（NodePort默认取值30000~32767）

8、K8S 资源限制 QoS？

Quality of Service（Qos）

1. Guaranteed：每个容器都必须设置CPU和内存的限制和请求（最大和最小），最严格的要求。
2. Burstable：在不满足Guaranteed的情况下，至少设置一个CPU或者内存的请求。
3. BestEffort：什么都不设置，佛系资源申请。

可压缩资源,如CPU资源
当资源紧俏，发生资源抢占时，Pod可以分享时间片。例如，在1U的node上，容器A请求0.6U，容器B请求0.4U。资源紧俏时，将会按照请求的比例分配时间片。容器A：0.6U/(0.6U+0.4U)；容器B：0.4U/(0.6U+0.4U)。
当资源剩余，发生超用时，即实际使用超过请求，Pod按照比例分配剩余资源。例如，在1U的node上，容器A请求0.6U，容器B请求0.3U，剩余0.1U。两个容器都想超用，剩余的0.1U将会按照请求的比例进行2:1分配给两个容器。
关于提高资源利用率，可以将负载高峰时间错开的应用部署在一起，提高node利用率。

不可压缩资源，如内存和磁盘资源。
当资源紧俏时，例如OOM，kubelet会根据QoS进行驱逐：
Best-Effort，最低优先级，第一个被kill；
Burstable，第二个被kill。
Guaranteed，最高优先级，最后kill。除非超过limit或者没有其他低优先级的Pod；
由于对于不可压缩资源，发生抢占的情况会出Pod被意外Kill掉的情况，所以建议对于不可以压缩资源(Memory，Disk)的设置成0<Request==Limit，即Guaranteed。

9、k8s数据持久化的方式有哪些？

1、EmptyDir

最基础的持久化方式，一个EmptyDir就是host上的一个空目录。

EmptyDir在pod被分配到node时创建，初始内容为空，pod销毁时，EmptyDir中的数据也会被永久删除（不适合数据持久化），用途如下：

• 临时空间，用于某些应用程序运行时所需要的临时目录，并且无须永久保留
• 多容器共享目录（一个容器需要从另一个容器上获取数据）

2、Hostpath

Hostpath就是将Node主机中一个实际目录挂在到Pod中，以供容器使用，这样的设计就可以保证Pod销毁了，但是数据依据可以存在于Node主机上

3、PV/PVC

HostPath可以解决数据持久化的问题，但是一旦Node节点故障了，Pod如果转移到了别的节点，又会出现问题了（会有新的hostpath volume在别的Node创建，但是原来的数据丢失了），此时需要准备单独的网络存储系统，比较常用的用NFS、CIFS。

NFS是一个网络文件存储系统，可以搭载一台NFS服务器，然后将pod中的存储直接连到NFS系统上，这样无论pod怎么在Node中转移，只要和NFS的对接没有问题，数据就不会丢失。

PV（Persistent Volume）持久化卷

NFS或者CIFS都是属于底层的共享存储类型，想要全部掌握显然不够现实，因此K8S引用了PV来对底层存储进行抽象，一般是由kubernetes管理员进行创建配置。

PVC（Persistent Volume Claim）持久卷声明

用户通过PVC对存储需求进行声明，然后申请对应的PV进行持久化存储。

PV关键参数配置的说明：

1、存储类型：

        底层实际的存储类型，包括NFS，CIFS等

2、存储能力：

        目前只支持存储空间的设置( storage=1Gi )，不过未来可能会加入IOPS、吞吐量等指标的配置

3、访问模式：accessModes 

• ReadWriteOnce（RWO）：读写权限，但是只能被单个节点挂载
• ReadOnlyMany（ROX）： 只读权限，可以被多个节点挂载
• ReadWriteMany（RWX）：读写权限，可以被多个节点挂载
• 注意：不同的底层存储类型可能支持的访问模式不一样

4、回收策略

        PV不在被使用后，对PV的处理方式：

• Retain （保留） 保留数据，需要管理员手工清理数据
• Recycle（回收） 清除 PV 中的数据，效果相当于执行 rm -rf /thevolume/*
• Delete （删除） 与 PV 相连的后端存储完成 volume 的删除操作，当然这常见于云服务商的存储服

5、存储类别

        PV可以通过storageClassName参数指定一个存储类别

• 具有特定类别的PV只能与请求了该类别的PVC进行绑定

• 未设定类别的PV则只能与不请求任何类别的PVC进行绑定

6、状态

一个 PV 的生命周期中，可能会处于4中不同的阶段：

• Available（可用）： 表示可用状态，还未被任何 PVC 绑定
• Bound（已绑定）： 表示 PV 已经被 PVC 绑定
• Released（已释放）： 表示 PVC 被删除，但是资源还未被集群重新声明
• Failed（失败）： 表示该 PV 的自动回收失败

10、K8S的基本组成部分？

10.1、控制平面，master节点

1. apiserver：控制平面的前端，资源操作唯一的入口，用于处理所有内部和外部请求。
2. scheduler：负责集群资源的调度，按照预定的调度策略将pod调度到相应的node节点上
3. controller-manager：所有资源对象的控制中心，负责维护集群状态，比如程序部署安排、故障检测、自动扩展、滚动更新等
4. etcd：负责存储集群中各种资源对象信息

 10.2 工作节点node节点

1. Kubelet: 负责维护容器的生命周期，即通过控制“容器运行时”，来创建、更新、销毁容器
2. KubeProxy: 负责提供集群内部的服务发现和负载均衡

3. Container Runtime 容器运行时，负责运行容器的软件，containerd、docker等。

11、K8s中镜像的下载策略是什么？

可通过命令“kubectl explain pod.spec.containers”来查看imagePullPolicy这行的解释，K8s的镜像下载策略有三种：

1. Always：镜像标签为latest时，总是从指定的仓库中获取镜像；
2. Never：禁止从仓库中下载镜像，也就是说只能使用本地镜像；
3. IfNotPresent：仅当本地没有对应镜像时，才从目标仓库中下载；

12、标签与标签选择器的作用是什么？

• 标签：是当相同类型的资源对象越来越多的时候，为了更好的管理，可以按照标签将其分为一个组，为的是提升资源对象的管理效率；
• 标签选择器：就是标签的查询过滤条件。

13、K8s的负载均衡器？

K8S的负载均衡方案有三种：kube-proxy（userspace）、iptables（防火墙）、ipvs。

1. 服务类型为userspace时，kube-proxy负责负载均衡
2. iptables是k8s默认的负载均衡策略，默认是随机策略，也可以设置为轮询
3. ipvs (IP Virtual Server) 实现传输层负载均衡，通常称为第四层LAN交换，是Linux内核的一部分。

4. Ingres是K8S对于nginx进行云原生模式的封装，使得nginx更适合云原生的结构，使用Ingres可以对Service进行负载均衡，因此Ingres工作在七层，属于七层负载均衡。

   Ingres通过http协议的方式实现Service的负载均衡

说明：在linux中iptables设计是用于防火墙的，对于比较少的规则，没有太多的性能影响，如果对于一个庞大的K8S集群，会有上千Service服务，Service服务会对应多个pod，每条都是一个iptables规则，那么对于集群来说，每个node上都有大量的规则，简直是噩梦。而IPVS则是使用hash tables来存储网络转发规则的，比iptables更有优势，而且ipvs主要工作在kerbespace，减少了上下文的切换。

IPVS有轮询（rr）、最小连接数（lc）、目的地址hash（dh）、源地址hash（sh）、最短期望延迟（sed）、无须队列等待（nq）等负载均衡算法，在node上通过 “–ipvs-scheduler”参数，指定kube-proxy的启动算法

14、kubelet 监控 Node 节点资源使用是通过什么组件来实现的？

用Metrics Server提供核心指标，包括Node、Pod的CPU和内存的使用。

我们可以通过kubectl scale 命令或者改yaml文件实现pod的扩容，但是不符合k8s自动化，智能化的定位。

k8s提供了Horizontal Pod Autoscaler（HPA）这种控制器，用来监测pod的使用情况，实现pod数量的自动调整。使用HPA前就要安装metrics-server，来收集集群中资源使用情况。

在1.8版本以前：

kubelet使用cAdvisor对worker节点资源进行监控。在 Kubernetes 系统中，cAdvisor 已被默认集成到 kubelet 组件内，当 kubelet 服务启动时，它会自动启动 cAdvisor 服务，然后 cAdvisor 会实时采集所在节点的性能指标及在节点上运行的容器的性能指标；

15、Pod的状态？

答：

1）Pending：已经创建了Pod，但是其内部还有容器没有创建；

2）Running：Pod内部的所有容器都已经创建，只有由一个容器还处于运行状态或者重启状态；

3）Succeeed：Pod内所有容器均已经成功执行并且退出，不会再重启；

4）Failed：Pod内所有容器都退出，但至少有一个为退出失败状态；

5）Unknown：由于某种原因不能获取该Pod的状态，可能是网络问题；

16、deployment/rs的区别？

ReplicaSet（RS）是一种pod控制器，主要作用是保证一定数量的pod正常运行，他会持续监听pod的运行状态，一旦pod发送故障，就会重建或者重启 （replicas里面可以定义pod的数量，默认为1）

Deployment也是一种pod控制器，但是他不直接管理pod，而是通过管理rs来间接管理pod，因此rs的功能deployment都支持，并且还支持以下功能（发布的停止和继续，滚动升级和回滚版本。）

        答：deployment是rs的超集，提供更多的部署功能，如：回滚、暂停和重启、 版本记录、事件和状态查看、滚动升级和替换升级。如果能使用deployment，则不应再使用rc和rs；

17、k8s 创建一个pod的详细流程，涉及的组件怎么通信的？

见4.2，pod的创建过程。

        答：1）客户端提交创建请求，可以通过 api-server 提供的 restful 接口，或者是通过 kubectl 命令行工具，支持的数据类型包括 JSON 和 YAML；2）api-server 处理用户请求，将 pod 信息存储至 etcd 中；3）kube-scheduler 通过 api-server 提供的接口监控到未绑定的 pod，尝试为 pod 分配 node 节点，主要分为两个阶段，预选阶段和优选阶段，其中预选阶段是遍历所有的 node 节点，根据策略筛选出候选节点，而优选阶段是在第一步的基础上，为每一个候选节点进行打分，分数最高者胜出；4）选择分数最高的节点，进行 pod binding 操作，并将结果存储至 etcd 中；5）随后目标节点的 kubelet 进程通过 api-server 提供的接口监测到 kube-scheduler 产生的 pod 绑定事件，然后从 etcd 获取 pod 清单，下载镜像并启动容器；

18、kubernetes服务发现？

这个问题应该是问k8s的service。kubernetes提供了Service资源，Service会对提供同一个服务的多个pod进行聚合（根据标签label进行分类，聚合），并且提供一个统一的入口地址。通过访问Service的入口地址就能访问到后面的pod服务。

        答：1）环境变量： 当你创建一个Pod的时候，kubelet会在该Pod中注入集群内所有Service的相关环境变量。需要注意: 要想一个Pod中注入某个Service的环境变量，则必须Service要先比该Pod创建；2）DNS：可以通过cluster add-on方式轻松的创建KubeDNS来对集群内的Service进行服务发现；

19、k8s发布(暴露)服务，servcie的类型有那些？

1. ClusterIP类型： kubernetes系统自动分配的虚拟ip（或者自己配置clusterIP），只能在集群内部访问
2. headless类型：无头服务，某些场景开发人员不想使用service提供的负载均衡功能，而是希望自己控制。（见后面）这类service配置时clusterIP要设置为None，如果要访问service，只能通过service的域名访问。
3. NodePort类型：这类service可以将service暴露给集群外部使用，原理就是将service的端口映射到Node的一个端口上，最常用
4. LoadBalancer类型：LoadBalancer又会在集群外部做一个负载均衡的设备，相当于把NodePort类型的service在向外映射。这种用法仅用于在公有云服务提供商的云平台上设置Service的场景；
5. ExternalName类型：用于引入集群外部的服务，通过externalName属性指定外部服务的地址，然后在集群内访问这个service的时候，就可以访问到外部服务了。

这个图说明了service的结构。

        答：kubernetes原生的，一个Service的ServiceType决定了其发布服务的方式。1） ClusterIP：这是k8s默认的ServiceType。通过集群内的ClusterIP在内部发布服务。2）NodePort：这种方式是常用的，用来对集群外暴露Service，你可以通过访问集群内的每个NodeIP:NodePort的方式，访问到对应Service后端的Endpoint。3）LoadBalancer: 这也是用来对集群外暴露服务的，不同的是这需要Cloud Provider的支持，比如AWS等。4）ExternalName：这个也是在集群内发布服务用的，需要借助KubeDNS(version >= 1.7)的支持，就是用KubeDNS将该service和ExternalName做一个Map，KubeDNS返回一个CNAME记录；

20、简述ETCD及其特点?

etcd是k8s的存储系统，k-v存储，强调各个节点之间通信，同步，确保各节点数据和事务的一致性，使服务发现工作更加稳定。

        答：etcd是一个分布式的、高可用的、一致的key-value存储数据库，基于Go语言实现，主要用于共享配置和服务发现。特点：1）完全复制：集群中的每个节点都可以使用完整的存档；2）高可用性：Etcd可用于避免硬件的单点故障或网络问题；3）一致性：每次读取都会返回跨多主机的最新写入；4）简单：包括一个定义良好、面向用户的API（gRPC）；5）安全：实现了带有可选的客户端证书身份验证的自动化TLS；6）快速：每秒10000次写入的基准速度；7）可靠：使用Raft算法实现了强一致、高可用的服务存储目录；

21、简述ETCD适应的场景?

        答：1）服务发现：服务发现要解决的也是分布式系统中最常见的问题之一，即在同一个分布式集群中的进程或服务，要如何才能找到对方并建立连接。本质上来说，服务发现就是想要了解集群中是否有进程在监听udp或tcp端口，并且通过名字就可以查找和连接。2）消息发布与订阅：在分布式系统中，最实用对的一种组件间的通信方式：消息发布与订阅。构建一个配置共享中心，数据提供者在这个配置中心发布消息，而消息使用者订阅他们关心的主题，一旦主题有消息发布，就会实时通知订阅者。达成集中式管理与动态更新。应用中用到的一些配置信息放到etcd上进行集中管理。3）负载均衡：分布式系统中，为了保证服务的高可用以及数据的一致性，通常都会把数据和服务部署多份，以此达到对等服务，即使其中的某一个服务失效了，也不影响使用。etcd本身分布式架构存储的信息访问支持负载均衡。4）分布式通知与协调：通过注册与异步通知机制，实现分布式环境下不同系统之间的通知与协调，从而对数据变更做到实时处理。5）分布式锁：因为etcd使用Raft算法保持了数据的强一致性，某次操作存储到集群中的值必然是全局一致的，所以很容易实现分布式锁。锁服务有两种使用方式，一是保持独占，二是控制时序。6）分布式队列：分布式队列的常规用法与场景五中所描述的分布式锁的控制时序用法类似，即创建一个先进先出的队列，保证顺序。7）集群监控与Leader精选：通过etcd来进行监控实现起来非常简单并且实时性强；

22、简述Kubernetes和Docker的关系?

docker是容器引擎，一种轻量级的虚拟化技术。

Kubernetes是一种容器编排软件，是为了解决容器化部署时遇到的一些问题：如容器故障停机后怎么处理，访问量变大的时候怎么自动横向扩展容器数量。

        答：Docker开源的容器引擎，一种更加轻量级的虚拟化技术；K8s，容器管理工具，用来管理容器pod的集合，它可以实现容器集群的自动化部署、自动扩缩容、维护等功能；

23、简述一些docker和containerd的关系。

containerd是docker的基础组件之一，从k8s的角度，可以选择docker或者containnerd来作为自己的容器运行时组件。因为containerd调用链更短，组件更少，更稳定，占用资源少，所有k8s后期默认使用containerd来作为容器运行时组件。

docker 由 docker-client ,dockerd,containerd,docker-shim,runc组成，所以containerd是docker的基础组件之一

24、简述Kubernetes中什么是Minikube、Kubectl、Kubelet?

1. Minikube 是一种可以在本地轻松运行一个单节点 Kubernetes 群集的工具；
2. Kubectl 是一个命令行工具，可以使用该工具控制Kubernetes集群管理器，如检查群集资源，创建、删除和更新组件，查看应用程序；
3. Kubelet 是一个代理服务，它在每个节点上运行，并使从服务器与主服务器通信；

25、简述Kubernetes如何实现集群管理?

master节点中运行着集群管理相关的进程，apiserver，scheduler，和controller-manager，这些进程实现了整个集群的资源管理，pod调度，弹性伸缩，安全控制，系统监控和纠错能力等。

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

26、简述Kubernetes的优势、适应场景及其特点?

优势：容器自动编排，轻量级，开源，支持弹性伸缩，负载均衡

适用场景：快速部署应用，扩展应用，无缝对接新的应用功能等

特点：可移植，可拓展，自动化

        答：优势：容器编排、轻量级、开源、弹性伸缩、负载均衡；场景：快速部署应用、快速扩展应用、无缝对接新的应用功能、节省资源，优化硬件资源的使用；特点：可移植: 支持公有云、私有云、混合云、多重云（multi-cloud）、可扩展: 模块化,、插件化、可挂载、可组合、自动化: 自动部署、自动重启、自动复制、自动伸缩/扩展；

27、简述Kubernetes的缺点或当前的不足之处?

        答：安装过程和配置相对困难复杂、管理服务相对繁琐、运行和编译需要很多时间、它比其他替代品更昂贵、对于简单的应用程序来说，可能不需要涉及Kubernetes即可满足；

28、简述Kubernetes相关基础概念?    

这里主要是介绍kubernetes中的资源类型  

• 节点nodes：master节点内相关进程及作用，node节点中的相关进程及作用
• 命名空间namespace：用于实现多套环境的资源隔离或者多租户的资源隔离
• pod：k8s集群进行管理的最小单元，程序要运行在容器中，容器要存在于pod中，可以认为pod是容器的封装，一个pod可以存在一个或者多个容器。
• pod控制器：replicaset，deployment，daemonset， jobs，cronjobs, HPA, statefulsets等
• 服务发现资源：service， ingress
• 数据持久化：emptydir, hostPath， PV/PVC
• 配置资源：configMap，secrets

        答：master：k8s集群的管理节点，负责管理集群，提供集群的资源数据访问入口。拥有Etcd存储服务（可选），运行Api Server进程，Controller Manager服务进程及Scheduler服务进程；node（worker）：Node（worker）是Kubernetes集群架构中运行Pod的服务节点，是Kubernetes集群操作的单元，用来承载被分配Pod的运行，是Pod运行的宿主机。运行docker eninge服务，守护进程kunelet及负载均衡器kube-proxy；pod：运行于Node节点上，若干相关容器的组合。Pod内包含的容器运行在同一宿主机上，使用相同的网络命名空间、IP地址和端口，能够通过localhost进行通信。Pod是Kurbernetes进行创建、调度和管理的最小单位，它提供了比容器更高层次的抽象，使得部署和管理更加灵活。一个Pod可以包含一个容器或者多个相关容器；label：Kubernetes中的Label实质是一系列的Key/Value键值对，其中key与value可自定义。Label可以附加到各种资源对象上，如Node、Pod、Service、RC等。一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上去。Kubernetes通过Label Selector（标签选择器）查询和筛选资源对象；Replication Controller：Replication Controller用来管理Pod的副本，保证集群中存在指定数量的Pod副本。集群中副本的数量大于指定数量，则会停止指定数量之外的多余容器数量。反之，则会启动少于指定数量个数的容器，保证数量不变。Replication Controller是实现弹性伸缩、动态扩容和滚动升级的核心；Deployment：Deployment在内部使用了RS来实现目的，Deployment相当于RC的一次升级，其最大的特色为可以随时获知当前Pod的部署进度；HPA（Horizontal Pod Autoscaler）：Pod的横向自动扩容，也是Kubernetes的一种资源，通过追踪分析RC控制的所有Pod目标的负载变化情况，来确定是否需要针对性的调整Pod副本数量；Service：Service定义了Pod的逻辑集合和访问该集合的策略，是真实服务的抽象。Service提供了一个统一的服务访问入口以及服务代理和发现机制，关联多个相同Label的Pod，用户不需要了解后台Pod是如何运行；Volume：Volume是Pod中能够被多个容器访问的共享目录，Kubernetes中的Volume是定义在Pod上，可以被一个或多个Pod中的容器挂载到某个目录下；Namespace：Namespace用于实现多租户的资源隔离，可将集群内部的资源对象分配到不同的Namespace中，形成逻辑上的不同项目、小组或用户组，便于不同的Namespace在共享使用整个集群的资源的同时还能被分别管理；

29、简述Kubernetes RC的机制?

rc/rs定义replica的数量，master节点的controller-manager巡检系统中存货的pod数量，如果pod实例值与期望值不服，就会创建或者停止一些pod。

        答：Replication Controller用来管理Pod的副本，保证集群中存在指定数量的Pod副本。当定义了RC并提交至Kubernetes集群中之后，Master节点上的Controller Manager组件获悉，并同时巡检系统中当前存活的目标Pod，并确保目标Pod实例的数量刚好等于此RC的期望值，若存在过多的Pod副本在运行，系统会停止一些Pod，反之则自动创建一些Pod；

30、简述kube-proxy作用?

kube-proxy 运行在所有节点上，它监听 apiserver 中 service 和 endpoint 的变化情况，将访问请求转发到后端的pod上。

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

31、简述kube-proxy iptables原理?

        答：Kubernetes从1.2版本开始，将iptables作为kube-proxy的默认模式。iptables模式下的kube-proxy不再起到Proxy的作用，其核心功能：通过API Server的Watch接口实时跟踪Service与Endpoint的变更信息，并更新对应的iptables规则，Client的请求流量则通过iptables的NAT机制“直接路由”到目标Pod；

32、简述kube-proxy ipvs原理?

        答：IPVS在Kubernetes1.11中升级为GA稳定版。IPVS则专门用于高性能负载均衡，并使用更高效的数据结构（Hash表），允许几乎无限的规模扩张，因此被kube-proxy采纳为最新模式；在IPVS模式下，使用iptables的扩展ipset，而不是直接调用iptables来生成规则链。iptables规则链是一个线性的数据结构，ipset则引入了带索引的数据结构，因此当规则很多时，也可以很高效地查找和匹配；可以将ipset简单理解为一个IP（段）的集合，这个集合的内容可以是IP地址、IP网段、端口等，iptables可以直接添加规则对这个“可变的集合”进行操作，这样做的好处在于可以大大减少iptables规则的数量，从而减少性能损耗；

33、简述kube-proxy ipvs和iptables的异同?

        答：iptables与IPVS都是基于Netfilter实现的，但因为定位不同，二者有着本质的差别：iptables是为防火墙而设计的；IPVS则专门用于高性能负载均衡，并使用更高效的数据结构（Hash表），允许几乎无限的规模扩张。与iptables相比，IPVS拥有以下明显优势：为大型集群提供了更好的可扩展性和性能；支持比iptables更复杂的复制均衡算法（最小负载、最少连接、加权等）；支持服务器健康检查和连接重试等功能；可以动态修改ipset的集合，即使iptables的规则正在使用这个集合；

34、简述Kubernetes中什么是静态Pod?

• 正常情况下，pod是在master上统一管理，指定和分配，静态pod就是不接受master的管理，在指定的node上 kubelet启动时，会自动启动定义的静态pod。
• 静态pod可以被apiserver发现，是因为kubelet会为他管理的每个静态pod，在apiserver上创建一个镜像pod，因此可以查询到，并且用kubectl命令访问，但是不能进行控制（如删除操作。）
• 如果尝试删除或者停止，静态Pod会进入Pending状态，并且很快会被kubelet重启。
• 静态pod完全交给kubelet进行监督和自愈，重启也会在这一个节点上重启，静态 Pod 始终绑定在某⼀个kubelet，并且始终运⾏在同⼀个节点上。
• 作用：静态pod绑定到某个节点的kubelet上，注意用途是运行自托管的控制面，可以有效预防误删除，可以部署一些核心组件，保证服务的稳定运行
• 例如：master节点上的apiserver，scheduler，controller-manager，etcd!

        答：静态pod是由kubelet进行管理的仅存在于特定Node的Pod上，他们不能通过API Server进行管理，无法与ReplicationController、Deployment或者DaemonSet进行关联，并且kubelet无法对他们进行健康检查。静态Pod总是由kubelet进行创建，并且总是在kubelet所在的Node上运行；

35、简述Kubernetes Pod的常见调度方式?

1. 自动调度：默认情况下，pod运行在那个节点，是scheduler通过一系列算法计算出来的，不受人工控制
2. 定向调度：
   1. nodeName（指定调度到某个节点上）、
   2. nodeSelector（指定调度到具有某个标签的节点上）；
   3. 注意：如果没有满足条件的Node,那么这个pod就不会运行
3. 亲和性调度Affinity：在定向调度的基础上进行拓展，如果找不到指定的node,也可以调度到不满足的节点上。
   1. nodeAffinity(node亲和性）：pod优先调度到哪些node上
   2. podAffinity(pod亲和性) ：pod可以和哪些已经存在的pod部署在一个拓扑中
   3. podAntiAffinity(pod反亲和性)：pod可以和哪些已经存在的pod避免部署在一个拓扑中
4. 污点和容忍
   1. 污点：Node上设置污点后，可以拒绝pod调度进来，有以下三种规则：
      1. PreferNoSchedule：避免调度到这个Node，除非没有其他可用的Node
      2. NoSchedule：不会调度到这个node，没有可用的也不会，但是已经存在的pod不受影响。
      3. NoExecute：不会调度到这个node，已经存在的pod也会被驱离。
   2. 容忍：Node有污点，但是pod可用容忍这些污点，容忍之后就可以调度到有污点的Node上了，但是要注意，容忍的规则也要和污点的规则对应起来

        答：1）Deployment或RC：该调度策略主要功能就是自动部署一个容器应用的多份副本，以及持续监控副本的数量，在集群内始终维持用户指定的副本数量；2）NodeSelector：定向调度，当需要手动指定将Pod调度到特定Node上，可以通过Node的标签（Label）和Pod的nodeSelector属性相匹配；3）NodeAffinity亲和性调度：亲和性调度机制极大的扩展了Pod的调度能力，目前有两种节点亲和力表达：硬规则，必须满足指定的规则，调度器才可以调度Pod至Node上（类似nodeSelector，语法不同）；软规则，优先调度至满足的Node的节点，但不强求，多个优先级规则还可以设置权重值；4）Taints和Tolerations（污点和容忍）：Taint：使Node拒绝特定Pod运行；Toleration：为Pod的属性，表示Pod能容忍（运行）标注了Taint的Node；

36、简述Kubernetes初始化容器（init container）?

init container的运行方式与应用容器不同，它们必须先于应用容器执行完成，当设置了多个init container时，将按顺序逐个运行，并且只有前一个init container运行成功后才能运行后一个init container。当所有init container都成功运行后，Kubernetes才会初始化Pod的各种信息，并开始创建和运行应用容器；

37、简述Kubernetes deployment升级过程?

升级，也就是镜像更新，分为两种类型

1、重建：创建出新的pod之前，先kill掉所有已经存在的pod，然后在创建

2、滚动更新：kill一部分，启动一部分，在更新中存在两个版本的pod

原题给的答案其实回答的是滚动更新的升级过程

升级时，deployment会额外创建一个新的rs，将副本数量扩展到1，就的rs缩减为2，之后按照相同的策略对新旧两个rs进行逐个调整，直到最后，新版本rs的pod数量对应副本数量，旧版本rs对应的副本数量变为0；

   rollingUpdate：当type为RollingUpdate时生效，用于为RollingUpdate设置参数，支持两个属性：
    maxUnavailable：用来指定在升级过程中不可用Pod的最大数量，默认为25%。
    maxSurge： 用来指定在升级过程中可以超过期望的Pod的最大数量，默认为25%。

        答：初始创建Deployment时，系统创建了一个ReplicaSet，并按用户的需求创建了对应数量的Pod副本；当更新Deployment时，系统创建了一个新的ReplicaSet，并将其副本数量扩展到1，然后将旧ReplicaSet缩减为2；之后，系统继续按照相同的更新策略对新旧两个ReplicaSet进行逐个调整；最后，新的ReplicaSet运行了对应个新版本Pod副本，旧的ReplicaSet副本数量则缩减为0；

38、简述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）来控制滚动更新的过程；

39、简述Kubernetes DaemonSet类型的资源特性?

回答见第3题

        答：DaemonSet资源对象会在每个Kubernetes集群中的节点上运行，并且每个节点只能运行一个pod，这是它和deployment资源对象的最大也是唯一的区别。因此，在定义yaml文件中，不支持定义replicas。它的一般使用场景如下：在去做每个节点的日志收集工作。监控每个节点的的运行状态。

40、简述Kubernetes自动扩容机制?

k8s使用HPA控制器实现基于CPU利用率进行自动Pod扩缩容的功能。HPA周期性的监测pod的资源性能指标，将CPU使用率和设置的监测条件进行对比，就会自动调整pod的副本数量。

        答：Kubernetes使用Horizontal Pod Autoscaler（HPA）的控制器实现基于CPU使用率进行自动Pod扩缩容的功能。HPA控制器周期性地监测目标Pod的资源性能指标，并与HPA资源对象中的扩缩容条件进行对比，在满足条件时对Pod副本数量进行调整；

41、简述Kubernetes Service分发后端的策略?

k8s提供了两种负载分法策略

1. 默认使用kube-proxy的策略，比如随机，轮询的方式发送到后端 的各个pod上
2. 基于客户端地址的会话保持模式，来自同一个客户端发起的所有请求都会转发到一个固定的pod上：
   1. 这个模式要在spec中添加配置项 sessionAffinity: ClientIP

        答：1）RoundRobin：默认为轮询模式，即轮询将请求转发到后端的各个Pod上；2）SessionAffinity：基于客户端IP地址进行会话保持的模式，即第1次将某个客户端发起的请求转发到后端的某个Pod上，之后从相同的客户端发起的请求都将被转发到后端相同的Pod上；

42、简述Kubernetes Headless Service?

前面已经了解了，增加了service后，访问服务的方式是 clusterIP:port，当前也可以通过service name来访问服务，利用的就是k8s中的coreDNS，他负责把service name 解析成clusterIP，然后通过clusterIP作为负载均衡，把流量分布到各个pod上。

在阐述一下clusterIP的原理：一个service可能对应多个pod，pod的ip和端口在service的EndPoints列表中，client访问clusterIP，通过iptables规则在转发到pod上，实现负载均衡。（k8s中查询的时候，可以把service中所有的endpoint查询出来，但是DNS只会返回service的地址，具体的转发规则是iptables决定的）

headless service：

• 有些时候，client想自己决定用哪一个pod，例如构建一个mysql集群，我们希望主节点用来读写，其他两个节点只能进行读，客户端值连接主pod的ip就可以，没必要连接集群的ip
• 或者，pod之间想要相互访问，如zk集群，eureka集群等内部需要相互通信

上述的情况，使用无头服务，headless service，因为没有clusterIP，所以DNS解析service name的时候，会返回所有的endpoint（也就是pod的地址和DNS，然后通过解析pod的DNS获得pod的IP），没有clusterIP也没办法进行负载均衡了。

访问方式一般是：

 ${podName}.${headlessServiceName}.${namespace}.${clusterDomainName}, 一般指定到headlessServiceName就可以访问了。

无头服务一般配合statefulSet使用，因为statefulSet创建出来的pod名称是固定的

        答：在某些应用场景中，若需要人为指定负载均衡器，不使用Service提供的默认负载均衡的功能，或者应用程序希望知道属于同组服务的其他实例。Kubernetes提供了Headless Service来实现这种功能，即不为Service设置ClusterIP（入口IP地址），仅通过Label Selector将后端的Pod列表返回给调用的客户端；

43、简述Kubernetes ingress?

前面了解了：Service对集群之外暴露服务的主要方式有两种：NotePort和LoadBalancer，但是这两种方式，都有一定的缺点：

• NodePort方式的缺点是占用了很多的Node端口
• LB缺点是每个service需要一个LB，资源浪费，并且需要k8s之外的设备支持。

为了解决上述问题，k8s提供了ingress资源对象，ingress只需要一个NodePort或者一个LB就可以满足暴露多个service的需求 。如下图：

实际上，ingress相当于一个7层负载均衡器，是kubernetes对反向代理的一个抽象，工作原理类似于Nginx，可以简单的理解成：ingress建立了诸多的映射规则，ingress controller 通过监听这些配置规则bin转化为Nginx的反向代理配置，然后对外提供服务。

• ingress：k8s中一种资源对象，作用是定义请求如何转发到service的规则
• ingress controller： 具体实现反向代理和负载均衡的程序。负责对ingress定义的规则进行解析，然后根据配置规则来实现请求转发，实现方式很多如Nginx，HAProxy等

ingress的工作原理（以Nginx实现方式为例）

1. 用户编写ingress规则，说明那个域名对应k8s集群中的哪个service
2. ingress controller动态感知ingress服务规则的变化，然后生成对应的Nginx反向代理配置
3. ingress controller将生成的Nginx配置写入到一个运行的Nginx服务中（这个是动态更新的 ）
4. 然后就是Nginx来工作了，Nginx将按照配置中的规则将请求转发给pod（实现HTTP层的业务路由机制），而不再经过kube-proxy

        答：K8s的Ingress资源对象，用于将不同URL的访问请求转发到后端不同的Service，以实现HTTP层的业务路由机制。K8s使用了Ingress策略和Ingress Controller，两者结合并实现了一个完整的Ingress负载均衡器。使用Ingress进行负载分发时，Ingress Controller基于Ingress规则将客户端请求直接转发到Service对应的后端Endpoint（Pod）上，从而跳过kube-proxy的转发功能，kube-proxy不再起作用，全过程为：ingress controller + ingress 规则 ----> services；

44、简述Kubernetes各模块如何与API Server通信?

API Server作为K8S集群的核心，负责集群各个功能模块之间的通信。集群各个模块通过API Server将信息存入etcd，当需要获取和操作这些数据的时候，就会通过API Server提供的rest接口实现（get，list，watch等方法），从而实现集群中各个功能模块之间的信息交互。

具体交互过程如下：

1. kubelet ：各个node节点上的kubelet每隔一定的时间，调用一次API Server的rest接口报告自身状态，API Server接收到这些信息后，会将节点状态信息更新到etcd中
2. controller-manager： 通过API Server提供的watch接口实时监控node信息，在变化的时候做出相应的处理
3. scheduler： 通过API Server提供的watch接口监听到新建pod副本的信息后，检索所有符合该pod要求的node列表，然后根据调度逻辑将分配的Node节点信息返回给apiserver。

        答：K8s API Server作为集群的核心，负责集群各功能模块之间的通信。集群内的各个功能模块通过API Server将信息存入etcd，当需要获取和操作这些数据时，则通过API Server提供的REST接口（用GET、LIST或WATCH方法）来实现，从而实现各模块之间的信息交互。1）kubelet进程与API Server的交互：每个Node上的kubelet每隔一个时间周期，就会调用一次API Server的REST接口报告自身状态，API Server在接收到这些信息后，会将节点状态信息更新到etcd中；2）kube-controller-manager进程与API Server的交互：kube-controller-manager中的Node Controller模块通过API Server提供的Watch接口实时监控Node的信息，并做相应处理；3）kube-scheduler进程与API Server的交互：Scheduler通过API Server的Watch接口监听到新建Pod副本的信息后，会检索所有符合该Pod要求的Node列表，开始执行Pod调度逻辑，在调度成功后将Pod绑定到目标节点上；

45、简述Kubernetes Scheduler作用及实现原理?

Scheduler是负责pod调度的重要模块，通过监听APIServer，发现有新的pod副本要创建时，按照特定的调度算法和调度策略为pod分配Node主机（生成一个pod绑定事件），并把这些信息返回给APIServer，通过APIServer存至etcd。随后，目标主机上的kubelet通过监听到APIServer上的pod绑定事件，接管后续的pod创建。

        答：Scheduler是负责Pod调度的重要功能模块，负责接收Controller Manager创建的新Pod，为其调度至目标Node，调度完成后，目标Node上的kubelet服务进程接管后继工作，负责Pod接下来生命周期；Scheduler的作用是将待调度的Pod，按照特定的调度算法和调度策略绑定（Binding）到集群中某个合适的Node上，并将绑定信息写入etcd中；Scheduler通过调度算法调度为待调度Pod列表中的每个Pod从Node列表中选择一个最适合的Node来实现Pod的调度。随后，目标节点上的kubelet通过API Server监听到Kubernetes Scheduler产生的Pod绑定事件，然后获取对应的Pod清单，下载Image镜像并启动容器；

46、简述Kubernetes Scheduler使用哪两种算法将Pod绑定到worker节点?

1）预选（Predicates）：输入是所有节点，输出是满足预选条件的节点。kube-scheduler根据预选策略过滤掉不满足策略的Nodes。如果某节点的资源不足或者不满足预选策略的条件则无法通过预选；

2）优选（Priorities）：输入是预选阶段筛选出的节点，优选会根据优先策略为通过预选的Nodes进行打分排名，选择得分最高的Node。例如，资源越富裕、负载越小的Node可能具有越高的排名；

59、简述Kubernetes Requests和Limits如何影响Pod的调度?

        答：当一个Pod创建成功时，Kubernetes调度器（Scheduler）会为该Pod选择一个节点来执行。对于每种计算资源（CPU和Memory）而言，每个节点都有一个能用于运行Pod的最大容量值。调度器在调度时，首先要确保调度后该节点上所有Pod的CPU和内存的Requests总和，不超过该节点能提供给Pod使用的CPU和Memory的最大容量值；

47、简述Kubernetes kubelet的作用?

k8s集群中，每个Node节点都会启动一个kubelet服务进程，用于处理master节点下发到本节点的任务，管理pod及pod中的容器。同时，每个kubectl进程都会在APIserver上注册所在节点自身的信息，定期向apiserver汇报节点资源的使用情况。（监控节点使用资源用的是cAdviser，1.8以后改用Metrics Sever）

48、简述Kubernetes如何保证集群的安全性?

1）基础设施方面：保证容器与其所在宿主机的隔离；

2）用户权限：划分普通用户和管理员的角色；

3）API Server的认证、授权：Kubernetes集群中所有资源的访问和变更都是通过Kubernetes API Server来实现的，因此需要建议采用更安全的HTTPS或Token来识别和认证客户端身份（Authentication），以及随后访问权限的授权（Authorization）环节；

4）API Server的授权管理：通过授权策略来决定一个API调用是否合法。对合法用户进行授权并且随后在用户访问时进行鉴权，建议采用更安全的RBAC方式来提升集群安全授权；

5）AdmissionControl（准入机制）：对kubernetes api的请求过程中，顺序为：先经过认证 & 授权，然后执行准入操作，最后对目标对象进行操作；

49、简述Kubernetes Secret作用?

        答：Secret对象，主要作用是保管私密数据，比如密码、OAuth Tokens、SSH Keys等信息。将这些私密信息放在Secret对象中比直接放在Pod或Docker Image中更安全，也更便于使用和分发；

50、简述Kubernetes Secret有哪些使用方式?

1）在创建Pod时，通过为Pod指定Service Account来自动使用该Secret；

2）通过挂载该Secret到Pod来使用它；

3）在Docker镜像下载时使用，通过指定Pod的spc.ImagePullSecrets来引用它，用来拉取私有仓库镜像

51、简述Kubernetes准入机制?

在对kubernetes api的请求过程中，顺序为：先经过认证 & 授权，然后执行准入控制，最后对目标对象进行操作。

准入控制：是一个可以配置的控制器列表，可以在通过命令行设置选择 需要执行哪些准入控制器；只有所有的准入控制器都检查通过后，apiserver才会执行该请求，否则整个请求的结果将会立即返回，并提示用户相应的error信息。

当前可以配置的准入控制如下：

AlwaysAdmit：允许所有请求；

AlwaysDeny：禁止所有请求，多用于测试环境；

ServiceAccount：它将serviceAccounts实现了自动化，它会辅助serviceAccount做一些事情，比如如果pod没有serviceAccount属性，它会自动添加一个default，并确保pod的serviceAccount始终存在；

LimitRanger：观察所有的请求，确保没有违反已经定义好的约束条件，这些条件定义在namespace中LimitRange对象中；

NamespaceExists：观察所有的请求，如果请求尝试创建一个不存在的namespace，则这个请求被拒绝；

在对集群进行请求时，每个准入控制代码都按照一定顺序执行。如果有一个准入控制拒绝了此次请求，那么整个请求的结果将会立即返回，并提示用户相应的error信息，准入控制（AdmissionControl）准入控制本质上为一段准入代码，。常用组件（控制代码）如下：AlwaysAdmit：允许所有请求；AlwaysDeny：禁止所有请求，多用于测试环境；ServiceAccount：它将serviceAccounts实现了自动化，它会辅助serviceAccount做一些事情，比如如果pod没有serviceAccount属性，它会自动添加一个default，并确保pod的serviceAccount始终存在；LimitRanger：观察所有的请求，确保没有违反已经定义好的约束条件，这些条件定义在namespace中LimitRange对象中；NamespaceExists：观察所有的请求，如果请求尝试创建一个不存在的namespace，则这个请求被拒绝；

52、简述Kubernetes RBAC及其特点（优势）?

RBAC（Role-Based Access Control），基于角色的访问控制。

RBAC主要包含以下概念：

Role：角色，角色定义了一组权限的集合，例如只读权限，读写权限

Subject：主体，主体是角色，可以是用户user，也可以是ServiceAccount，在实际使用中，主体通常是ServiceAccount。

RoleBinding：定义了角色和主体之间的绑定关系。
 

 --

kubernetes有role以及clusterrole两种角色，简单来说就是role受到namespace的制约，仅仅在namespace中生效，而clusterrole是对整个集群生效的。

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

53、简述Kubernetes网络模型?

kubernetes网络模型设计的一个基础原则是：每个pod都拥有一个独立的IP地址，并假定所有的Pod都在一个可以直接连通、扁平的网络空间。所以不管它们是否运行在同一个Node(宿主机)中，都要求它们可以直接通过对方的IP进行访问。用户不需要额外考虑如何建立Pod之间的联系，也不需要考虑如何将容器端口映射到主机端口问题。

在Kubernetes的世界里，IP是以Pod为单位进行分配的。一个Pod内部的所有容器共享一个网络堆栈(相当于一个网络命名空间，它们的IP地址、网络设备、配置都是共享的)。按照这网络原则抽象出来的为每个Pod都设置一个IP地址的模型也称为IP-per-Pod模型。

        答：Kubernetes网络模型中每个Pod都拥有一个独立的IP地址，不管它们是否运行在同一个Node（宿主机）中，都要求它们可以直接通过对方的IP进行访问；同时为每个Pod都设置一个IP地址的模型使得同一个Pod内的不同容器会共享同一个网络命名空间，也就是同一个Linux网络协议栈。这就意味着同一个Pod内的容器可以通过localhost来连接对方的端口；在Kubernetes的集群里，IP是以Pod为单位进行分配的。一个Pod内部的所有容器共享一个网络堆栈；

54、简述Kubernetes CNI模型?

Container Network Interface（CNI）模型，CNI定义的是容器运行环境与网络插件之间的简单接口规范，如图，容器运行环境与各种网络插件通过CNI进行连接。

CNI模型中只涉及两个概念：容器和网络，CNI仅关注在创建容器时分配网络资源，和在销毁容器时删除网络资源。

• 容器（Container）：是拥有独立Linux网络命名空间的环境，例如使用Docker或rkt创建的容器。容器需要拥有自己的Linux网络命名空间，这是加入网络的必要条件。
• 网络（Network）：表示可以互连的一组实体，这些实体拥有各自独立、唯一的IP地址，可以是容器、物理机或者其他网络设备（比如路由器）等。

        答：是对容器网络进行操作和配置的规范，通过插件的形式对CNI接口进行实现。CNI仅关注在创建容器时分配网络资源，和在销毁容器时删除网络资源。容器（Container）：是拥有独立Linux网络命名空间的环境，例如使用Docker或rkt创建的容器。容器需要拥有自己的Linux网络命名空间，这是加入网络的必要条件；网络（Network）：表示可以互连的一组实体，这些实体拥有各自独立、唯一的IP地址，可以是容器、物理机或者其他网络设备（比如路由器）等；

55、简述Kubernetes网络策略?

        答：为实现细粒度的容器间网络访问隔离策略，K8s引入Network Policy主要功能是对Pod间的网络通信进行限制和准入控制，设置允许访问或禁止访问的客户端Pod列表。Network Policy定义网络策略，配合策略控制器（Policy Controller）进行策略的实现；

56、简述Kubernetes网络策略原理?

        答：Network Policy的工作原理主要为：policy controller需要实现一个API Listener，监听用户设置的Network Policy定义，并将网络访问规则通过各Node的Agent进行实际设置（Agent则需要通过CNI网络插件实现）；

57、简述Kubernetes中flannel的作用?

1）它能协助Kubernetes，给每一个Node上的Docker容器都分配互相不冲突的IP地址；

2）它能在这些IP地址之间建立一个覆盖网络（Overlay Network），通过这个覆盖网络，将数据包原封不动地传递到目标容器内；

58、简述Kubernetes CSI模型?

Container Storage Interface（CSI），CSI是Kubernetes推出与容器对接的存储接口标准，存储提供方只需要基于标准接口进行存储插件的实现，就能使用Kubernetes的原生存储机制为容器提供存储服务，CSI使得存储提供方的代码能和Kubernetes代码彻底解耦，部署也与Kubernetes核心组件分离。

CSI Controller：主要功能是提供存储服务视角对存储资源和存储卷进行管理和操作

CSI Node：主要功能是对主机（Node）上的Volume进行管理和操作；

        答：CSI是Kubernetes推出与容器对接的存储接口标准，存储提供方只需要基于标准接口进行存储插件的实现，就能使用Kubernetes的原生存储机制为容器提供存储服务，CSI使得存储提供方的代码能和Kubernetes代码彻底解耦，部署也与Kubernetes核心组件分离；CSI包括CSI Controller：的主要功能是提供存储服务视角对存储资源和存储卷进行管理和操作；Node的主要功能是对主机（Node）上的Volume进行管理和操作；

59、标签与标签选择器的作用是什么?

标签就是给资源分类

标签选择器就是基于已经分好的类，进行选择（等值关系、集合关系）

1）标签可以附加在kubernetes任何资源对象之上的键值型数据，常用于标签选择器的匹配度检查，从而完成资源筛选；

2）标签选择器用于表达标签的查询条件或选择标准，Kubernetes API目前支持两个选择器：基于等值关系（equality-based）的标签选项器以及基于集合关系（set-based）的标签选择器；

60、常用的标签分类有哪些?

        答：release（版本）：stable（稳定版）、canary（金丝雀版本）、beta（测试版本）、environment（环境变量）：dev（开发）、qa（测试）、production（生产）、application（应用）：ui、as（application software应用软件）、pc、sc、tier（架构层级）：frontend（前端）、backend（后端）、cache（缓存）、partition（分区）：customerA（客户A）、customerB（客户B）、track（品控级别）：daily（每天）、weekly（每周）；

61、pod的共享资源？

        答：1）PID 命名空间：Pod 中的不同应用程序可以看到其他应用程序的进程 ID；2）网络命名空间：Pod 中的多个容器能够访问同一个IP和端口范围；3）IPC 命名空间：Pod 中的多个容器能够使用 SystemV IPC 或 POSIX 消息队列进行通信；4）UTS 命名空间：Pod 中的多个容器共享一个主机名；5）Volumes（共享存储卷）：Pod 中的各个容器可以访问在 Pod 级别定义的 Volumes；

62、说说你对Job这种资源对象的了解?

job也是一种pod控制器，它创建出来的pod只要完成任务就立即退出，不需要重启或重建，用于执行一次性任务（1当Job创建的pod执行成功结束时，Job将记录成功结束的pod数量，2当成功结束的pod达到指定的数量时，Job将完成执行）

cronjob: 以job为管控对象，可以在特定的时间点(周期性任务)去运行job任务。

        答：Job控制一组Pod容器，可以通过Job这种资源对象定义并启动一个批处理任务的Job，其中Job所控制的Pod副本是短暂运行的，可以将其视为一组Docker容器，每个Docker容器都仅仅运行一次，当Job控制的所有Pod的副本都运行结束时，对应的Job也就结来。Job生成的副本是不能自动重启的，对应的Pod副本的RestartPolicy都被设置为Never。Job所控制的Pod副本的工作模式能够多实例并行计算。

63、 k8s是怎么进行服务注册的?

1. 向apiserver提交service信息
2. coreDNS为这个service创建一个DNS记录，service得到一个clusterIP（虚拟的IP）并通过apiserver保存到etcd中
3. 集群范围内传播这个service配置

        答：1）Service创建的时候会向 API Server 用 POST 方式提交一个新的 Service 定义，这个请求需要经过认证、鉴权以及其它的准入策略检查过程之后才会放行；2）CoreDns 会为Service创建一个dns记录，Service 得到一个 ClusterIP（虚拟 IP 地址），并保存到集群数据仓库；3）在集群范围内传播 Service 配置；

64、什么是Container Orchestration容器编排?

资源编排 --- 负责资源分配， 如scheduler计算pod应该调度到那个node

负载编排 --- 资源之间共享工作的负载

服务编排 --- 服务发现和高可用，如服务负载均衡等

        答：1）资源编排 - 负责资源的分配，如限制 namespace 的可用资源，scheduler 针对资源的不同调度策略；2）工作负载编排 - 负责在资源之间共享工作负载，如 Kubernetes 通过不同的 controller 将 Pod 调度到合适的 node 上，并且负责管理它们的生命周期；3）服务编排 - 负责服务发现和高可用等，如 Kubernetes 中可用通过 Service 来对内暴露服务，通过 Ingress 来对外暴露服务；容器编排常用的控制器有：Deployment 经常被作为无状态实例控制器使用; StatefulSet 是一个有状态实例控制器; DaemonSet 可以指定在选定的 Node 上跑，每个 Node 上会跑一个副本，它有一个特点是它的 Pod 的调度不经过调度器，在 Pod 创建的时候就直接绑定 NodeName；最后一个是定时任务，它是一个上级控制器，和 Deployment 有些类似，当一个定时任务触发的时候，它会去创建一个 Job ，具体的任务实际上是由 Job 来负责执行的；

65、无头服务，headless service

1、普通service和无头service的区别？

• service：一组pod的访问策略，提供cluster-ip 集群之间的通讯，也支持负载均衡 --- 支持负载均衡（因此一般只会转发到一个pod上）
• headless service：clusterIP为None的service，直接绑定具体的Pod的IP---不需要支持负载均衡，用于有状态的中间件部署。（转发给所有的pod）

2、无头service的应用场景？

• 有状态中间件部署场景 --- headless service一个很重要的场景是发现所有的pod（包括未就绪的pod），虽然只有ready状态的pod可以通过服务，但是有些时候也需要发现那些没有就绪的pod，比如zk集群，zk节点的pod必须相互识别之后进行选举，pod状态才会变成就绪，headless service就完美的解决了这个问题
• 不需要负载均衡时 ---- 有些场景不需要提供负载均衡（还比如zk集群，想把所有数据写入到中心站点时）

K8S面试题总结_云原生_孤独天狼-DevPress官方社区