别慌！完全不用每次都重置集群——我之前在树莓派上用kubeadm搭的集群也遇到过这个困惑，试了好多次总结出一套安全的关机/重启流程，保证集群能稳稳恢复：

一、关机/重启前的核心准备（重中之重！） #

不管是关机还是重启节点，先把节点上的Pod妥善迁移走，避免服务中断或数据异常：

• 先执行驱逐命令，把目标节点上的非DaemonSet Pod全部移到其他节点：

  kubectl drain <你的节点名称> --ignore-daemonsets --delete-local-data
  

  这里的参数解释下：
  • --ignore-daemonsets：DaemonSet类型的Pod是每个节点必须运行的，不用驱逐，跳过即可
  • --delete-local-data：清理节点上的本地临时存储卷，避免下次启动时出现残留冲突
• 确认节点状态变为SchedulingDisabled，说明Pod已经全部迁移完成：

  kubectl get nodes
  

二、安全执行关机或重启 #

确认Pod迁移完成后，就可以放心操作节点了：

• 关机的话，在目标节点上执行：

  sudo shutdown -h now
  

• 直接重启的话，执行：

  sudo systemctl reboot
  

  这里完全不用担心会搞坏集群，只要前面的驱逐步骤做到位，正常重启不会有问题。

三、重启后的恢复操作 #

节点重启完成、正常开机后，把节点重新加入集群调度：

• 解除节点的调度禁用状态：

  kubectl uncordon <你的节点名称>
  

• 等待1-2分钟，检查节点状态，确认它回到Ready状态：

  kubectl get nodes
  

• 最后再检查所有Pod的运行情况，确保服务都恢复正常：

  kubectl get pods --all-namespaces
  

四、Master节点的特殊注意事项 #

如果要重启Master节点，流程基本一致，但有个小细节：

• 单Master集群的话，重启期间控制平面会暂时不可用，建议在业务低峰期操作；
• Master上的kube-system组件大多是静态Pod或DaemonSet，驱逐命令会自动处理这些特殊Pod，不用额外操作。

五、长期稳定的小建议 #

• 给树莓派配个带断电保护的电源，意外断电才是集群出问题的主要元凶，正常关机重启只要按流程来都很稳；
• 可以把驱逐+解除调度的命令写成简单的shell脚本，每次操作直接运行，省得反复敲命令。

内容的提问来源于stack exchange，提问作者DazWilkin