在 Kubernetes 中，重启 Deployment 的方式有多种，以下是详细的分类和说明：

1. 使用kubectl rollout restart（推荐）

适用场景：快速、安全地触发滚动重启，无需修改配置或镜像。

• o 步骤：kubectl rollout restart deployment <deployment-name> -n <namespace>
• o 特点：
• o 触发滚动更新（Rolling Update），逐个替换 Pod，确保服务高可用。
• o 不需要修改镜像或配置，仅通过更新 Deployment 的 template 的 annotations 或 labels 来触发重启。
• o 要求集群版本 >= 1.15。
• o 回滚：# 查看历史版本
  kubectl rollout history deployment/<deployment-name> -n <namespace>
  # 回滚到上一个版本
  kubectl rollout undo deployment/<deployment-name> -n <namespace>
  # 回滚到指定版本
  kubectl rollout undo deployment/<deployment-name> --to-revision=<version> -n <namespace>

2. 通过修改镜像（kubectl set image）

适用场景：需要更新镜像或间接触发重启。

• o 步骤：kubectl set image deployment/<deployment-name> <container-name>=<new-image> -n <namespace>
• o 例如：kubectl set image deployment/nginx-deployment nginx=nginx:1.21 -n default
• o 特点：
• o 修改容器镜像会触发滚动更新，即使镜像未变化（如使用相同标签），但 Kubernetes 会强制重启。
• o 需要确保新镜像存在，否则会失败。
• o 回滚： 同 rollout restart 的回滚方法。

3. 通过修改环境变量或配置

适用场景：需要更新配置或环境变量，同时触发重启。

• o 步骤：# 使用 patch 命令添加/修改环境变量
  kubectl patch deploy <deployment-name> -p \
  '{"spec":{"template":{"spec":{"containers":[{"name":"<container-name>","env":[{"name":"RESTART_TIME","value":"'$(date +%s)'"}]}]}}}}'
• o 或通过 kubectl set env：kubectl set env deploy/<deployment-name> RESTART_TIME=$(date +%s) -n <namespace>
• o 特点：
• o 修改 PodTemplateSpec 的环境变量会触发滚动更新。
• o 添加无意义的环境变量（如时间戳）仅用于强制触发重启。
• o 回滚： 同 rollout restart 的回滚方法。

4. 删除 Pod

适用场景：快速重启单个或多个 Pod，适合小规模或紧急情况。

• o 步骤：# 删除所有 Pod（通过标签选择器）
  kubectl delete pod -l app=<app-label> -n <namespace>
• o 例如：kubectl delete pod -l app=nginx -n default
• o 特点：
• o 依赖 Deployment 的控制器自动重建 Pod，实现滚动重启。
• o 无需修改配置或镜像。
• o 缺点：手动删除 Pod 可能导致短暂服务中断（取决于副本数）。
• o 回滚： 通过 Deployment 的历史版本回滚。

5. 编辑 Deployment 的 YAML 文件

适用场景：需要修改配置并触发重启。

• o 步骤：# 直接编辑 Deployment 的 YAML
  kubectl edit deployment <deployment-name> -n <namespace>
• o 在编辑器中修改无关紧要的字段（如注释、标签），保存后触发更新。
• o 特点：
• o 任何修改（即使无关）都会触发滚动更新。
• o 回滚： 同 rollout restart 的回滚方法。

6. 通过kubectl scale（不推荐）

适用场景：极端情况下强制重启（不推荐，可能中断服务）。

• o 步骤：# 先缩容到 0，再扩容回来
  kubectl scale deployment <deployment-name> --replicas=0 -n <namespace>
  kubectl scale deployment <deployment-name> --replicas=<original-replicas> -n <namespace>
• o 特点：
• o 会短暂中断服务（所有 Pod 被删除后再重建）。
• o 仅在非关键场景使用。

对比与选择建议

方法优点缺点适用场景rollout restart安全、无配置变更、滚动更新需集群版本 >=1.15快速重启且需保持服务高可用修改镜像/环境变量灵活，可结合配置更新需额外操作需要同时更新配置或镜像删除 Pod快捷，无需修改配置可能短暂中断服务小规模或紧急情况编辑 YAML可视化修改配置需手动操作需要修改配置时kubectl scale强制重启中断服务极端情况（不推荐）

注意事项

1. 1. 滚动更新：大多数方法会触发滚动更新，确保服务在重启过程中保持可用。
2. 2. 回滚机制：所有方法生成新的 ReplicaSet，可通过 kubectl rollout undo 回滚。
3. 3. 数据持久化：若 Pod 持有数据（如数据库），需确保使用 PersistentVolume，否则重启会丢失数据。

根据实际需求选择最合适的方法，推荐优先使用 kubectl rollout restart。

欢迎关注我的公众号“辣个男人Devin”，新鲜技术文章第一时间推送。

Tags：nginx指定配置文件重启