2.5 生命周期、重启策略及健康检查
详情参考： 《k8s教程（pod篇）-生命周期、重启策略及健康检查》
Pod的生命周期：
| 状态值 | 描述 |
| Pending | API Server已经创建了pod，但在pod内还有一个或多个容器的镜像没有创建，包括正在下载镜像的过程 |
| Running | pod内所有容器均已创建，且至少有一个容器处于运行状态、正在启动状态或正在重启状态 |
| Succeeded | pod内所有容器均成功执行后退出，且不会在重启 |
| Failed | pod内所有容器均已退出，但至少有一个容器为退出失败状态 |
| Unknown | 由于某种原因无法获取该Pod的状态，可能由于网络通信不畅导致的 |
Pod的重启策略：当某个容器异常退出或者健康检查 失败时，kubelet将根据RestartPolicy的设置进行相应的操作，pod的重启策略包括Always、OnFailure和Never（默认值为Always）：
| 重启策略 | 描述 |
| Always | 当容器失效时，由kubelet自动重启该容器 |
| OnFailure | 当容器终止运行且退出码不为0时，由kubelet自动重启该容器 |
| Never | 不论容器运行状态如何，kubelet都不会重启该容器 |
Pod健康检查：Kubernetes对Pod的健康状态可以通过三类探针来检查：LivenessProbe、ReadinessProbe及StartupProbe，其中最主要的探针为LivenessProbe与ReadinessProbe，kubelet会定期执行这两类探针来诊断容器的健康状况。
| 探针 | 作用 |
| LivenessProbe探针 | 用于判断容器是否存活(Running状态)，如果LivenessProbe探针探测到容器不健康，则kubelet“将“杀掉”该容器，并根据容器的重启策略做相应的处理。如果一个容器不包含LivenessProbe探针，那么kubelet认 为该容器的LivenessProbe探针返回的值永远是Success |
| ReadinessProbe探针 | 用于判断容器服务是否可用(Ready状态)，达到Ready状态的Pod才可以接收请求。对于被Service管理的Pod、Service与PodEndpoint的关联关系也将基于Pod是否Ready进行设置。如果在运行过程中Ready 状态变为False，则系统自动将其从Service的后端Endpoint列表中隔离出去，后续再把恢复到Ready状态的Pod加回后端Endpoint列表。这样就能保证客户端在访问Service时不会被转发到服务不可用的Pod实例上。需要注意的是ReadinessProbe也是定期触发执行的，存在于Pod的整个生命周期中 |
| StartupProbe探针 | 某些应用会遇到启动比较慢的情况，例如应用程序启动时需要与远程服务器建立网络连接，或者遇到网络访问较慢等情况时，会造成容器启动缓慢，此时ReadinessProbe就不适用了，因为这属于“有且仅有一次” 的超长延时，可以通过StartupProbe探针解决该问题 |
2.6 pod调度
详情参考：
- 《k8s教程（pod篇）-调度概述》
- 《k8s教程（pod篇）-全自动调度》
- 《k8s教程（pod篇）-定向调度》
- 《k8s教程（pod篇）-node亲和性调度》
- 《k8s教程（pod篇）-亲和性与互斥性调度》
- 《k8s教程（pod篇）-污点与容忍》
- 《k8s教程（pod篇）-优先级调度》
- 《k8s教程（pod篇）-DaemonSet（每个node上只调度一个pod）》
- 《k8s教程（pod篇）-批处理调度》
- 《k8s教程（pod篇）-定时任务》
- 《k8s教程（pod篇）-容灾调度》
之前已经写了总结了，可以参考： 《k8s教程（pod篇）-调度总结》
2.7 初始化容器
详情参考：《k8s教程（pod篇）-初始化容器》
init container(初始化容器)，用于在启动应用容器（app container)之前启动一个或多个初始化容器，完成应用容器所需的预置条件。
下面以nginx应用为例，在启动nginx之前，通过初始化容器busybox，为nginx 创建一个index.html主页文件：
apiversion: v1 kind: Pod metadata: name: nginx annotations: spec: # These containers are run during pod initialization initContainers: - name: install image: busybox command: - wget -"-o" -"/work-dir/index.html" - http://kubernetes.io volumeMounts: - name: workdir mountPath: "/work-dir" containers: - name: nginx image: nginx ports: - containerPort: 80 volumeMounts: - name: workdir mountPath: /usr/share/nginx/html dnsPolicy: Default volumes: - name: workdir emptyDir: {}
创建完成后，在运行init container的过程中查看Pod的状态，可见init过程还未完成：
$ kubectl create -f nginx-init-containers.yaml pod "nginx"created $ kubectl get pods NAME READY STATUS RESTARTS AGE nginx 0/1 Init:0/1 0 1m
在init container成功运行完成后，系统继续启动Nginx容器，再次查看Pod的状态：
$ kubectl get pods NAME READY STATUS RESTARTS AGE nginx 1/1 Running 0 7s
查看Pod的事件，可以看到系统首先创建并运行init container容器（名为install)，成功后继续创建和运行Nginx容器。
2.8 升级与回滚
详情参考：《k8s教程（pod篇）-升级与回滚》
Pod的升级方式有两种：
- 通过kubectl set image命令为Deployment设置新的镜像名称
- 使用kubectl edit命令修改Deployment的配置，将
spec.template.spec.containers[0].image从nginx: 1.7.9更改为nginx:1.9.1
Pod的回滚方式：
- 撤销本次发布并回滚到上一个部署版本：
Pod暂停和恢复Deployment操作：
- 通过kubectl rollout pause命令暂停Deployment的更新操作:
- 修改完后，恢复这个Deployment的部署操作：
2.9 扩缩容
详情参考： 《k8s教程（pod篇）-扩缩容》
Pod扩缩容分为两种：
- 手动扩缩容：例如通过kubectl scale命令可以将Pod副本数量从初始的3个更新为5个
- 自动扩缩容：使用HPA控制器，用于实现基于CPU使用率进行自动Pod扩缩容的功能，详情查看 《k8s教程（pod篇）-扩缩容》。
2.10 使用StatefulSet搭建MongoDB集群
详情参考： 《k8s教程（pod篇）-使用StatefulSet搭建MongoDB集群》
原理图如下：
为了完成MongoDB集群的搭建，需要部署以下三个资源对象，分别为：
- StorageClass：用于StatefulSet自动为各个应用Pod申请PVC；
- Headless Service：用于设置MongoDB实例的域名；
- StatefulSet
详情查看原文：《k8s教程（pod篇）-使用StatefulSet搭建MongoDB集群》
03 文末
本文主要总结了前段时间对k8s pod的知识点整理，希望能帮助到大家，谢谢大家的阅读，本文完！
