面试题：容器化下Kubernetes滚动更新过程中如何避免服务中断

1. 合理设置滚动更新参数

maxSurge：此参数定义了在滚动更新期间，能够超过期望 Pod 数量的最大 Pod 数量。建议设置为一个合适的百分比或固定数量。例如设置为 25%，意味着在更新过程中，新的 Pod 可以比期望数量多出 25%。这样在更新时可以有更多的 Pod 来处理请求，减少服务中断的可能性。示例配置如下：

spec:
  strategy:
    rollingUpdate:
      maxSurge: 25%

maxUnavailable：该参数定义了在滚动更新期间，不可用的 Pod 的最大数量。同样建议设置为百分比或固定数量，如 25%。表示在更新过程中，最多只能有 25% 的 Pod 处于不可用状态。这确保了始终有足够的 Pod 提供服务。示例配置：

spec:
  strategy:
    rollingUpdate:
      maxUnavailable: 25%

2. 健康检查机制

Liveness Probe：配置存活探针，定期检查 Pod 是否正常运行。如果 Pod 未通过存活探针检查，Kubernetes 会自动重启该 Pod。例如对于一个 HTTP 服务，可以通过如下方式配置：

spec:
  containers:
  - name: myapp
    image: myapp:latest
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 30
      periodSeconds: 10

这里 initialDelaySeconds 表示容器启动后等待多久开始执行探针检查，periodSeconds 表示检查的时间间隔。

Readiness Probe：配置就绪探针，用于判断 Pod 是否准备好接收流量。只有通过就绪探针的 Pod 才会被添加到 Service 的端点中，接收用户请求。配置方式与存活探针类似，例如：

spec:
  containers:
  - name: myapp
    image: myapp:latest
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5

3. 金丝雀发布

可以采用金丝雀发布策略，先将少量的流量导向新版本的 Pod，观察新版本是否稳定。例如，可以通过 Service 和 Ingress 的配置，将 10% 的流量发送到新版本的 Pod 上。如果新版本运行稳定，再逐步增加流量比例，直到全部切换到新版本。这可以使用 Istio 等服务网格工具来实现更细粒度的流量控制。

4. 预发布环境验证

在生产环境进行滚动更新之前，先在预发布环境进行相同的更新操作，全面测试服务的各项功能和性能，提前发现可能导致服务中断的问题并解决。

5. 回滚策略

配置好回滚策略，一旦在滚动更新过程中发现服务出现问题，能够快速回滚到上一个稳定版本。在 Kubernetes 中，可以通过 kubectl rollout undo 命令进行回滚，并且可以在部署配置中设置回滚相关的参数，如保留的历史版本数量等。例如：

spec:
  revisionHistoryLimit: 10

这里设置了保留 10 个历史版本，方便在需要时进行回滚操作。

星途面试题库