|
本文档采用自动化机器翻译技术翻译。 尽管我们力求提供准确的译文，但不对翻译内容的完整性、准确性或可靠性作出任何保证。 若出现任何内容不一致情况，请以原始 英文 版本为准，且原始英文版本为权威文本。 |
|
这是尚未发布的文档。 SUSE® Storage 1.12 (Dev). |
节点维护和Kubernetes升级指南
请按照说明中关于计划内节点维护和集群中Kubernetes版本升级的操作指引进行操作。
更新节点操作系统或容器运行时
-
对节点进行标记为不可调度。当Kubernetes节点被标记为不可调度时，Longhorn将自动禁用节点调度。
-
排空节点以将工作负载迁移到其他地方。
需要使用`--ignore-daemonsets`来排空节点。需要`--ignore-daemonsets`，因为Longhorn部署了一些守护程序集（DaemonSet），例如`Longhorn manager`、
Longhorn CSI plugin、engine image。在排空过程中，节点上的引擎进程将与工作负载Pod一起迁移到其他节点。
未通过CSI流附加到节点的卷（例如，手动通过UI附加的卷）在排空期间不会被Kubernetes自动附加到新节点。因此，Longhorn将阻止节点完成排空操作。用户需要手动分离这些卷以解除排空的阻塞。 在排空过程中，节点上的副本进程将继续运行，或者根据节点排空策略最终被驱逐并停止。
默认情况下，如果节点上有一个健康的卷副本，Longhorn将阻止节点完成排空操作，以保护最后一个副本并防止工作负载中断。您可以通过设置节点排空策略或在排空之前将副本驱逐到其他节点来控制此行为。请参阅节点排空策略建议以获取选择策略时的注意事项。 排空完成后，节点上不应有任何引擎或副本进程在运行，因为运行它们的实例管理器Pod将被停止。根据节点排空策略，调度到节点的副本将显示为`Failed`或被移除以便替换。使用Longhorn卷的工作负载将按预期运行，并且足够的副本将在其他地方运行以满足策略的要求。
通常，您不需要在排空操作之前驱逐副本，只要您在其他节点上有健康的副本。副本可以在节点重新上线并解除禁用后重新使用。请参阅节点排空策略以获取更多指导。 -
执行必要的维护，包括关闭或重启节点。
-
解除节点的禁用。Longhorn 将自动重新启用节点调度。如果节点上有现有副本，Longhorn 可能会使用这些副本来加快重建过程。您可以设置 副本补充等待间隔 设置，以自定义 Longhorn 应该等待多长时间以便可用的潜在可重用副本。
移除节点
要移除节点：
-
禁用磁盘调度。
-
驱逐节点上的所有副本。
-
分离节点上的所有卷。
如果节点已经被排空，所有工作负载应迁移到另一个节点。
如果还有其他卷附加，请在继续之前将其分离。
-
使用`Delete`在`Node`选项卡中从Longhorn中移除节点。
或者，使用以下命令从Kubernetes中移除节点：
kubectl delete node
-
Longhorn 将自动从集群中移除该节点。
升级Kubernetes
就地升级
就地升级是一种在不从集群中移除节点的情况下进行升级的方法。一些使用此升级方法的示例解决方案包括 SUSE® Rancher Prime: K3s自动升级、 SUSE Rancher Prime的Kubernetes升级指南、 Kubeadm升级等…。
假设节点和磁盘没有被删除/移除，推荐的升级指南是：
-
在升级Kubernetes组件之前，请对节点进行标记和排空。排空说明与更新节点操作系统或容器运行时中的说明类似。
-
排空`--timeout`应足够大，以便在节点升级之间，健康节点上的副本重建可以完成。在排空节点上，您拥有的Longhorn副本越多，其他健康节点上Longhorn副本重建所需的时间就越长。我们建议您测试并选择一个足够大的值，或将其设置为0（即永不超时）。
-
一次升级的节点数量应小于每个卷的Longhorn副本数量。 这样，正在运行的Longhorn卷至少有一个健康副本在运行。
-
考虑将设置节点排空策略设置为`allow-if-replica-is-stopped`，以便排空不会被分离卷的最后一个健康副本阻塞。请参见节点排空策略建议，以便在选择策略时考虑。
节点排空策略建议
目前有五种节点排空策略可供选择。每种策略都有其自身的优缺点。本节提供了每种策略的一般指导，并建议在何种情况下可以使用每种策略。
重要注意事项
节点排空策略旨在管理当节点正在排空时 Longhorn 的行为。然而，Longhorn 无法区分节点的隔离和排空，因此根据策略，即使节点未进行排空，Longhorn 也可能在其被隔离时采取行动。
节点排空策略旨在防止在满足特定条件之前驱逐实例管理器 Pod。如果实例管理器 Pod 无法被驱逐，则排空操作无法完成。这防止用户（或自动化过程）在不安全的情况下继续关闭或重启节点。如果排空操作失败且维护过程似乎耗时过长，可能会诱使忽视该故障并继续维护，但这会限制 Longhorn 保护数据的能力。始终查看事件和/或日志，以尝试确定排空进程为何未能推进，并采取措施解决根本问题。
如果包含最后一个副本则阻止
这是默认策略。它旨在在便利性和数据保护之间提供良好的平衡。在此策略生效期间，Longhorn 将防止在包含卷最后一个健康副本的隔离节点上驱逐实例管理器 Pod（并完成排空）。
优点：
-
该策略通过阻止排空操作完成来保护数据，直到另一个节点上为每个卷提供健康副本。
缺点：
-
如果卷只有一个副本，或者其他副本不健康，用户可能需要手动（通过 UI）请求从磁盘或节点驱逐副本。
-
排空完成后，卷可能会降级。如果节点重启，冗余会减少，直到它再次运行。如果节点被移除，冗余将减少，直到另一个副本重建。
允许如果最后一个副本已停止
该策略类似于`Block If Contains Last Replica`。它本质上不太安全，但可以让排空操作更快完成。它仅防止在包含最后一个运行中的健康副本的节点上驱逐实例管理器 Pod（以及完成排空）。
优点：
-
在预期被排空的节点将重新上线（数据不会丢失）且节点磁盘上的副本未被积极使用的情况下，允许排空操作继续进行。
缺点：
-
与`Block If Contains Last Replica`类似的缺点。
-
如果由于某种原因，节点永远不会恢复，数据将丢失。
始终允许
该策略不会以任何方式保护数据，但允许排空操作立即完成。它从不阻止驱逐实例管理器 Pod（以及完成排空）的操作。请勿在生产环境中使用。
优点：
-
排空操作快速完成，而不会受到 Longhorn 的干预。
缺点：
-
没有机会让 Longhorn 保护数据。
阻止驱逐
该策略提供了最高级别的数据保护，但可能导致排空时间过长并引发不必要的数据迁移。只要节点上仍存在任何副本，该策略就会阻止驱逐实例管理器 Pod（及排空操作的完成）。此外，它会采取措施自动驱逐节点上的副本。
在正常使用情况下，不建议保持此策略启用，因为它会在每次节点被隔离时触发副本驱逐。仅在计划维护期间启用。
该策略的主要用例是在自动升级没有冗余的卷的集群时（numberOfReplicas == 1）。其他策略将防止排水，直到这些副本被手动驱逐，这对自动化来说很不方便。
优点：
-
通过防止排水操作完成，直到所有副本被重新定位，从而保护数据。
-
自动驱逐副本，因此用户不需要手动执行（通过用户界面）。
-
始终保持副本冗余。
缺点：
-
排水操作的速度明显慢于其他行为。每个副本必须在另一个节点上重建，才能完成。排水超时必须根据重建期间将移动的数据量进行适当调整。
-
排水操作数据密集，特别是在启用副本自动平衡时，因为被驱逐的副本可能在被排水的节点重新上线时被移回。
-
与所有这些策略一样，它在隔离时触发，而不是在排水时。如果用户经常隔离节点而不进行排水，副本将毫无意义地被重建。
如果包含最后一个副本，则阻止驱逐。
此策略提供了默认 Block If Contains Last Replica 的数据保护，并增加了自动驱逐的便利性。在生效期间，Longhorn 将防止在包含卷的最后一个健康副本的隔离节点上驱逐实例管理器 pod（以及完成排水）。此外，满足此条件的副本会自动从节点中驱逐。
在正常使用情况下，不建议保持此策略启用，因为它可能在任何节点被隔离时触发副本驱逐。仅在计划维护期间启用。
该策略的主要用例是在自动升级没有冗余的卷的集群时（numberOfReplicas == 1）。其他策略将防止排水，直到这些副本被手动驱逐，这对自动化来说很不方便。
优点：
-
通过防止排水操作完成，保护数据，直到在另一个节点上为每个卷提供健康副本。
-
自动驱逐副本，因此用户不需要手动执行（通过用户界面）。
-
排水操作的速度和数据密集程度仅限于保护数据所需的程度。
缺点：
-
排水完成后，卷可能会降级。如果节点重启，冗余会减少，直到它再次运行。如果节点被去除，冗余将减少，直到另一个副本重建。
-
与所有这些策略一样，它在隔离时触发，而不是在排水时。如果用户经常隔离节点而不进行排水，副本将毫无意义地被重建。