K8s配置应用的滚动更新与启动、就绪和存活三种探针

完整的滚动更新与探针配置参考test-shushi-os.yml, hexo以静态资源的方式引用YAML文件会导致这个文件被强行转换成JSON, 所以在文章末尾以代码块的方式引入

K8s配置滚动更新

Kubernetes支持名为Rolling Update的功能, 允许用户不间断地, 接近几乎无缝地平滑升级部署应用程序, 即在不停止对外服务的前提下完成应用的更新

maxSurge

如图可以看到在最大副本数设置为1的情况下, 在新的Pod就绪之前旧Pod保持运行, 滚动更新正常工作

主要影响滚动更新的配置块

1
2
3
4
5
6
7
8
9
10
11
spec:
replicas: 1
selector:
matchLabels:
app: test-shushi-os
minReadySeconds: 10
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1

replicas 表示Pod的副本数量, 这里配置为1个

minReadySeconds 容器启动后, 在启动livenessreadiness探针之前的秒数, 这是从pod变为Ready阶段到变为Available阶段的时间, 这里配置为10s

strategy.type Deployment使用rolling update 的方式更新Pod

strategy.rollingUpdate.maxSurge 滚动更新期间可以创建的pod的最大数量超过指定数量的pod

strategy.rollingUpdate.maxUnavailable 在rolling更新期间无法使用的最大pod数

K8s中的启动(Startup Probe)、就绪(Readiness Probe)和存活(Liveness Probe)三种探针

在Kubernetes, 探针(Probes)是用于检测容器运行状态的机制, 探针通过探针动作(Probe Actions)来执行检测, 比如 HTTP 请求、命令执行或 TCP 检测

启动探针(Startup Probe)

用于检测应用程序是否已经启动完成, 它在容器启动时执行, 成功后, 其他探针才会开始工作, 如果失败, 容器会被重启

1
2
3
4
5
6
7
8
9
10
11
startupProbe:
failureThreshold: 5
initialDelaySeconds: 300
periodSeconds: 15
successThreshold: 1
timeoutSeconds: 1
exec:
command:
- sh
- "-c"
- sh /project/healthCheck.sh 8080

就绪探针(Readiness Probe)

用于检测应用是否准备好接收流量, 决定是否将 Pod 加入服务负载均衡, 它会周期性执行, 如果失败, 会从服务的负载均衡中移除 Pod, 但不会导致 Pod 重启

存活(Liveness Probe)探针

用于检测应用是否处于运行状态和发现无法自行恢复的死锁状态, 它会周期性执行, 如果失败, 会导致容器重启

探针的参数和配置

探针的常用参数

  • initialDelaySeconds: 容器启动后延迟多少秒执行第一次探测
  • periodSeconds: 执行探测的时间间隔
  • timeoutSeconds: 探测超时时间
  • successThreshold: 探测成功的最小连续次数
  • failureThreshold: 探测失败的最大次数,超过后采取相应动作(服务中移除-就绪探针、重启-存活探针)

探针的配置实践

  • 对于启动缓慢的应用,使用启动探针
  • 就绪探针应该检查应用是否真正准备好处理请求
  • 存活探针应该检查应用是否处于运行状态,但不应过于严格

一个完整的YAML文件实例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: test-shushi-os
name: test-shushi-os
namespace: hkzc-test
spec:
replicas: 1
selector:
matchLabels:
app: test-shushi-os
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
template:
metadata:
labels:
app: test-shushi-os
spec:
restartPolicy: Always
imagePullSecrets:
- name: harbor
containers:
- name: test-shushi-os
image: test-shushi-os:v906
imagePullPolicy: Always
ports:
- containerPort: 8080
env:
- name: DUBBO_IP_TO_REGISTRY
value: 192.168.6.100
- name: DUBBO_PORT_TO_REGISTRY
value: "31148"
livenessProbe:
failureThreshold: 10
initialDelaySeconds: 300
periodSeconds: 15
successThreshold: 1
timeoutSeconds: 1
exec:
command:
- sh
- "-c"
- sh /project/healthCheck.sh 8080
readinessProbe:
failureThreshold: 5
initialDelaySeconds: 300
periodSeconds: 15
successThreshold: 1
timeoutSeconds: 2
exec:
command:
- sh
- "-c"
- sh /project/healthCheck.sh 8080
startupProbe:
failureThreshold: 5
initialDelaySeconds: 300
periodSeconds: 15
successThreshold: 1
timeoutSeconds: 1
exec:
command:
- sh
- "-c"
- sh /project/healthCheck.sh 8080
resources:
requests:
cpu: "800m"
memory: "1024Mi"
limits:
cpu: "2000m"
memory: "3072Mi"
volumeMounts:
- mountPath: /var/logs/focusin/
name: focusin-logs
volumes:
- hostPath:
path: /var/logs/focusin/
type: ""
name: focusin-logs
---
apiVersion: v1
kind: Service
metadata:
name: test-shushi-os # 服务名 dev-shushi-os
namespace: hkzc-test
spec:
externalTrafficPolicy: Cluster
ports:
# 协议TCP/UDP/SCTP三选一
# nodePort: 30000-32767
# 业务服务端口 容器内的 8080 -> 31888
- name: shushi-os-8080
protocol: TCP
port: 80 # SRV对外端口
targetPort: 8080
nodePort: 31888 # 节点暴露的端口
# dubbo 服务端口 容器内的 20880 -> 31146
- name: susih-dubbo-20880
protocol: TCP
port: 83
targetPort: 31148
nodePort: 31148
# 外部api端口 容器内的 8091 -> 31891
- name: susih-api-8091
protocol: TCP
port: 84
targetPort: 8091
nodePort: 31891
selector:
app: test-shushi-os
sessionAffinity: None
type: NodePort