MicroK8s环境下Kubernetes滚动更新更优方案咨询

你当前通过修改环境变量时间戳触发更新的思路是可行的，但存在本地配置文件被修改、停机时间等问题，下面是几个更优的原生解决方案：

1. 直接使用kubectl rollout restart触发更新 #

这是最简单直接的方式，不需要修改任何yaml文件，执行以下命令即可触发Deployment的滚动更新：

microk8s kubectl rollout restart deployment/<你的Deployment名称>

Kubernetes会自动为每个Pod生成新的修订版本，逐步替换旧Pod，完全符合你想要的"一条命令触发更新"的需求。

2. 通过注解触发更新 #

如果希望通过配置变更的方式触发（类似你当前的思路但不修改yaml文件），可以给Deployment添加一个动态注解：

microk8s kubectl annotate deployment/<你的Deployment名称> kubectl.kubernetes.io/restartedAt=$(date +%Y-%m-%dT%H:%M:%S) --overwrite

当注解值变化时，Kubernetes会识别为Deployment配置变更，自动触发滚动更新，这种方式不会污染本地的yaml文件。

3. 优化滚动更新策略与探针，解决停机问题 #

不管用哪种触发方式，停机问题的核心是滚动更新的参数和探针配置不到位，你可以在Deployment的yaml中配置以下内容：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: your-deployment-name
spec:
  # 配置滚动更新策略，确保先启动新Pod再销毁旧Pod
  strategy:
    rollingUpdate:
      maxSurge: 1        # 允许最多额外启动1个Pod
      maxUnavailable: 0  # 更新过程中不允许有不可用的Pod
    type: RollingUpdate
  template:
    spec:
      containers:
      - name: your-container-name
        # 你的容器配置
        image: your-image:tag
        command: ["your-startup-command"]
        # 就绪探针：确认Pod已准备好接收流量
        readinessProbe:
          httpGet:
            path: /healthz  # 替换为你的健康检查路径
            port: 8080      # 替换为你的服务端口
          initialDelaySeconds: 5
          periodSeconds: 5
        # 存活探针：确认Pod正常运行
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 10
        # 环境变量可以保留，但不需要用它触发更新了
        env:
        - name: version
          value: "v1.0.0"  # 用实际版本号代替时间戳更清晰

• maxUnavailable: 0 确保更新过程中始终有足够的Pod提供服务，彻底避免停机
• readinessProbe 确保新Pod真正就绪后才会被加入服务负载，旧Pod会在新Pod就绪后才被销毁
• livenessProbe 用于检测Pod是否存活，避免异常Pod继续接收流量

总结 #

对比你当前的脚本方案，rollout restart或注解触发的方式更简洁、不污染本地配置，配合优化后的滚动策略和探针，可以完全解决停机问题。这些都是Kubernetes原生特性，MicroK8s完全支持，不需要额外的组件配置。

内容的提问来源于stack exchange，提问作者kevP-Sirius