[TOC]
### **Pod的三种重启策略**
在Pod的spec中有一个restartPolicy字段,如下:
```
apiVersion: v1
kind: Pod
metadata:
name: xxx
spec:
restartPolicy: Always
...
```
restartPolicy的值有三个:Always、OnFailure、Never;默认值为Always。
**注意:虽然restartPolicy字段是Pod的配置,但是其实是作用于Pod的Container,换句话说,不应该叫Pod的重启策略,而是叫Container的重启策略;Pod中的所有Container都适用于这个策略。**
三种策略的区别在于(参考Reference 2的回答):
* Always:只要Container退出,就重启,即使用它的退出码为0(即成功退出)
* OnFailure:如果Container的退出码不是0(即失败退出),就重启
* Never:Container退出后永不重启
所谓Container的退出码,就是Container中进程号为1的进程的退出码。每个进程退出时都有一个退出码,我们常见的提示`exit 0`表示退出码为0(即成功退出)。举个例子:shell命令`cat /tmp/file`,如果文件`/tmp/file`存在,则该命令(进程)的退出码为0。
### **重启Container**
上面谈到当Container退出后,Container可能会被重启,那么Container是如何被重启的呢?是kubelet调用类似于docker start的API拉起?还是重新创建一个docker容器?
答案是,kubelet会重新创建一个docker容器。
我们给一个例子,创建一个如下的Pod,这个Pod中有两个Container,其中`linzhe`这个Container在启动后60秒就会退出(退出码为0),`shizhu`这个Container则会一直运行
```
apiVersion: v1
kind: Pod
metadata:
name: peng
spec:
restartPolicy: Always
containers:
- name: linzhe
image: tomcat:8
command:
- /bin/sh
- -c
- sleep 60
- name: shizhu
image: tomcat:8
```
接下来我们创建这个Pod,然后观察`linzhe`这个Container的docker名字与ID,发现名字为`k8s_linzhe_peng_default_2cf74016-f80f-47b8-bd77-f7c96a02fa3b_0`,ID为`557818a3da5c`
```
$ docker ps | grep linzhe
557818a3da5c 3d793e2e777b "/bin/sh -c 'sleep 6…" 8 seconds ago Up 6 seconds k8s_linzhe_peng_default_2cf74016-f80f-47b8-bd77-f7c96a02fa3b_0
```
再过一分钟,我们再看这个Container的名字和ID,发现名字为`k8s_linzhe_peng_default_2cf74016-f80f-47b8-bd77-f7c96a02fa3b_1`,ID为`7ec6c5d33dd7`。这说明,重启后已经不是同一个docker容器了。
```
$ docker ps | grep linzhe
7ec6c5d33dd7 3d793e2e777b "/bin/sh -c 'sleep 6…" 37 seconds ago Up 35 seconds k8s_linzhe_peng_default_2cf74016-f80f-47b8-bd77-f7c96a02fa3b_1
```
如果我们细心的会发现,docker容器的名字其实是有规则的,为`k8s_<ContainerName_In_Pod>_<PodName>_<Namespace>_<PodID>_<Index>`;其中最后一个`<Index>`一开始为0,每重启一次就会递增1。
如果同时我们查看Pod的yaml文件,会发现这个Container的restartCount为1
```
$ kubectl get pod peng -o yaml
...
status:
...
containerStatuses:
- containerID: docker://7ec6c5d33dd7ad6f04824a37a4bb02639ecc71e0e5921bc53dbc2e610b2381fc
...
name: linzhe
ready: false
restartCount: 1
started: false
```
如果再等几分钟,查看Pod的状态,会变成`CrashLoopBackOff`
```
$ kubectl get pod peng
NAME READY STATUS RESTARTS AGE
peng 1/2 CrashLoopBackOff 5 11m
```
### **最佳实践**
一般Pod是通过工作负载去管理的,在五种工作负载中,一般建议:Deployment、StatefulSet、DaemonSet设置为Always;Job与CronJob设置为OnFailure或Never
### **Reference**
* https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy
* https://stackoverflow.com/questions/40530946/what-is-the-difference-between-always-and-on-failure-for-kubernetes-restart-poli
- 常用命令
- 安装
- 安装Kubeadm
- 安装单Master集群
- 安装高可用集群(手动分发证书)
- 安装高可用集群(自动分发证书)
- 启动参数解析
- certificate-key
- ETCD相关参数
- Kubernetes端口汇总
- 安装IPv4-IPv6双栈集群
- 下载二进制文件
- 使用Kata容器
- 快速安装shell脚本
- 存储
- 实践
- Ceph-RBD实践
- CephFS实践
- 对象存储
- 阿里云CSI
- CSI
- 安全
- 认证与授权
- 认证
- 认证-实践
- 授权
- ServiceAccount
- NodeAuthorizor
- TLS bootstrapping
- Kubelet的认证
- 准入控制
- 准入控制示例
- Pod安全上下文
- Selinux-Seccomp-Capabilities
- 给容器配置安全上下文
- PodSecurityPolicy
- K8S-1.8手动开启认证与授权
- Helm
- Helm命令
- Chart
- 快速入门
- 内置对象
- 模板函数与管道
- 模板函数列表
- 流程控制
- Chart依赖
- Repository
- 开源的Chart包
- CRD
- CRD入门
- 工作负载
- Pod
- Pod的重启策略
- Container
- 探针
- 工作负载的状态
- 有状态服务
- 网络插件
- Multus
- Calico+Flannel
- 容器网络限速
- 自研网络插件
- 设计文档
- Cilium
- 安装Cilium
- Calico
- Calico-FAQ
- IPAM
- Whereabouts
- 控制平面与Pod网络分开
- 重新编译
- 编译kubeadm
- 编译kubeadm-1.23
- 资源预留
- 资源预留简介
- imagefs与nodefs
- 资源预留 vs 驱逐 vs OOM
- 负载均衡
- 灰度与蓝绿
- Ingress的TLS
- 多个NginxIngressController实例
- Service的会话亲和
- CNI实践
- CNI规范
- 使用cnitool模拟调用
- CNI快速入门
- 性能测试
- 性能测试简介
- 制作kubemark镜像
- 使用clusterloader2进行性能测试
- 编译clusterloader2二进制文件
- 搭建性能测试环境
- 运行density测试
- 运行load测试
- 参数调优
- Measurement
- TestMetrics
- EtcdMetrics
- SLOMeasurement
- PrometheusMeasurement
- APIResponsivenessPrometheus
- PodStartupLatency
- FAQ
- 调度
- 亲和性与反亲和性
- GPU
- HPA
- 命名规范
- 可信云认证
- 磁盘限速
- Virtual-kubelet
- VK思路整理
- Kubebuilder
- FAQ
- 阿里云日志服务SLS