如果您使用远程工作节点，请考虑使用哪些对象来运行您的应用程序。
建议根据您在网络问题或断电事件中所需的行为使用守护进程集或静态Pod。此外，如果控制平面无法访问远程工作节点，您可以使用Kubernetes区域和容差来控制或避免Pod驱逐。
- 守护进程集
-
由于以下原因，守护进程集是在远程工作节点上管理Pod的最佳方法：
-
守护进程集通常不需要重新调度行为。如果节点与集群断开连接，节点上的 Pod 可以继续运行。OpenShift Container Platform 不会更改守护进程集 Pod 的状态，并保留 Pod 上次报告的状态。例如，如果守护进程集 Pod 处于运行中状态，当节点停止通信时，Pod 将继续运行，并被 OpenShift Container Platform 视为正在运行。
-
默认情况下，守护进程集 Pod 会创建具有针对node.kubernetes.io/unreachable和node.kubernetes.io/not-ready污点的NoExecute容忍度，且没有tolerationSeconds值。这些默认值可确保如果控制平面无法访问节点，则永远不会驱逐守护进程集 Pod。例如
默认情况下添加到守护进程集 Pod 的容忍度
tolerations:
- key: node.kubernetes.io/not-ready
operator: Exists
effect: NoExecute
- key: node.kubernetes.io/unreachable
operator: Exists
effect: NoExecute
- key: node.kubernetes.io/disk-pressure
operator: Exists
effect: NoSchedule
- key: node.kubernetes.io/memory-pressure
operator: Exists
effect: NoSchedule
- key: node.kubernetes.io/pid-pressure
operator: Exists
effect: NoSchedule
- key: node.kubernetes.io/unschedulable
operator: Exists
effect: NoSchedule
-
守护进程集可以使用标签来确保工作负载在匹配的工作节点上运行。
-
您可以使用 OpenShift Container Platform 服务端点来负载均衡守护进程集 Pod。
|
|
如果 OpenShift Container Platform 无法访问节点，则守护进程集在节点重新引导后不会调度 Pod。
|
- 静态 Pod
-
如果您希望 Pod 在节点重新引导后（例如，断电后）重新启动，请考虑使用静态 Pod。节点上的 kubelet 会在节点重新启动时自动重启静态 Pod。
当控制平面无法访问节点时，节点控制器默认会应用node.kubernetes.io/unreachable污点并以每秒 0.1 个节点的速度驱逐 Pod。但是，在使用 Kubernetes 区域的集群中，Pod 驱逐行为会发生改变。
如果区域完全中断，即区域中的所有节点的Ready状态为False或Unknown，则控制平面不会将node.kubernetes.io/unreachable污点应用于该区域中的节点。
对于部分中断的区域，如果超过 55% 的节点具有False或Unknown状态，则 Pod 驱逐速率将降低至每秒 0.01 个节点。对于节点数少于 50 个的小型集群，不会添加污点。您的集群必须拥有三个以上的区域才能生效。
您可以通过在节点规范中应用topology.kubernetes.io/region标签将节点分配到特定区域。
Kubernetes 区域的节点标签示例
kind: Node
apiVersion: v1
metadata:
labels:
topology.kubernetes.io/region=east
您可以调整 kubelet 检查每个节点状态的时间量。
要设置影响本地节点控制器何时使用Unhealthy或Unreachable状态标记节点的时间间隔，请创建一个包含node-status-update-frequency和node-status-report-frequency参数的KubeletConfig对象。
每个节点上的 kubelet 根据node-status-update-frequency设置确定节点状态，并根据node-status-report-frequency设置向集群报告该状态。默认情况下，kubelet 每 10 秒确定一次 Pod 状态，并每分钟报告一次状态。但是，如果节点状态发生更改，kubelet 会立即将更改报告给集群。OpenShift Container Platform 仅在启用 Node Lease 功能门（这是 OpenShift Container Platform 集群中的默认状态）时才使用node-status-report-frequency设置。如果禁用 Node Lease 功能门，则节点会根据node-status-update-frequency设置报告其状态。
Kubelet 配置示例
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"
| 1 |
使用MachineConfig对象的标签指定此KubeletConfig对象适用的节点类型的类型。 |
| 2 |
指定 kubelet 检查与此MachineConfig对象关联的节点状态的频率。默认值为10s。如果更改此默认值，则node-status-report-frequency值将更改为相同的值。 |
| 3 |
指定 kubelet 报告与此MachineConfig对象关联的节点状态的频率。默认值为1m。 |
node-status-update-frequency参数与node-monitor-grace-period参数配合使用。
|
|
不支持修改node-monitor-grace-period参数。
|
- 容忍度
-
如果本地节点控制器向其无法访问的节点添加具有NoExecute效果的node.kubernetes.io/unreachable污点，您可以使用 Pod 容忍度来减轻其影响。
具有NoExecute效果的污点会以以下方式影响在节点上运行的 Pod：
|
|
除非显式设置容忍度，否则 Kubernetes 会自动为node.kubernetes.io/not-ready和node.kubernetes.io/unreachable添加具有tolerationSeconds=300的容忍度，这意味着如果检测到这些污点中的任何一个，Pod 将保持绑定 5 分钟。
|
您可以通过为node.kubernetes.io/unreachable和node.kubernetes.io/not-ready污点配置具有NoExecute效果的 Pod 容忍度来延迟或避免 Pod 驱逐。
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)
...
| 1 |
没有tolerationSeconds的NoExecute效果允许 Pod 在控制平面无法访问节点时永远保持运行。 |
| 2 |
具有tolerationSeconds: 600 的NoExecute效果允许 Pod 在控制平面将节点标记为Unhealthy时保持运行 10 分钟。 |
| 3 |
您可以指定您自己的tolerationSeconds值。 |
- 其他类型的 OpenShift Container Platform 对象
-
您可以使用副本集、部署和复制控制器。节点断开连接 5 分钟后，调度程序可以将这些 Pod 重新调度到其他节点。对于某些工作负载（例如 REST API），重新调度到其他节点可能很有益，管理员可以保证运行并访问特定数量的 Pod。
|
|
在使用远程工作节点时，如果远程工作节点旨在保留用于特定功能，则可能无法接受在不同节点上重新调度 Pod。
|
有状态集在出现中断时不会重新启动。Pod 将保持在terminating状态，直到控制平面确认 Pod 已终止。
为了避免调度到无法访问相同类型持久存储的节点，在网络隔离的情况下，OpenShift Container Platform 无法将需要持久卷的 Pod 迁移到其他区域。
