直接重启节点可能会导致集群出现异常。比如，对于 Swarm Mode 集群内的 Manager 节点，如果 Manager 健康节点数小于 2，则可能会导致集群无法自愈，最终导致集群不可用。本文结合阿里云历史案例经验，说明了在对容器服务进行主动运维等场景下，需要重启节点时的操作最佳实践。
检查业务高可用配置
在重启容器服务节点前，建议先检查或修正如下业务配置，以避免节点重启触发单点异常，进而导致业务可用性受损：
- 配置数据持久化策略
建议为日志、业务配置等重要数据配置外部卷进行数据持久化，以避免容器重建后，原有容器被删除引发数据丢失。 关于容器服务数据卷的使用，可以参阅 产品文档。 - 配置重启策略
建议为相应业务服务配置restart: always自重启策略，以便节点重启后，相应容器能自动拉起。 - 配置高可用策略
建议结合产品架构，为相应业务配置 可用区调度(availability:az 属性)、指定节点调度（affinity、constraint 属性) 和 指定多节点调度（constraint 属性） 等亲和性、互斥性策略，以避免由于相应节点重启引发单点异常。比如，对于数据库业务，建议主备或多实例部署，然后结合前述特性，确保不同实例落在不同节点上，并且相关节点不会同时重启。
操作最佳实践
建议首先参阅前述说明，检查业务高可用性配置。然后 在每个节点上（切忌同时对多个节点进行操作），依次按如下步骤操作：
- 快照备份：
建议先对节点所有关联磁盘创建最新快照进行备份，以避免由于长时间未重启服务器，导致节点关机后启动过程中出现异常导致业务可用性受损。 - 验证业务容器配置有效性（Swarm Mode 集群忽略）：
对于非 Swarm Mode 集群，重启节点上的相应业务容器，确保容器能正常被重新拉起。
说明：
Swarm Mode 集群的最小控制操作单元是服务。所以，不能直接在 Swarm Mode 集群节点上通过 docker start/stop 等操作直接处理业务容器，否则会引发相关报错。正确的做法，是在 容器服务管理控制台 通过重新 调整应用的 REPLICAS 的方式来对业务做自动调整。
- 修改节点角色（Swarm Mode 集群）
如果相应节点是 Swarm Mode 集群内的 Manager 节点，则先将其 设置为 Worker 节点。 - 验证 Docker Engine 运行有效性
尝试重启 docker daemon ，确保 docker enginger 能正常重新启动。 - 执行相关运维操作
执行计划内的相关运维操作，比如业务代码更新、系统补丁安装、系统配置调整等。 - 重启节点
在控制台或系统内部，正常重启节点。 - 重启后状态检查
重启完节点后，到 容器服务管理控制台 ,检查节点健康状态，检查业务容器运行状态。 - 回调节点角色（Swarm Mode 集群）
如果相应节点是 Swarm Mode 集群内的 Manager 节点，则先将其重新 设置为 Manager 节点。
