本篇及此系列文章只针对面试相关问题做了简单总结,后续会出比较详细的系列文章....
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的节点,但不强求,多个优先级规则还可以设置权重值。
- Taints和Tolerations(污点和容忍)
- Taint:Node属性,表示Node拒绝特定Pod运行;
- Toleration:Pod的属性,表示Pod能容忍运行在标注了Taint的Node上。
8. kubernetes的Replication Controller机制
Replication Controller用来管理Pod的副本,保证集群中存在指定数量的Pod副本。当定义了RC并提交至k8s集群之后,master节点上的controller-manager组件得到消息,巡检系统中当前存活的目标pod,并确保目标pod的存活数量符合期望值。
上一篇: kubernetes 初探