Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

2.5. 配置自节点修复 Operator

Self Node Remediation Operator 创建 SelfNodeRemediationConfig CR 和 SelfNodeRemediationTemplate 自定义资源定义(CRD)。

注意

为了避免意外重启特定节点，Node Maintenance Operator 会将节点置于维护模式，并自动添加阻止 SNR daemonset 在特定节点中运行的节点选择器。

2.5.1. 了解 Self Node Remediation Operator 配置
复制链接

Self Node Remediation Operator 创建了名为 self-node-remediation-config 的 SelfNodeRemediationConfig CR。CR 在 Self Node Remediation Operator 的命名空间中创建。

SelfNodeRemediationConfig CR 的更改重新创建 Self Node Remediation 守护进程集。

SelfNodeRemediationConfig CR 类似于以下 YAML 文件： 

apiVersion: self-node-remediation.medik8s.io/v1alpha1
kind: SelfNodeRemediationConfig
metadata:
  name: self-node-remediation-config
  namespace: openshift-workload-availability
spec:
  safeTimeToAssumeNodeRebootedSeconds: 180
1 

  watchdogFilePath: /dev/watchdog
2 

  isSoftwareRebootEnabled: true
3 

  apiServerTimeout: 15s
4 

  apiCheckInterval: 5s
5 

  maxApiErrorThreshold: 3
6 

  peerApiServerTimeout: 5s
7 

  peerDialTimeout: 5s
8 

  peerRequestTimeout: 5s
9 

  peerUpdateInterval: 15m
10 

  hostPort: 30001
11 

  customDsTolerations:
12 

      - effect: NoSchedule
        key: node-role.kubernetes.io.infra
        operator: Equal
        value: "value1"
        tolerationSeconds: 3600
1
指定 Operator 在恢复不健康节点上运行的受影响工作负载前等待的可选持续时间。在仍然在故障节点上运行时启动替换 pod 可能会导致数据崩溃并违反运行一次语义。Operator 使用 ApiServerTimeout,ApiCheckInterval,MaxApiErrorThreshold,PeerDialTimeout, 和 PeerRequestTimeout 字段的值，以及补救时的 watchdog 超时和集群大小来计算最小持续时间。要检查最小持续时间计算，请查看 manager pod 日志并查找对 计算的最短时间的引用，以秒为单位。

如果您指定了小于最短持续时间的值，Operator 将使用最短持续时间。但是，如果要将持续时间增加到大于这个最小值的值，您可以将 secureTimeToAssumeNodeRebootedSeconds 设置为大于最小持续时间的值。

2
指定节点中 watchdog 设备的文件路径。如果您为 watchdog 设备输入了一个错误的路径，则 Self Node Remediation Operator 会自动检测到 softdog 设备路径。

如果 watchdog 设备不可用，则 SelfNodeRemediationConfig CR 将使用软件重启。

3
指定是否启用不健康节点的软件重启。默认情况下，SoftwareRebootEnabled 的值设置为 true。要禁用软件重启，请将参数设置为 false。
4
指定检查每个 API 服务器的连接的超时持续时间。此超过了此持续时间，Operator 会启动补救。超时持续时间必须大于或等于 10 毫秒。
5
指定检查每个 API 服务器的连接的频率。超时持续时间必须大于或等于 1 秒。
6
指定一个阈值。达到这个阈值后，节点开始联系其同级服务器。阈值必须大于或等于 1 秒。
7
指定对等对等服务器连接 API 服务器的超时时间。超时持续时间必须大于或等于 10 毫秒。
8
指定与对等连接建立超时的持续时间。超时持续时间必须大于或等于 10 毫秒。
9
指定超时从对等点获得响应的时长。超时持续时间必须大于或等于 10 毫秒。
10
指定更新对等信息的频率，如 IP 地址。超时持续时间必须大于或等于 10 秒。
11
指定可选值，以更改 Self Node Remediation 代理用于内部通信的端口。该值必须大于 0。默认值为端口 30001。
12
指定在 DaemonSet 上运行的自定义容限自助修复代理，以支持对不同类型的节点的补救。您可以配置以下字段：
  • effect: effect 表示污点效果要匹配。如果此字段为空，则所有污点效果都会匹配。指定后，允许的值为 NoSchedule、PreferNoSchedule 和 NoExecute。
  • Key ：键是容限应用到的污点键。如果此字段为空，则所有污点键都会匹配。如果键为空，operator 字段必须是 Exists。这种组合意味着匹配所有值和所有键。
  • operator ：运算符表示键与值的关系。有效的运算符为 Exists 和 Equal。默认值为 Equal。exists 等同于值的通配符，以便 pod 可以容忍特定类别的所有污点。
  • 值 ：容限匹配的污点值。如果运算符是 Exists，则该值应为空，否则它只是一个常规字符串。
  • TolerationSeconds ：容限的期间（它必须是 NoExecute，否则此字段将被忽略）容许污点。默认情况下，它没有被设置，这意味着容许污点（即不驱除）。系统会将零值和负值视为 0 （即立即驱除）。
  • 通过自定义容限，您可以为 Self Node Remediation 代理 pod 添加容限。如需更多信息，请参阅使用容忍度来控制 OpenShift Logging pod 放置。
注意
  • Self Node Remediation Operator 在部署命名空间中默认创建 CR。
  • CR 的名称必须是 self-node-remediation-config。
  • 您只能有一个 SelfNodeRemediationConfig CR。
  • 删除 SelfNodeRemediationConfig CR 会禁用自助节点修复。
  • 您可以编辑由 Self Node Remediation Operator 创建的 self-node-remediation-config CR。但是，当您尝试为 Self Node Remediation Operator 创建新 CR 时，日志中会显示以下信息： 
controllers.SelfNodeRemediationConfig
ignoring selfnoderemediationconfig CRs that are not named 'self-node-remediation-config'
or not in the namespace of the operator:
'openshift-workload-availability' {"selfnoderemediationconfig":
"openshift-workload-availability/selfnoderemediationconfig-copy"}

2.5.2. 了解自助节点修复模板配置
复制链接

Self Node Remediation Operator 还创建 SelfNodeRemediationTemplate 自定义资源定义(CRD)。此 CRD 为旨在更快地恢复工作负载的节点定义补救策略。可用的补救策略如下：

自动
此补救策略通过让 Self Node Remediation Operator 决定集群最合适的补救策略简化了补救过程。此策略检查集群中是否有 OutOfServiceTaint 策略。如果 OutOfServiceTaint 策略可用，Operator 会选择 OutOfServiceTaint 策略。如果 OutOfServiceTaint 策略不可用，Operator 会选择 ResourceDeletion 策略。自动 是默认的补救策略。
ResourceDeletion
此补救策略移除节点上的 pod，而不是移除节点对象。
OutOfServiceTaint
此补救策略隐式会导致在节点上删除 pod 和关联的卷附加，而不是移除节点对象。它通过将 OutOfServiceTaint 策略放在节点上来实现此目的。自 OpenShift Container Platform 版本 4.13 起，此策略在技术预览上被支持，从 OpenShift Container Platform 版本 4.15 开始正式发布。

Self Node Remediation Operator 为策略 self-node-remediation-automatic-strategy-template 创建 SelfNodeRemediationTemplate CR，自动 补救策略使用。

SelfNodeRemediationTemplate CR 类似于以下 YAML 文件： 

apiVersion: self-node-remediation.medik8s.io/v1alpha1
kind: SelfNodeRemediationTemplate
metadata:
  creationTimestamp: "2022-03-02T08:02:40Z"
  name: self-node-remediation-<remediation_object>-deletion-template
1 

  namespace: openshift-workload-availability
spec:
  template:
    spec:
      remediationStrategy: <remediation_strategy>
2
1
根据补救策略指定补救模板的类型。将 <remediation_object> 替换为 resource 或 node; 例如 self-node-remediation-resource-deletion-template。
2
指定补救策略。默认补救策略是 Automatic。

2.5.3. 对自节点修复 Operator 进行故障排除
复制链接

2.5.3.1. 常规故障排除
复制链接

问题
您需要使用自助服务修复 Operator 排除问题。
解决方案
检查 Operator 日志。

2.5.3.2. 检查守护进程集
复制链接

问题
已安装 Self Node Remediation Operator，但守护进程集不可用。
解决方案
检查 Operator 日志中的错误或警告。

2.5.3.3. 失败的补救
复制链接

问题
一个不健康的节点没有被修复。
解决方案

运行以下命令验证 selfNodeRemediation CR 是否已创建： 

$ oc get snr -A

当节点处于不健康状态时，如果 MachineHealthCheck 控制器没有创建 SelfNodeRemediation CR，请检查 MachineHealthCheck 控制器的日志。此外，请确保 MachineHealthCheck CR 包含使用补救模板所需的规范。

如果创建了 SelfNodeRemediation CR，请确保其名称与不健康的节点或机器对象匹配。

问题
即使卸载 Operator 后，也会存在 Self Node Remediation Operator 资源，如守护进程集、配置 CR 和补救模板 CR。
解决方案

要删除 Self Node Remediation Operator 资源，请运行以下命令来删除每种资源类型的资源： 

$ oc delete ds <self-node-remediation-ds> -n <namespace>
 
$ oc delete snrc <self-node-remediation-config> -n <namespace>
 
$ oc delete snrt <self-node-remediation-template> -n <namespace>

2.5.4. 收集自节点修复 Operator 的数据
复制链接

要收集有关自助服务修复 Operator 的调试信息，请使用 must-gather 工具。有关 Self Node Remediation Operator 的 must-gather 镜像的详情，请参考 收集有关特定功能的数据。

2.5.5. 其他资源
复制链接

Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2026 Red Hat返回顶部