第 9 章 网络边缘上的远程 worker 节点

在集群中添加远程 worker 节点涉及一些额外的注意事项。

所有节点每 10 秒向 OpenShift Container Platform 集群中的 Kubernetes Controller Manager Operator（kube 控制器）发送 heartbeat。如果集群没有从节点获得 heartbeat,OpenShift Container Platform 会使用几个默认机制进行响应。

OpenShift Container Platform 旨在可以正确处理网络分区和其他中断问题的出现。您可以缓解一些常见中断的影响，如软件升级中断、网络分割和路由问题。缓解策略包括确保远程 worker 节点上的 pod 请求正确的 CPU 和内存资源量、配置适当的复制策略、使用跨区冗余以及在工作负载中使用 Pod Disruption Tables。

如果 kube 控制器在经过了配置的时间后无法访问节点，则 control plane 上的节点控制器会将节点健康状况更新为 Unhealthy，并将节点 Ready 条件标记为 Unknown。因此，调度程序会停止将 pod 调度到该节点。内部节点控制器添加了 node.kubernetes.io/unreachable 污点，对节点具有 NoExecute 效果，默认情况下，在五分钟后调度节点上的 pod 进行驱除。

如果工作负载控制器（如 Deployment 对象或 StatefulSet 对象）将流量定向到不健康节点上的 pod，而其他节点也可以访问集群，OpenShift Container Platform 会从节点上的 pod 路由流量。无法访问集群的节点不会使用新的流量路由进行更新。因此，这些节点上的工作负载可能会继续尝试访问不健康的节点。

您可以通过以下方法降低连接丢失的影响：

有关在带有远程 worker 节点的集群中使用这些对象的更多信息，请参阅关于远程 worker 节点策略。

如果远程 worker 节点断电或重启不可用，OpenShift Container Platform 会使用几个默认机制进行响应。

如果 Kubernetes Controller Manager Operator（kube controller）在配置的时间后无法访问节点，control plane 会将节点健康状况更新为 Unhealthy，并将节点 Ready 条件标记为 Unknown。因此，调度程序会停止将 pod 调度到该节点。内部节点控制器添加了 node.kubernetes.io/unreachable 污点，对节点具有 NoExecute 效果，默认情况下，在五分钟后调度节点上的 pod 进行驱除。

在节点上当节点恢复电源并与 control plane 重新连接时， pod 必须重启。

节点重启后，kubelet 还会重启并尝试重启节点上调度的 pod。如果到 control plane 的连接时间超过默认的五分钟，则 control plane 无法更新节点健康状况并移除 node.kubernetes.io/unreachable 污点。在节点上，kubelet 会终止任何正在运行的 pod。当这些条件被清除后，调度程序就可以开始将 pod 调度到该节点。

您可以通过以下方法减轻电源损失的影响：

有关在带有远程 worker 节点的集群中使用这些对象的更多信息，请参阅关于远程 worker 节点策略。

如果集群管理员为平台验证执行了延迟测试，他们可以发现需要调整集群的操作，以确保高延迟的情况的稳定性。集群管理员只需要更改一个参数，该参数记录在一个文件中，它控制了 Supervisory 进程读取状态并解释集群的运行状况的四个参数。仅更改一个参数可以以方便、可支持的方式提供集群调整。

Kubelet 进程提供监控集群运行状况的起点。Kubelet 为 OpenShift Container Platform 集群中的所有节点设置状态值。Kubernetes Controller Manager (kube controller) 默认每 10 秒读取状态值。如果 kube 控制器无法读取节点状态值，它会在配置的时间后丢失与该节点联系。默认行为是：

如果您的网络容易出现延迟问题，尤其是在网络边缘中有节点时，此行为可能会造成问题。在某些情况下，Kubernetes Controller Manager 可能会因为网络延迟而从健康的节点接收更新。Kubelet 会从节点中驱除 pod，即使节点处于健康状态。

要避免这个问题，您可以使用 worker 延迟配置集调整 kubelet 和 Kubernetes Controller Manager 在执行操作前等待状态更新的频率。如果在控制平面和 worker 节点间存在网络延迟，worker 节点没有处于最近状态，这个调整有助于集群可以正常工作。

这些 worker 延迟配置集包含预定义的三组参数，它们带有经过仔细调优的值，以控制集群对增加的延迟进行适当地响应。用户不需要手动进行实验以查找最佳值。

您可在安装集群时配置 worker 延迟配置集，或当您发现集群网络中的延迟增加时。

如果您使用远程 worker 节点，请考虑使用哪个对象来运行应用程序。

建议根据所计划的在出现网络问题或电源丢失时需要进行的行为，使用守护进程集或静态 pod。另外，如果 control plane 无法访问远程 worker 节点，您可以使用 Kubernetes 区和容限来控制或避免 pod 驱除。

当 control plane 无法访问节点时，节点控制器默认应用 node.kubernetes.io/unreachable 污点并驱除 pod，驱除率为每秒 0.1 个节点。但是，在使用 Kubernetes 区的集群中，pod 驱除行为会被改变。

如果区被完全破坏，区中的所有节点都具有 False 或 Unknown 的 Ready 条件，control plane 不会将 node.kubernetes.io/unreachable 污点应用到那个区的节点。

对于部分受破坏的区，超过 55% 的节点具有 False 或 Unknown 条件，pod 驱除率会降低为每秒 0.01 个节点。在较小集群（小于 50 个节点）中的节点不具有污点。您的集群必须具有超过三个区域才能使行为生效。

您可以通过应用节点规格中的 topology.kubernetes.io/region 标签将节点分配给特定区。

kind: Node
apiVersion: v1
metadata:
  labels:
    topology.kubernetes.io/region=east

您可以调整 kubelet 检查每个节点状态的时间长度。

要设置影响内部节点控制器何时标记具有 Unhealthy 或 Unreachable 状况的节点的时间间隔，创建一个包含 node-status-update-frequency 参数的 KubeletConfig 对象，以及 node-status-report-frequency 参数。

每个节点上的 kubelet 决定 node-status-update-frequency 设置定义的节点状态，并根据 node-status-report-frequency 设置向集群报告这个状态。默认情况下，kubelet 每 10 秒决定 pod 状态，并每分钟报告状态。但是，如果节点状态更改，kubelet 会立即报告到集群的更改。只有在启用了 Node Lease 功能门时，OpenShift Container Platform 才会使用 node-status-report-frequency 设置，这是 OpenShift Container Platform 集群的默认设置。如果禁用了 Node Lease 功能门，节点会根据 node-status-update-frequency 设置报告其状态。

apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: disable-cpu-units
spec:
  machineConfigPoolSelector:
    matchLabels:
      machineconfiguration.openshift.io/role: worker 1
  kubeletConfig:
    node-status-update-frequency: 2
      - "10s"
    node-status-report-frequency: 3
      - "1m"

node-status-update-frequency 参数可用于 node-monitor-grace-period 参数。

具有 NoExecute 效果的污点会影响节点上运行的 pod：

您可以通过把 pod 配置为使 node.kubernetes.io/unreachable 和 node.kubernetes.io/not-ready 污点有 NoExecute 的效果来延迟或避免 pod 驱除。

...
tolerations:
- key: "node.kubernetes.io/unreachable"
  operator: "Exists"
  effect: "NoExecute" 1
- key: "node.kubernetes.io/not-ready"
  operator: "Exists"
  effect: "NoExecute" 2
  tolerationSeconds: 600 3
...

有状态集不会在停机时重启。pod 处于 terminating 状态，直到 control plane 可以确认 pod 已被终止。

为了避免调度到一个无法访问同一类型的持久性存储的节点，OpenShift Container Platform 不允许在网络分离时将需要持久性卷的 pod 迁移到其他区。