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