简介
Pod在整个生命周期中被系统定义为各种状态，熟悉Pod的各种状态对于理解如何设置Pod的调度策略，重启策略很有必要
1. Pod的状态
-
Pending
API Server已经创建Pod 但在Pod内还有一个或多个的镜像没有创建，包括正在下载镜像的过程。 -
Running
Pod内所有容器已经创建完成，且至少有一个容器处于运行状态 -
Successded
Pod内所有容器均成功执行退出，并且不会再重启 -
Faild
Pod内所有容器均已退出，但至少有一个容器为退出失败状态
2. Pod重启策略
Pod的重启策略应用于Pod内所有的容器，并且仅在Pod所处的Node上由kubelet进行判断和重启操作
重启策略
- Always： 总是重启；当容器失效时，由kubelete自动重启该容器，默认值
- OneFailure：当容器终止运行且退出码不为0时候，由kubelete自动重启该容器
- Never：不论容器运行状态如何都不会重启该容器,Job或CronJob
配置在spec与containers同级中
........
containers:
- name: tomcat-app1-container
image: harbor.magedu.local/tomcat-app1:v1
command: ["/apps/tomcat/bin/run_tomcat.sh"]
imagePullPolicy: IfNotPresent
#imagePullPolicy: Always
ports:
- containerPort: 8080
protocol: TCP
name: http
env:
- name: "password"
value: "123456"
resources:
limits:
cpu: 1
memory: "512Mi"
requests:
cpu: 500m
memory: "512Mi"
restartPolicy: Always #重启策略
3. Pod探针
Pod健康检查和服务可用性检查
Kubernetes对Pod的健康检查可以通过两类探针检查LivenessProbe，ReadinessProbe，kubelet定期执行这两类探针来诊断容器的监控状态
-
LivenessProber探针
用于判断容器是否存活(Running状态)，如果LivenessProbe探针探测到容器不健康，则kubelete将杀掉该容器，并根据容器的重启策略做相应的处理，如果一个容器不包含LivenessProbe探针，那么kubelet认为该容器的LivenessProbe弹指值返回永远时Seccess -
ReadinessProbe探针
用于判断容器服务是否可用(Ready状态)，达到Ready状态的Pod才可以接受请求，流量可以接入。对于service管理的Pod service与Pod Endpoint的关联关系也会将基于Pod是否Ready进行设置
3.1 探针的探测方式
-
ExecAction
在容器内执行一个命令，如果该命令的返回值为0 则表明容器健康 -
TCPSocketActio
通过容器的IP地址和端口号执行TCP检
查，如果能够建立TCP连接，则表明容器健康 -
HTTPGetAction
通过容器的IP地址，端口号及路径调用Http Get方法，如果状态码大于等于200且小于400，则认为容器健康
生产建议使用此方法调用你的程序接口进行检测
3.2 配置方式
辅助探测的其它配置项目
-
initialDelaySeconds: 5 #启动容器后的多长时间进行探测
-
periodSeconds: 3 #间隔多长时间执行一次探测
-
timeoutSeconds: 5 #探测超时等待多少秒进行下一次探测
-
successThreshold: 1 #从失败转为成功的重试次数，探测器在失败后，被视为成功的最小连续成功数，默认值是1，存活探测的这个值必须是1，最小值是 1
-
failureThreshold: 3 #从成功转为失败的重试次数，当Pod启动了并且探测到失败，Kubernetes的重试次数，存活探测情况下的放弃就意味着重新启动容器，就绪探测情况下的放弃Pod 会被打上未就绪的标签，默认值是3，最小值是1
HttpGet探针
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 1
selector:
matchLabels: #rs or deployment
app: ng-deploy-80
template:
metadata:
labels:
app: ng-deploy-80
spec:
containers:
- name: ng-deploy-80
image: nginx:1.17.5
ports:
- containerPort: 80
livenessProbe:
httpGet:
path: /index.html
port: 80
initialDelaySeconds: 5 #启动容器后的多长时间进行探测
periodSeconds: 3 #间隔多长时间执行一次探测
timeoutSeconds: 5 #探测超时等待多少秒进行下一次探测
successThreshold: 1 #从失败转为成功的重试次数，探测器在失败后，被视为成功的最小连续成功数，默认值是1，存活探测的这个值必须是1，最小值是 1
failureThreshold: 3 #从成功转为失败的重试次数，当Pod启动了并且探测到失败，Kubernetes的重试次数，存活探测情况下的放弃就意味着重新启动容器，就绪探测情况下的放弃Pod 会被打上未就绪的标签，默认值是3，最小值是1
kubelet定时发送HTTP请求到 localhost:80/index.html 来进行容器应用的健康检查
TcpSocket探针
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 1
selector:
matchLabels: #rs or deployment
app: ng-deploy-80
template:
metadata:
labels:
app: ng-deploy-80
spec:
containers:
- name: ng-deploy-80
image: nginx:1.17.5
ports:
- containerPort: 80
livenessProbe:
tcpSocket:
port: 80
initialDelaySeconds: 5
periodSeconds: 3
timeoutSeconds: 5
successThreshold: 1
failureThreshold: 3
ExecAction探针
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 1
selector:
matchLabels: #rs or deployment
app: ng-deploy-80
template:
metadata:
labels:
app: ng-deploy-80
spec:
containers:
- name: ng-deploy-80
image: nginx:1.17.5
ports:
- containerPort: 80
livenessProbe:
exec:
command:
- cat
- /root/
initialDelaySeconds: 5
periodSeconds: 3
timeoutSeconds: 5
successThreshold: 1
failureThreshold: 3
3.2 livenessProbe和readinessProbe的对比
配置参数一样
-
livenessProbe 连续探测失败会重启、重建pod，readinessProbe不会执行重启或者重建Pod操作
-
livenessProbe 连续检测指定次数失败后会将容器置于(Crash Loop BackOff)且不可用，readinessProbe不
会 -
readinessProbe 连续探测失败会从service的endpointd中删除该Pod，livenessProbe不具备此功能，但是会将容器挂起livenessProbe
-
livenessProbe用户控制是否重启pod，readinessProbe用于控制pod是否添加至service
建议：
两个探针都配置
4. 镜像拉取策略
-
imagePullPolicy: IfNotPresent
node节点没有此镜像就去指定的镜像仓库拉取，node有就使用node本地镜像。 -
imagePullPolicy: Always
每次重建pod都会重新拉取镜像 -
imagePullPolicy: Never
从不到镜像中心拉取镜像，只使用本地镜像