K8S 滚动升级

一、升级策略 

K8S中通过spect.strategy来定义新的 Pod 替换为旧的Pod的策略。策略类型分为：重建策略（Recreate）或滚动升级策略（RollingUpdate），默认为 RollingUpdate。

Recreate -- 在创建出新的Pod之前会先删掉所有已存在的Pod。

RollingUpdate -- 可以指定maxSurge和maxUnavailable来控制滚动升级过程。

• maxSurge：用来指定升级期间可以超过预期Pod数量的最大值，该值可以是一个绝对数（例如：5）或一个预期 Pod 的百分比（例如：10%），默认为 25%。通过百分比计算的绝对值向上取整。
• maxUnavailable：用来指定升级期间不可用的最大 Pod 数量。该值可以是一个绝对数（例如：5）或一个预期 Pod 的百分比（例如：10%），默认为 25%。通过百分比计算的绝对值向下取整。

在业务中我们默认使用滚动升级策略，通过合理配置maxSurge和maxUnavailable实现业务高可用。

# Pod退出等待时间

# Pod退出等待时间
deployment:
  terminationGracePeriodSeconds: 30
  # 滚动更新参数
  RollingUpdate:
    # 滚动更新时，总Pod数量最多可以超出期望值的最大值/比例（特殊业务此处需设置为100%，即：一次性拉起一倍预期Pod数量，更新全部pod）
    maxSurge: 25%
    # 滚动更新时，不可用副本数的最大值/比例
    maxUnavailable: 25%

　　

二、健康检查 

K8S中通过探针对容器执行定期诊断来判断容器的状态，通常使用存活性探针（liveness probes）和就绪性探针（readiness probes）根据容器状态进行后续处理。

• livenessProbe：探测容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为 Success。
• readinessProbe：探测容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有Service的端点中删除该Pod的IP地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Success。

在业务中我们经常同时使用这两种探针，通过存活性探针判断容器是否需要重启以实现自愈，通过就绪性探针判断容器是否已经准备好对外提供服务。

Pod 提供如下三种探针，均支持使用 Command、HTTP API、TCP Socket 这三种手段来进行服务可用性探测。

• startupProbe 启动探针（Kubernetes v1.18 [beta]）: 此探针通过后，「就绪探针」与「存活探针」才会进行存活性与就绪检查
  • startupProbe 显然比 livenessProbe 的 initialDelaySeconds 参数更灵活。
  • 同时它也能延迟 readinessProbe 的生效时间，这主要是为了避免无意义的探测。容器都还没 startUp，显然是不可能就绪的。
  • 用于对慢启动容器进行存活性检测，避免它们在启动运行之前就被杀掉
  • 程序将最多有 failureThreshold * periodSeconds 的时间用于启动，比如设置 failureThreshold=20、periodSeconds=5，程序启动时间最长就为 100s，如果超过 100s 仍然未通过「启动探测」，容器会被杀死。
• readinessProbe 就绪探针:
  • 就绪探针失败次数超过 failureThreshold 限制（默认三次），服务将被暂时从 Service 的 Endpoints 中踢出，直到服务再次满足 successThreshold.
• livenessProbe 存活探针: 检测服务是否存活，它可以捕捉到死锁等情况，及时杀死这种容器。
  • kubectl describe pod 会显示重启原因为 State.Last State.Reason = Error, Exit Code=137，同时 Events 中会有 Liveness probe failed: ... 这样的描述。
  • 服务发生死锁，对所有请求均无响应
  • 服务线程全部卡在对外部 redis/mysql 等外部依赖的等待中，导致请求无响应
  • 存活探针失败可能的原因：
  • 存活探针失败次数超过 failureThreshold 限制（默认三次），容器将被杀死，随后根据重启策略执行重启。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-v3
spec:
  # ...
  template:
    #  ...
    spec:
      containers:
      - name: my-app-v3
        image: xxx.com/app/my-app:v3
        imagePullPolicy: IfNotPresent
        # ... 省略若干配置
        startupProbe:
          httpGet:
            path: /actuator/health  # 直接使用健康检查接口即可
            port: 8080
          periodSeconds: 5
          timeoutSeconds: 1
          failureThreshold: 20  # 最多提供给服务 5s * 20 的启动时间
          successThreshold: 1
       :
          httpGet:
            path: /actuator/health  # spring 的通用健康检查路径
            port: 8080
          periodSeconds: 5
          timeoutSeconds: 1
          failureThreshold: 5
          successThreshold: 1
        # Readiness probes are very important for a RollingUpdate to work properly,
        readinessProbe:
          httpGet:
            path: /actuator/health  # 简单起见可直接使用 livenessProbe 相同的接口，当然也可额外定义
            port: 8080
          periodSeconds: 5
          timeoutSeconds: 1
          failureThreshold: 5
          successThreshold: 1

　　参数详解

pod:   #健康检查的对象
  http:   #建健康检查使用的协议
    port: 8080 #健康检查端口
  probe:
    enabled: true #开启健康检查
    probes:
      livenessProbe: #存活性健康检查
        tcpSocket:
          port: http
        initialDelaySeconds: 150 #启动容器后，启动活动或就绪探针之前的秒数。默认为0秒。最小值为0。
        periodSeconds: 10 #执行探测的频率（以秒为单位）。默认为10秒。最小值为1。
        timeoutSeconds: 1 #探测超时的秒数。默认为1秒。最小值为1。
        successThreshold: 1 #探测失败后，连续最小成功探测为成功。默认值为1。为保持活力，必须为1。最小值为1。
        failureThreshold: 3 #如果探测失败，Kubernetes将尝试尝试failureThreshold放弃。放弃活动探针意味着重新启动容器。如果准备就绪，则将Pod标记为“未就绪”。默认值为3。最小值为1。
      readinessProbe: #就绪性健康检查
        tcpSocket:
          port: http
        initialDelaySeconds: 150 #启动容器后，启动活动或就绪探针之前的秒数。默认为0秒。最小值为0。
        periodSeconds: 10 #执行探测的频率（以秒为单位）。默认为10秒。最小值为1。
        timeoutSeconds: 1 #探测超时的秒数。默认为1秒。最小值为1。
        successThreshold: 1 #探测失败后，连续最小成功探测为成功。默认值为1。为保持活力，必须为1。最小值为1。
        failureThreshold: 3 #如果探测失败，Kubernetes将尝试尝试failureThreshold放弃。放弃活动探针意味着重新启动容器。如果准备就绪，则将Pod标记为“未就绪”。默认值为3。最小值为1。

　　

参数详解

健康检查种类
在kubernetes中，经常会看到健康检查相关的配置。一般有两种健康检查方式：存活性健康检查和可用性健康检查，也叫做存活探针（livenessProbe）或者就绪探针（readinessProbe）。

livenessProbe探测应用是否处于健康状态，如果不健康会杀掉容器并根据容器策略决定是否重启容器

readinessProbe探测应用是否就绪并处于正常服务的状态，探测失败后隔离服务（不分配流量）。

Probe 中有很多精确和详细的配置，通过它们你能准确的控制 liveness 和 readiness 检查：

initialDelaySeconds：容器启动后第一次执行探测是需要等待多少秒。
periodSeconds：执行探测的频率。默认是 10 秒，最小 1 秒。
timeoutSeconds：探测超时时间。默认 1 秒，最小 1 秒。
successThreshold：探测失败后，最少连续探测成功多少次才被认定为成功。默认是 1。对于 liveness 必须是 1。最小值是 1。
failureThreshold：探测成功后，最少连续探测失败多少次才被认定为失败。默认是 3。最小值是 1。
HTTP probe 中可以给 httpGet 设置其他配置项：

host：连接的主机名，默认连接到 pod 的 IP。你可能想在 http header 中设置 "Host" 而不是使用 IP。
scheme：连接使用的 schema，默认 HTTP。
path: 访问的 HTTP server 的 path。
httpHeaders：自定义请求的 header。HTTP 运行重复的 header。
port：访问的容器的端口名字或者端口号。端口号必须介于 1 和 65535 之间。
对于 HTTP 探测器，kubelet 向指定的路径和端口发送 HTTP 请求以执行检查。 Kubelet 将 probe 发送到容器的 IP 地址，除非地址被 httpGet 中的可选 host 字段覆盖。 在大多数情况下，你不想设置主机字段。 有一种情况下你可以设置它。 假设容器在 127.0.0.1 上侦听，并且 Pod 的 hostNetwork 字段为 true。 然后，在 httpGet 下的 host 应该设置为 127.0.0.1。 如果你的 pod 依赖于虚拟主机，这可能是更常见的情况，你不应该是用 host，而是应该在 httpHeaders 中设置 Host 头。

 

三、K8S滚动升级原理

K8S通过Deployment创建副本，Deployment是一个三级结构：Deployment控制Replicaset（副本集），Replicaset控制Pod。根据Deployment的这个结构特性，一个Deployment下可存在不同的Replicaset，那就表示一个Deployment下可以有不同镜像版本的Pod同时存在。

升级过程中Deployment自动创建Replicaset，Replicaset通过滚动升级策略中maxSurge、maxUnavailable两个参数来精准地控制每次滚动的Pod数量。再结合健康检查中的存活性探针（liveness probes）和就绪性探针（readiness probes）来精准判断Pod何时启动成功以及何时准备好服务请求，确保升级过程中可用的Pod都是可正常提供服务的。

具体过程如下图所示。

 

K8S滚动升级过程

 

Part 04、总结

本文中介绍了K8S中的升级策略和健康检查，通过配置升级策略和健康检查实现滚动升级来确保微服务的平滑部署，但滚动升级也对业务设计提出了更高的要求，需要业务在设计中做到前后版本兼容，否则滚动升级过程中新旧版本同时存在期间服务调用可能会导致业务失败、脏数据等问题，业务要根据自身特性与需求选择适合的升级方案。

 

 

今日语录：

　　控制自己的物欲水平，只求一个安逸宁静的生活。