K8s配置应用的滚动更新与启动、就绪和存活三种探针
完整的滚动更新与探针配置参考test-shushi-os.yml
, hexo以静态资源的方式引用YAML
文件会导致这个文件被强行转换成JSON
, 所以在文章末尾以代码块的方式引入
K8s配置滚动更新
Kubernetes支持名为Rolling Update的功能, 允许用户不间断地, 接近几乎无缝地平滑升级部署应用程序, 即在不停止对外服务的前提下完成应用的更新

如图可以看到在最大副本数设置为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
容器启动后, 在启动liveness
或readiness
探针之前的秒数, 这是从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 namespace: hkzc-test spec: externalTrafficPolicy: Cluster ports: - name: shushi-os-8080 protocol: TCP port: 80 targetPort: 8080 nodePort: 31888 - name: susih-dubbo-20880 protocol: TCP port: 83 targetPort: 31148 nodePort: 31148 - name: susih-api-8091 protocol: TCP port: 84 targetPort: 8091 nodePort: 31891 selector: app: test-shushi-os sessionAffinity: None type: NodePort
|