Swarm管理指南（引擎） | Swarm administration guide (Engine)

当您运行一群Docker引擎时，管理节点是管理群集和存储群集状态的关键组件。理解管理节点的一些关键特性对于正确部署和维护群体非常重要。

请参阅节点如何工作以简要概述Docker群集模式以及管理器和工作器节点之间的区别。

操作群中的管理者节点

Swarm管理器节点使用Raft一致性算法来管理群体状态。你只需要理解Raft的一些一般概念就可以管理一个群体。

管理器节点的数量没有限制。决定要实现多少个管理节点是性能和容错之间的折中。将管理器节点添加到群集使群集更容错。但是，其他管理器节点会降低写入性能，因为更多节点必须确认提议来更新群集状态。这意味着更多的网络往返流量。

Raft要求大多数管理者（也称为法定人数）同意对群体提出更新，例如节点添加或删除。成员资格操作受到与状态复制相同的限制。

维持管理人员的法定人数

如果群体失去了管理人员的法定人数，群体就无法执行管理任务。如果你的群体拥有多个管理器，则总是有两个以上的管理器。为了维持法定人数，大多数管理器必须可用。建议使用奇数的管理器，因为下一个偶数不会使仲裁容易保留。例如，无论您是3或4位管理器，您仍然只能失去1位管理器并维持法定人数。如果你有5或6个管理器，你仍然只能失去两个。

即使群体失去了管理人员的法定人数，现有工作人员节点上的群集任务也会继续运行。但是，不能添加，更新或删除群集节点，并且无法启动，停止，移动或更新新的或现有的任务。

如果您确实失去了管理人员的法定人数，请参阅恢复失败故障排除步骤的法定人数。

配置管理器通过静态IP地址进行通告

启动群集时，必须指定该--advertise-addr标志以将您的地址通告给群中的其他管理节点。有关更多信息，请参阅以群集模式运行Docker引擎。由于管理器节点旨在成为基础架构的稳定组件，因此您应该使用广告地址的固定IP地址来防止群集在重新启动计算机时变得不稳定。

如果整个群体重新启动并且每个管理节点随后都获得新的IP地址，则任何节点都无法联系现有的管理员。因此，当节点尝试以旧IP地址相互联系时，群集被挂起。

工作节点的动态IP地址正常。

添加管理器节点以实现容错

您应该维护群体中的奇数个管理器以支持管理器节点故障。拥有奇数个管理器可确保在网络分区期间，如果将网络分为两组，则法定人数仍然可用于处理请求的可能性较高。如果您遇到两个以上的网络分区，则不保证达到法定人数。

Swarm Size	Majority	Fault Tolerance
1	1	0
2	2	0
3	2	1
4	3	1
5	3	2
6	4	2
7	4	3
8	5	3
9	5	4

例如，在一个有5个节点的群体中，如果失去3个节点，则没有法定人数。因此，在恢复其中一个不可用的管理节点或使用灾难恢复命令恢复群集之前，无法添加或删除节点。请参阅从灾难中恢复。

虽然可以将群集缩放到单个管理器节点，但不可能降级最后一个管理器节点。这可以确保您保持对群体的访问权限，并且群体仍然可以处理请求。缩小到单个管理员是不安全的操作，不建议实施。如果在降级操作过程中最后一个节点意外地离开群集，则群集将变为不可用，直到重新启动节点或重新启动--force-new-cluster。

您管理与群成员docker swarm和docker node子系统。有关如何添加工作节点并将工作节点提升为管理者的更多信息，请参阅向群添加节点。

分布式管理节点

除了维护奇数个管理器节点之外，放置管理器时还要注意数据中心的拓扑结构。为了获得最佳的容错性，可以在至少3个可用区中分配管理器节点，以支持整套机器或常见维护方案的故障。如果您在任何区域出现故障，群集应维持管理器节点的法定数量以处理请求并重新平衡工作负载。

Swarm manager nodes	Repartition (on 3 Availability zones)
3	1-1-1
5	2-2-1
7	3-2-2
9	3-3-3

运行仅限manager的节点

默认情况下，管理节点也可以作为工作节点。这意味着调度程序可以将任务分配给管理器节点。对于为管理人员分配任务的小型和非关键群体，只要您使用cpu和内存资源约束来安排服务，则风险相对较低。

但是，由于管理器节点使用Raft一致性算法以一致的方式复制数据，因此它们对资源匮乏很敏感。你应该隔离群体中的管理人员，使其免受可能阻碍群体心跳或领导者选举等群体操作的过程。

为了避免干扰管理器节点操作，可以删除管理器节点以使其不可用作worker节点：

docker node update --availability drain <NODE>

当您排空节点时，调度程序将节点上运行的任何任务重新分配给群中的其他可用工作节点。它也阻止调度器将任务分配给节点。

添加工作节点以实现负载平衡

为群体添加节点以平衡群体的负载。只要工作节点与服务的要求相匹配，复制服务任务将随着时间的推移尽可能均匀地分布在整个群体中。将服务限制为仅在特定类型的节点（例如具有特定数量的CPU或内存量的节点）上运行时，请记住，不符合这些要求的工作节点将无法运行这些任务。

监测群体健康

您可以nodes通过/nodesHTTP端点以JSON格式查询Docker API 来监控管理器节点的健康状况。有关更多信息，请参阅节点API文档。

从命令行运行docker node inspect <id-node>查询节点。例如，要查询作为管理器的节点的可达性：

docker node inspect manager1 --format "{{ .ManagerStatus.Reachability }}"
reachable

要将节点的状态查询为接受任务的worker，请执行以下操作：

docker node inspect manager1 --format "{{ .Status.State }}"
ready

从这些命令中，我们可以看到，manager1它既是reachable的manager又是ready的worker。

一个unreachable健康的状态意味着这个特定的管理器节点是从其他管理器节点无法访问。在这种情况下，您需要采取措施恢复无法访问的管理器：

• 重新启动守护进程并查看管理器是否回到可访问状态。

• 重新启动机器。

• 如果既不重新启动也不重新启动工作，则应该添加另一个管理器节点或将工作人员提升为管理器节点。您还需要从使用docker node demote <NODE>和设置的管理器中干净地删除失败的节点条目docker node rm <id-node>。

或者，您还可以从管理器节点获得群集运行状况的概述，其中包括docker node ls：

docker node ls
ID                           HOSTNAME  MEMBERSHIP  STATUS  AVAILABILITY  MANAGER STATUS
1mhtdwhvsgr3c26xxbnzdc3yp    node05    Accepted    Ready   Active
516pacagkqp2xc3fk9t1dhjor    node02    Accepted    Ready   Active        Reachable
9ifojw8of78kkusuc4a6c23fx *  node01    Accepted    Ready   Active        Leader
ax11wdpwrrb6db3mfjydscgk7    node04    Accepted    Ready   Active
bb1nrq2cswhtbg4mrsqnlx1ck    node03    Accepted    Ready   Active        Reachable
di9wxgz8dtuh9d2hn089ecqkf    node06    Accepted    Ready   Active

管理节点的故障排除

您不应该通过raft从另一个节点复制目录来重新启动管理器节点。数据目录对于节点ID是唯一的。一个节点只能使用一次节点ID加入群。节点ID空间应该是全局唯一的。

清晰的地重新加入管理器节点到集群：

1. 要将节点降级为工作人员，请运行docker node demote <NODE>。

2. 若要从群集中删除节点，请运行docker node rm <NODE>...

3. 使用以下方法将节点重新加入到具有新状态的群集中。docker swarm join...

有关将管理器节点加入群的更多信息，请参阅将群节点加入群。

强制删除节点

在大多数情况下，您应该关闭一个节点，然后使用该docker node rm命令将其从群集中删除。如果某个节点变得无法访问，无响应或受损，则可以通过传递该--force标志强制删除该节点而不关闭该节点。例如，如果node9变得受到影响：

$ docker node rm node9

Error response from daemon: rpc error: code = 9 desc = node node9 is not down and can't be removed

$ docker node rm --force node9

Node node9 removed from swarm

在强制删除管理器节点之前，必须先将其降级为辅助角色。如果您降级或删除管理者，请确保您总是有奇数个管理者节点。

备份群

Docker管理器节点将swarm状态和管理器日志存储在/var/lib/docker/swarm/目录中。在1.13及更高版本中，这些数据包括用于加密Raft日志的密钥。没有这些键，你将无法恢复群。

您可以使用任何管理器备份群。使用以下步骤。

1. 如果群体启用了自动锁定功能，则需要解锁密钥才能从备份恢复群集。必要时检索解锁钥匙并将其存放在安全的地方。如果您不确定，请阅读锁定群集以保护其加密密钥。

2. 在备份数据之前在Manager上停止Docker，以便在备份过程中不会更改任何数据。可以在管理器运行时进行备份（一个“hot”的备份），但不建议这样做，并且恢复时结果的可预测性会降低。当管理器关闭时，其他节点将继续生成不属于此备份的群集数据。

注意：务必保持群体管理器的法定人数。在管理器关闭期间，如果更多节点丢失，则群体更容易丢失法定人数。你所经营的管理器数是一种权衡。如果您定期关闭管理员进行备份，请考虑运行5管理器群，以便在备份运行时丢失额外的管理器，而不会中断服务。

1. 备份整个/var/lib/docker/swarm目录。

1. 重新启动管理器。

要恢复，请参阅从备份恢复。

灾后恢复

从备份恢复

按备份群组中的说明备份群组后，使用以下步骤将数据恢复到新群组。

1. 关闭群集将要恢复的目标主机上的Docker。

2. 删除/var/lib/docker/swarm新群体上目录的内容。

3. 使用备份的内容还原目录/var/lib/docker/swarm。 注意：新节点将使用与旧的节点相同的加密密钥进行磁盘存储。目前无法更改磁盘上的存储加密密钥。对于启用了自动锁定的群组，解锁密钥也与旧群组相同，并且需要解锁密钥才能恢复。

1. 在新节点上启动Docker。必要时解锁群。使用以下命令重新初始化群集，以便此节点不会尝试连接到属于旧群集的节点，并且可能不再存在。

$ docker swarm init --force-new-cluster

2. 验证群体的状态是否符合预期。这可能包括特定于应用程序的测试或仅检查输出docker service ls以确保所有预期的服务都存在。

3. 如果您使用自动锁定，请旋转解锁键。

4. 添加管理器和工作者节点，使您的新团队达到运营能力。

5. 在新群体上恢复先前的备份方案。

从失去法定人数恢复

Swarm对故障具有恢复能力，并且该群可以从任何数量的临时节点故障（机器重启或重启时崩溃）或其他瞬时错误中恢复。但是，如果群体失去法定人数，群体无法自动恢复。现有工作节点上的任务将继续运行，但管理任务不可行，包括扩展或更新服务以及加入或从群集中删除节点。恢复的最佳方法是将丢失的管理器节点重新联机。如果这是不可能的，继续阅读一些恢复你的群的选项。

在一群N管理人员中，管理器节点的法定人数（大多数）必须始终可用。例如，在一个拥有5名管理器的群体中，至少有3人必须开展业务并相互沟通。换句话说，群体可以容忍(N-1)/2永远的失败，超过这个失败的群体管理请求不能被处理。这些类型的故障包括数据损坏或硬件故障。

如果你失去了管理人员的法定人数，你不能管理群体。如果您失去了法定人数，并且您尝试对群体执行任何管理操作，则会发生错误：

Error response from daemon: rpc error: code = 4 desc = context deadline exceeded

从丢失法定数量中恢复的最佳方法是将故障节点重新联机。如果你不能这样做，从这个状态恢复的唯一方法就是使用--force-new-cluster来自管理节点的动作。这将除去命令运行的管理器之外的所有管理器。达到法定人数是因为现在只有一名经理。促使节点成为管理器，直到你拥有理想的管理器数量。

# From the node to recover
docker swarm init --force-new-cluster --advertise-addr node01:2377

当您运行docker swarm init命令的--force-new-cluster标志，您运行命令的Docker引擎将成为能够管理和运行服务的单个节点群的管理节点。管理器拥有有关服务和任务的所有信息，工作节点仍然是群集的一部分，服务仍然在运行。您将需要添加或重新添加管理器节点，以实现您以前的任务分发，并确保您有足够的管理器来保持高可用性和防止丢失仲裁。

强制群体重新平衡

一般来说，你不需要强迫群体重新平衡任务。当您向群体中添加新节点或在某段时间不可用后节点重新连接群体时，群体不会自动将工作负荷分配给闲置节点。这是一个设计决定。如果群体为了平衡而周期性地将任务转移到不同节点，那么使用这些任务的客户端将会中断。我们的目标是避免为了整个群体的平衡而中断运行服务。当新任务启动时，或者当运行任务的节点变为不可用时，这些任务将被分配给不太繁忙的节点。目标是最终平衡，对最终用户造成的影响最小。

在Docker 1.13及更高版本中，可以使用--forceor -f标志docker service update来强制服务在可用的工作节点上重新分配其任务。这将导致服务任务重新启动。客户端应用程序可能会中断。如果您已配置它，您的服务将使用滚动更新。

如果您使用较早的版本，并且希望在工作人员之间达到均衡的负载，并且不介意中断正在运行的任务，则可以通过临时缩放服务来强制群集重新平衡。使用docker service inspect --pretty <servicename>看服务的配置比例。在您使用时docker service scale，具有最少任务数量的节点将用于接收新的工作负载。群体中可能有多个负载不足的节点。您可能需要通过几次适度增量扩展服务，以实现所有节点间的平衡。

当负载达到您的满意度时，您可以将服务缩减至原始比例。您可以使用docker service ps来评估跨节点的服务当前余额。

另见docker service scale和docker service ps。

docker，容器，群，管理器，raft