Kubernetes探索-Pod面试

置顶 TanYoung@t

已于 2024-03-31 13:02:31 修改

阅读量2.4k

点赞数 59

分类专栏： Kubernetes 文章标签： kubernetes 云原生面试

于 2024-03-29 10:44:47 首次发布

本文链接：https://blog.csdn.net/Guaike0210/article/details/137134333

版权

Kubernetes 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

本篇及此系列文章只针对面试相关问题做了简单总结，后续会出比较详细的系列文章....

1. 创建Pod的底层逻辑

1）创建单个Pod时：组件间的交互流程和描述如下图，该过程中controller-manager组件不工作。

流程描述

① 客户端提交创建请求【通过 api-server 的restful 接口或kubectl 命令行工具，支持JSON 和 YAML】

② api-server 处理用户请求，将 pod 信息存储至 etcd 中；

③ kube-scheduler 通过 api-server 接口监测到未绑定的 pod，尝试为 pod 分配 node 节点；

        两阶段进行：预选阶段和优选阶段

                预选阶段：遍历所有的 node 节点，根据策略筛选出候选节点；

                优选阶段：为预选阶段所选的候选节点进行打分，取分数最高者；

④ 选出最优节点后，进行 pod绑定操作，并将结果存储至 etcd 中；

⑤ 目标节点的 kubelet 进程通过 api-server 接口监测到 pod绑定事件，从 etcd 获取 pod 清单，下载镜像并启动容器；

⑥ kubelet通过接口上报pod状态给api-server，api-server更新etcd资源信息

2）创建Deployment时：组件间的交互流程和描述如下图：

流程描述

① 客户端提交创建请求【通过 api-server 的restful 接口或kubectl 命令行工具，支持JSON 和 YAML】

② api-server 验证并存储deployment信息到 etcd 数据中心；

③ + ④ deployment-controller通过api-server监测到新deployment对象创建，则创建一个replicaset对象并存储到etcd数据中心；

⑤+⑥ replicaset-controller通过api-server监测到新replicaset对象创建，则基于配置信息创建指定数量的pod副本；

⑦ kube-scheduler 通过 api-server 接口监测到未绑定的 pod，尝试为 pod 分配 node 节点；

        两阶段进行：预选阶段和优选阶段

                预选阶段：遍历所有的 node 节点，根据策略筛选出候选节点；

                优选阶段：为预选阶段所选的候选节点进行打分，取分数最高者；

⑧ 选出最优节点后，进行 pod绑定操作，并将结果存储至 etcd 中；

⑨ 目标节点的 kubelet 进程通过 api-server 接口监测到 pod绑定事件，从 etcd 获取 pod 清单，下载镜像并启动容器；

⑩ kubelet通过接口上报pod状态给api-server，api-server更新etcd资源信息

2. Pod的运行状态有哪些？

Pending：API Server已经创建该Pod，且Pod内还有一个或多个容器的镜像没有创建，包括正在下载镜像的过程。
Running：Pod内所有容器均已创建，且至少有一个容器处于运行状态、正在启动状态或正在重启状态。
Succeeded：Pod内所有容器均成功执行退出，且不会重启。
Failed：Pod内所有容器均已退出，但至少有一个容器退出为失败状态。
Unknown：由于某种原因无法获取该Pod状态，可能由于网络通信不畅导致。

3. 什么是静态Pod？

由kubelet创建，存在于特定node上的无法进行健康检查的pod；
不能通过api-server进行管理；
无法与Replication Controller，Deployment或者DaemonSet进行关联

4. Pod的重启策略有哪些？

作用：重启策略应用于Pod内的所有容器，当pod内的某容器异常退出/健康检测失败时，kubelet会根据重启策略完成相应操作；
重启策略
- Always(default)：当容器失效时，由kubelet自动重启该容器
- OnFailure：当容器终止运行且退出码不为0时，由kubelet自动重启该容器；
- Never：不论容器运行状态如何，kubelet都不会重启该容器
重启策略与控制方式（Replication Controller，Job，DaemonSet和kubelet）关联
- Replication Controller和DaemonSet：必须设置为Always，需要保证该容器持续运行；
- Job：OnFailure或Never，确保容器执行完成后不再重启；
- kubelet：在Pod失效时重启，不论将RestartPolicy设置为何值，也不会对Pod进行健康检查。

5. Pod的健康检查方式

kubernetes提供三类Probe（探针），kubelet会定期执行探针检测Pod的健康状态。

LivenessProbe探针：判断容器是否存活（running状态），如果LivenessProbe探针探测到容器不健康，kubelet将杀掉该容器，并根据容器的重启策略做相应处理。若一个容器不包含LivenessProbe探针，kubelet认为该容器的LivenessProbe探针返回值用于是“Success”。
ReadineeProbe探针：用于判断容器是否启动完成（ready状态）。如果ReadinessProbe探针探测到失败，Pod的状态将被修改。Endpoint Controller将从Service的Endpoints中删除包含该容器所在Pod的Eedpoint。
StartupProbe探针：启动检查机制，应用一些启动缓慢的业务，避免业务长时间启动而被上面两类探针kill掉。

6. LivenessProbe探针的实现方式

ExecAction：在容器内执行一个命令，若返回码为0，则表明容器健康。
TCPSocketAction：通过容器的IP地址和端口号执行TCP检查，若能建立TCP连接，则表明容器健康。
HTTPGetAction：通过容器的IP地址、端口号及路径调用HTTP-Get方法，若响应的状态码大于等于200且小于400，则表明容器健康。

7. Pod的常见调度方式

常见的Pod调度方式有以下四种:

Deployment或Replication Controller：自动部署一个容器应用的多份副本，持续监控副本的数量，在集群内始终维持用户指定的副本数量。
NodeSelector：定向调度，当需要将Pod调度到特定Node上时，可以通过Node的标签（Label）和 Pod的nodeSelector属性相匹配。
NodeAffinity亲和性调度：亲和性调度机制极大的扩展了Pod的调度能力，目前有两种节点亲和力表达式。

requiredDuringSchedulingIgnoredDuringExecution：硬规则，必须满足指定的规则，调度器才可以调度Pod至Node上（类似nodeSelector）
preferredDuringSchedulingIgnoredDuringExecution：软规则，优先调度至满足的Node的节点，但不强求，多个优先级规则还可以设置权重值。