一、配置探针
kubernetes 提供了三种探针（支持exec、tcp和http方式）来探测容器的状态：
LivenessProbe： 容器存活性检查，用于判断容器是否健康，告诉 kubelet 一个容器什么时候处于不健康的状态。如果 LivenessProbe 探针探测到容器不健康，则 kubelet 将删除该容器，并根据容器的重启策略做相应的处理。如果一个容器不包含 LivenessProbe 探针，那么 kubelet 认为该容器的 LivenessProbe 探针返回的值永远是 Success；
ReadinessProbe： 容器就绪性检查，用于判断容器是否启动完成且准备接收请求。如果ReadinessProbe探针探测到失败，Endpoint Controller 将从 Service 的 Endpoint 中删除包含该容器所在 Pod 的 IP 地址的Endpoint条目。如果容器不提供就绪态探针，则默认状态为 Success。
startupProbe:
容器启动检查，探测容器中的应用是否已经启动。如果提供了启动探针，则所有其他探针都会被禁用，直到此探针成功为止。如果启动探测失败，kubelet 将杀死容器，而容器按照重启策略进行重启。 如果容器没有提供启动探测，则默认状态为 Success。
探针的配置非常灵活，用户可以指定探针的探测频率、探测成功阈值、探测失败阈值等。各参数的含义和配置方法可参考文档 Configure Liveness and Readiness Probes。
1.1、exec命令型：
livenessProbe:
exec:
command:
- curl
- 127.0.0.1:8000
initialDelaySeconds: 5 #第一次探测时等待5s
periodSeconds: 5 #每5s执行一次
failureThreshold: 2 #失败的阈值
successThreshold: 1 #成功一次表示正常
timeoutSeconds: 5 # 执行检查指令的超时时间
readinessProbe:
exec: #退出0 表示成功
command:
- curl
- 127.0.0.1:8000
initialDelaySeconds: 5 #第一次探测时等待5s
periodSeconds: 5 #每5s执行一次
failureThreshold: 2 #失败的阈值
successThreshold: 1 #成功的阈值
timeoutSeconds: 3 #单次执行超时的时间1.2、http型
livenessProbe:
httpGet:
path: /
port: 8000
scheme: HTTP # 返回200表示正常
initialDelaySeconds: 5 #第一次探测时等待5s
periodSeconds: 5 #每5s执行一次
failureThreshold: 2 #失败的阈值
successThreshold: 1 #成功的阈值
timeoutSeconds: 3 #单次执行超时的时间
readinessProbe:
httpGet:
path: /
port: 8000
scheme: HTTP
initialDelaySeconds: 5 #第一次探测时等待5s
periodSeconds: 5 #每5s执行一次
failureThreshold: 2 #失败的阈值
successThreshold: 1 #成功的阈值
timeoutSeconds: 3 #单次执行超时的时间1.3、tcp型
livenessProbe:
tcpSocket:
port: 8000
initialDelaySeconds: 5 #第一次探测时等待5s
periodSeconds: 5 #每5s执行一次
failureThreshold: 2 #失败的阈值
successThreshold: 1 #成功的阈值
timeoutSeconds: 3 #单次执行超时的时间
readinessProbe:
tcpSocket:
port: 8000
initialDelaySeconds: 5 #第一次探测时等待5s
periodSeconds: 5 #每5s执行一次
failureThreshold: 2 #失败的阈值
successThreshold: 1 #成功的阈值
timeoutSeconds: 3 #单次执行超时的时间1.4、startup案例
livenessProbe:
httpGet:
path: /test
prot: 80
failureThreshold: 1
initialDelay：10
periodSeconds: 10
startupProbe:
httpGet:
path: /test
prot: 80
failureThreshold: 10
initialDelay：10
periodSeconds: 10注意点：上面的配置是只有startupProbe探测成功后再交给livenessProbe。
我们startupProbe配置的是10*10s，也就是说只要应用在100s内启动都是OK的，而且应用挂掉了10s就会发现问题。
例子：
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 2
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: python
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8000
args:
- "python"
- "-m"
- "http.server"
livenessProbe:
httpGet:
path: /
port: 8000
scheme: HTTP
initialDelaySeconds: 5 #第一次探测时等待5s
periodSeconds: 5 #每5s执行一次
failureThreshold: 2 #失败的阈值
successThreshold: 1 #成功的阈值
timeoutSeconds: 3 #单次执行超时的时间
readinessProbe:
httpGet:
path: /
port: 8000
scheme: HTTP
initialDelaySeconds: 5 #第一次探测时等待5s
periodSeconds: 5 #每5s执行一次
failureThreshold: 2 #失败的阈值
successThreshold: 1 #成功的阈值
timeoutSeconds: 3 #单次执行超时的时间二、minReadySeconds
minReadySeconds参数用于控制pod在running状态后，到真正上线之间的观察时间。
默认情况下，一旦新创建的 pod 变成就绪状态 k8s 就会认为该 pod 是可用的，从而将老的 pod 删除掉。但有时问题可能会在新 pod 真正处理用户请求时才暴露，因此一个更稳健的做法是设置合理的minReadySeconds参数值，当某个新 pod 就绪后对其观察一段时间再删掉老的 pod。
apiVersion: apps/v1
kind: Deployment
metadata:
name: busybox
spec:
minReadySeconds: 10
strategy:
rollingUpdate:
maxUnavailable: 1
maxSurge: 1
selector:
matchLabels:
app: busybox
replicas: 2
template:
metadata:
labels:
app: busybox
spec:
terminationGracePeriodSeconds: 60
containers:
- name: busybox
image: busybox:1.31.0
command: ["/bin/sh", "-c", "sleep 3600"]三、terminationGracePeriodSeconds
定义优雅关闭的宽限期，即在收到停止请求后，有多少时间来进行资源释放或者做其它操作，如果到了最大时间还没有停止，会被强制结束。（默认 30 秒）
验证：
apiVersion: apps/v1
kind: Deployment
metadata:
name: busybox
spec:
minReadySeconds: 10
strategy:
rollingUpdate:
maxUnavailable: 1
maxSurge: 1
selector:
matchLabels:
app: busybox
replicas: 2
template:
metadata:
labels:
app: busybox
spec:
terminationGracePeriodSeconds: 60
containers:
- name: busybox
image: busybox:1.31.0
command: ["/bin/sh", "-c", "sleep 3600"]
