第 8 章 网络边缘上的远程 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 的连接时间超过默认的 5 分钟，则 control plane 无法更新节点健康状况并移除 node.kubernetes.io/unreachable 污点。在节点上，kubelet 会终止任何正在运行的 pod。当这些条件被清除后，调度程序就可以开始将 pod 调度到该节点。

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

有关在带有远程 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 和 pod-eviction-timeout 参数一起工作。

具有 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
...

OpenShift Container Platform 在 pod-eviction-timeout 值到期后使用 tolerationSeconds 值。

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

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