容器服务节点重启操作最佳实践

直接重启节点可能会导致集群出现异常。比如，对于 swarm mode 集群内的 Manager 节点，如果 Manager 健康节点数小于 2，则可能会导致集群无法自愈，最终导致集群不可用。本文结合阿里云历史案例经验，说明了在对容器服务进行主动运维等场景下，需要重启节点时的操作最佳实践。
检查业务高可用配置
在重启容器服务节点前，建议先检查或修正如下业务配置，以避免节点重启触发单点异常，进而导致业务可用性受损。

• [backcolor=transparent]配置数据持久化策略
  建议为日志、业务配置等重要数据配置的外部卷进行数据持久化，以避免容器重建后，原有容器被删除引发数据丢失。
  关于容器服务数据卷的使用，参见 数据卷管理。
• [backcolor=transparent]配置重启策略
  建议为相应业务服务配置 restart: always 自重启策略，以便节点重启后，相应容器能自动拉起。
• [backcolor=transparent]配置高可用策略
  建议结合产品架构，为相应业务配置 可用区调度（availability:az 属性）、指定节点调度（affinity、constraint 属性) 和 指定多节点调度（constraint 属性） 等亲和性、互斥性策略，以避免由于相应节点重启引发单点异常。比如，对于数据库业务，建议主备或多实例部署，然后结合前述特性，确保不同实例落在不同节点上，并且相关节点不会同时重启。

1. [backcolor=transparent]快照备份
   建议先对节点所有关联磁盘创建最新快照进行备份，以避免由于长时间未重启服务器，导致节点关机后启动过程中出现异常导致业务可用性受损。
2. [backcolor=transparent]验证业务容器配置有效性（swarm mode 集群忽略）
   对于非 swarm mode 集群，重启节点上的相应业务容器，确保容器能正常被重新拉起。

   
   [backcolor=transparent]注意：Swarm mode 集群的最小控制操作单元是服务。所以，不能直接在 swarm mode 集群节点上通过 docker start/stop 等操作直接处理业务容器，否则会引发相关报错。正确的做法是在 容器服务管理控制台 通过重新 调整应用的 REPLICAS 的方式来对业务做自动调整。

3. [backcolor=transparent]修改节点角色（适用于 swarm mode 集群）
   如果相应节点是 swarm mode 集群内的 Manager 节点，则先将其 设置为 Worker 节点。
4. [backcolor=transparent]验证 Docker Engine 运行有效性
   尝试重启 Docker daemon ，确保 Docker enginge 能正常重新启动。
5. [backcolor=transparent]执行相关运维操作
   执行计划内的相关运维操作，比如业务代码更新、系统补丁安装、系统配置调整等。
6. [backcolor=transparent]重启节点
   在控制台或系统内部，正常重启节点。
7. [backcolor=transparent]重启后状态检查
   重启完节点后，到 容器服务管理控制台，检查节点健康状态，检查业务容器运行状态。
8. [backcolor=transparent]回调节点角色（适用于 swarm mode 集群）
   如果相应节点是 swarm mode 集群内的 Manager 节点，则需要将其重新 设置为 Manager 节点。