ghcr.io/mellanox/maintenance-operator:v0.1.1

NVIDIA Maintenance Operator

NVIDIA Maintenance Operator 提供 Kubernetes API（自定义资源定义，Custom Resource Definition），允许 K8s 集群中的节点维护操作员以协调的方式进行操作。它执行一些常见操作来准备节点进行维护，例如隔离节点（cordoning）和排空节点（draining）。

用户/使用者可以通过创建 NodeMaintenance 自定义资源（CR）来请求对节点执行维护。操作员随后将调和 NodeMaintenance CR。大致来说，调和流程如下：

• 调度（Scheduling）- 安排 NodeMaintenance 由操作员处理，同时考虑约束条件，例如允许的最大并行操作数。
• 节点维护准备，例如节点隔离（cordon）和排空（draining）
• 将 NodeMaintenance 标记为就绪（Ready）（通过条件）
• 删除 NodeMaintenance 时的清理，例如节点解除隔离（uncordon）

步骤 2：确定集群中可不可用的节点数量

调度器通过不超过 MaintenanceOperatorConfig.Spec.MaxUnavailable 来遵守集群可用性限制。

• 根据 MaintenanceOperatorConfig.Spec.MaxUnavailable 计算集群中可不可用的节点绝对数量
• 该值可以是绝对数量（例如，3）或节点总数的百分比（例如，"20%"）
• 若未指定，则不应用限制
• 通过求和确定当前不可用节点数量：
  • 具有进行中的 NodeMaintenance CR 的节点数量
  • 不可调度或未就绪的节点数量
• 通过用步骤1的结果减去步骤2的结果，确定可额外不可用的节点数量

我们将此值标记为 canBecomeUnavailable。

NodeMaintenance 调度流程

维护操作员使用以下调度算法选择下一组要执行维护的节点。

步骤 1：确定节点维护调度的可用槽位数

节点维护调度的可用槽位数确定如下：

1. 获取 MaintenanceOperatorConfig.Spec.MaxParallelOperations 的值
   • 该值可以是绝对数字（例如 5）或节点总数的百分比（例如 "10%"）
2. 获取当前正在维护的节点数量（已调度 NodeMaintenance CR 的节点）
3. 可用槽位数通过用 1. 减去 2. 得出

我们将此值标记为 availableSlots。

步骤 2：确定集群中可变为不可用的节点数量

调度器通过不超过 MaintenanceOperatorConfig.Spec.MaxUnavailable 来遵守集群可用性限制。

1. 基于 MaintenanceOperatorConfig.Spec.MaxUnavailable 计算集群中可变为不可用的节点绝对数量
   • 该值可以是绝对数字（例如 3）或节点总数的百分比（例如 "20%"）
   • 如果未指定，则不应用限制
2. 通过累加以下数量确定当前不可用节点数：
   • 正在进行 NodeMaintenance CR 的节点数量
   • 不可调度或未就绪的节点数量
3. 通过用 1. 减去 2. 确定可额外变为不可用的节点数量

我们将此值标记为 canBecomeUnavailable。

步骤 3：确定维护候选节点列表

这些节点是由处于 pending（尚未调度）状态的 NodeMaintenance 对象通过 NodeMaintenance.Spec.NodeName targeting 的节点。

[!NOTE] 已被正在进行的 NodeMaintenance 对象 targeting 的节点不会出现在此列表中。

步骤 4：确定候选 NodeMaintenance 对象列表

这些是所有 targeting 步骤 3 中的候选节点之一且处于 Pending 状态的 NodeMaintenance 对象。

步骤 5：对候选 NodeMaintenance 对象进行排序

每个候选 NodeMaintenance 使用以下标准进行排序（按优先级排序）：

1. 优先处理已存在正在进行的 NodeMaintenance 对象的请求者
2. 优先处理待处理 NodeMaintenance 对象较少的请求者
3. 按创建时间排序（较早的

较新的）

排序靠前的对象将优先调度。

步骤 6：调度 NodeMaintenance 对象

调度器选择最多 availableSlots（来自步骤 1）个 NodeMaintenance 对象进行调度，同时确保：

• 额外变为不可用的节点不超过 canBecomeUnavailable（来自步骤 2）
• 如果目标节点已不可用，则不计入 canBecomeUnavailable 限制
• 每个节点仅调度一个 NodeMaintenance 对象（如果存在多个，则排序最高的胜出）

示例：当 availableSlots=3 且 canBecomeUnavailable=1 时：

• 如果 2 个请求 targeting 已不可用节点，1 个请求 targeting 可用节点 → 所有 3 个请求均可调度
• 如果 3 个请求均 targeting 可用节点 → 仅可调度 1 个请求

示例 1：并行操作限制

• 集群：10个节点（全部可用）
• 配置：MaxParallelOperations=2，MaxUnavailable=5
• 待处理：5个维护请求
• 结果：2个请求被调度（受MaxParallelOperations限制）

示例 2：可用性限制

• 集群：10个节点（其中2个已不可用）
• 配置：MaxParallelOperations=5，MaxUnavailable=3
• 待处理：3个维护请求（均针对可用节点）
• 结果：1个请求被调度（受MaxUnavailable限制：3-2=1）

故障排除

阻止维护操作器调度新节点进行维护

要防止维护操作器在可能变得不可用的额外节点上调度维护，请将MaintenanceOperatorConfig的spec.maxUnavailable字段设置为零。

[!NOTE] 这允许在已不可用的节点上继续维护，但会阻止新节点变得不可用。

示例：

kubectl -n maintenance-operator patch maintenanceoperatorconfigs.maintenance.nvidia.com default --type merge --patch '{"spec": {"maxUnavailable": 0}}'

停止维护操作器的调和过程

要完全停止所有维护操作器活动（包括正在进行的操作），请将维护操作器部署缩容至零：

示例：

kubectl scale --replicas 0 -n maintenance-operator deployment maintenance-operator

要恢复维护操作器的调和过程，请扩容部署：

示例：

kubectl scale --replicas 1 -n maintenance-operator deployment maintenance-operator