赛博工地巡检手册：全集群工作负载优雅重启指令

本手册用于在完成底层基础设施升级（如增加物理节点内存、调整网络架构）或需要清零应用重启计数时，对整个 Kubernetes 集群进行一次“全量赛博大扫除”。

🌀 为什么需要循环脚本？

在日常维护中，我们常常习惯使用 kubectl rollout restart deployment <name> 来平滑重启单个服务。但当我们需要重启所有命名空间下的资源时，会遇到两个主要阻碍：

1. 原生的限制：kubectl rollout restart 这个特定的命令本身并不支持 --all --all-namespaces（或 -A）这种全局标志。
2. 跨平台的陷阱：虽然可以通过 kubectl get ... | xargs 来批量传递参数，但 macOS 自带的 BSD 版 xargs 与 Linux 上的 GNU 版 xargs 在参数支持上存在差异。在混合终端环境中，极易报错甚至遗漏资源。

为了做到绝对的稳妥与高兼容性，编写 Bash 循环脚本是最佳实践。

---

🛠️ 全量优雅重启指令 (The Architect’s Loop)

该脚本会遍历集群中的所有命名空间，并依次找出所有的 Deployment、StatefulSet 和 DaemonSet 进行滚动更新。由于是 Rollout Restart，控制器会保证至少有一个健康的 Pod 在提供服务，从而避免业务的全面中断。

你可以直接在终端中复制并粘贴运行以下完整的 Bash 脚本：

for ns in $(kubectl get namespaces -o jsonpath='{.items[*].metadata.name}'); do
  echo "🚀 正在处理命名空间: $ns ..."

  # 获取该命名空间下的所有 Deployment, StatefulSet, DaemonSet 并逐一重启
  kubectl get deployment,statefulset,daemonset -n "$ns" -o name | while read -r res; do
    if [ -n "$res" ]; then
      kubectl rollout restart "$res" -n "$ns"
    fi
  done
done

---

🚨 施工前的风险排查 (Blast Radius)

虽然使用了优雅重启（Graceful Restart），但这依然是一次触及集群地基的高危操作。在按下回车键之前，请务必知悉以下影响范围：

1. 底层组件的短暂抖动

这个脚本不仅会重启你的业务代码，也会将 kube-system 等系统命名空间重新刷一遍。这意味着：

• 网络与路由：诸如 Cilium、CoreDNS 等网络核心组件也会依次滚动重启。在大规模重启期间，内部 DNS 解析和跨节点网络可能会出现几秒钟的短暂延迟或抖动。
• 高可用组件：kube-vip 等提供虚拟 IP 漂移的守护进程被重启时，可能会引发极短时间的流量中断。
• CI/CD：ArgoCD 等基础设施管家也会经历重启。

建议： 在执行此操作前，确保没有正在进行的重要外部拉流、长连接下载或家人的在线视频娱乐，以免触发“家庭网络危机”。

2. Operator 管理的特殊资源 (钉子户)

某些特定的基础服务不会被上述脚本覆盖。例如：

• CloudNativePG (CNPG) 数据库：CNPG 直接通过其 Operator 管理底层的裸 Pod（Naked Pods），这些数据库实例不属于标准的 Deployment 或 StatefulSet。该脚本只会重启 CNPG Operator 本身，数据库 Pod 不受影响。如需重启数据库，需借助特定的 kubectl 插件或修改集群注解。
• 独立 Pod：任何没有被控制器管理的游离 Pod 都会被忽略。

3. 存储 I/O 风暴

全量重启意味着集群内几乎所有的容器镜像都需要重新校验，应用需要重新加载配置并建立数据库连接。这会在短时间内引发极高的磁盘读写（I/O）以及内存的缓存（Buffer/Cache）占用。这属于正常现象，等待数分钟后集群资源曲线即可恢复平稳。