第 5 章 检查 RHOSO 高可用性服务的 pod


OpenShift (RHOSO) High Availability 服务中每个 Red Hat OpenStack Services 的 Operator 监控它们管理的 pod 的状态。服务 Operator 旨在使至少一个服务副本保持状态为 Running

流程

  1. 您可以使用以下命令检查 Galera、RabbitMQ 和 memcached 共享 control plane 服务的所有 pod 的状态和可用性:

    $ oc get pods |egrep -e "galera|rabbit|memcache"
    NAME                            	READY   STATUS  	RESTARTS   AGE
    memcached-0                        1/1  Running 	0      	3h11m
    memcached-1                        1/1  Running 	0      	3h11m
    memcached-2                        1/1  Running 	0      	3h11m
    openstack-cell1-galera-0           1/1 	Running 	0      	3h11m
    openstack-cell1-galera-1           1/1 	Running 	0      	3h11m
    openstack-cell1-galera-2           1/1 	Running 	0      	3h11m
    openstack-galera-0                 1/1 	Running 	0      	3h11m
    openstack-galera-1                 1/1 	Running 	0      	3h11m
    openstack-galera-2                 1/1 	Running 	0      	3h11m
    rabbitmq-cell1-server-0            1/1 	Running 	0      	3h11m
    rabbitmq-cell1-server-1            1/1 	Running 	0      	3h11m
    rabbitmq-cell1-server-2            1/1 	Running 	0      	3h11m
    rabbitmq-server-0                  1/1 	Running 	0      	3h11m
    rabbitmq-server-1                  1/1 	Running 	0      	3h11m
    rabbitmq-server-2                  1/1 	Running 	0      	3h11m
    Copy to Clipboard Toggle word wrap
  2. 您可以使用以下命令从此列表中调查特定 pod,通常确定无法启动 pod 的原因:

    $ oc describe pod/<pod-name>
    Copy to Clipboard Toggle word wrap
    • 将 < pod-name > 替换为您要更多信息的 pod 列表中的 pod 名称。

      在以下示例中,rabbitmq-server-0 pod 正在调查:

      $ oc describe pod/rabbitmq-server-0
      Name:         	rabbitmq-server-0
      Namespace:    	openstack
      Priority:     	0
      Service Account:  rabbitmq-server
      Node:         	master-2/192.168.111.22
      Start Time:   	Thu, 21 Mar 2024 08:39:57 -0400
      Labels:       	app.kubernetes.io/component=rabbitmq
                    	app.kubernetes.io/name=rabbitmq
                    	app.kubernetes.io/part-of=rabbitmq
                    	controller-revision-hash=rabbitmq-server-5c886b79b4
                    	statefulset.kubernetes.io/pod-name=rabbitmq-server-0
      Annotations:  	k8s.ovn.org/pod-networks:
                      	{"default":{"ip_addresses":["192.168.16.35/22"],"mac_address":"0a:58:c0:a8:10:23","gateway_ips":["192.168.16.1"],"routes":[{"dest":"192.16...
                    	k8s.v1.cni.cncf.io/network-status:
                      	[{
                          	"name": "ovn-kubernetes",
                          	"interface": "eth0",
                          	"ips": [
                              	"192.168.16.35"
                          	],
                          	"mac": "0a:58:c0:a8:10:23",
                          	"default": true,
                          	"dns": {}
                      	}]
                    	openshift.io/scc: restricted-v2
                    	seccomp.security.alpha.kubernetes.io/pod: runtime/default
      Status:       	Running
      ...
      Copy to Clipboard Toggle word wrap

5.1. 了解基于 Taint/Toleration 的 pod 驱除过程

Red Hat OpenShift Container Platform (RHOCP)实施基于 Taint/Toleration 的 pod 驱除过程,这决定了各个 pod 如何从 worker 节点驱除。被驱除的 Pod 会在不同节点上重新调度。

RHOCP 将 污点 分配给特定的工作程序节点状况,如 未就绪不可访问。当 worker 节点遇到这些状况之一时,RHOCP 会自动污点 worker 节点。在 worker 节点变为污点后,pod 必须确定它们是否可以容忍这个污点:

  • 任何不容许污点的 pod 都会立即被驱除。
  • 任何容许污点的 pod 不会被驱除,除非 pod 对这个污点有有限 容限

    tolerationSeconds 参数指定 pod 的有限 容限,这是 pod 可以容忍特定污点(节点状况)并保持连接到 worker 节点的时长。如果在指定 tolerationSeconds 到期后 worker 节点状况仍然存在,污点会保留在 worker 节点上,pod 会被驱除。如果 worker 节点状况在指定 tolerationSeconds 到期前清除,则 pod 不会被驱除。

RHOCP 通过 设置为lerationSeconds=300 来添加 node.kubernetes.io/not-readynode.kubernetes.io/unreachable 污点的默认容限。

重要

Red Hat OpenStack Services on OpenShift (RHOSO) 18.0 Operator 不会修改污点的默认容限,因此在污点 worker 节点上运行的 pod 需要超过五分钟才能重新调度。

提高高可用性和故障切换时间

RHOCP 提供以下 Operator,您可以一起安装这些 Operator,从而提供更高的弹性,以帮助减少工作负载的故障转移时间:

  • Node Health Check Operator。如需更多信息,请参阅 Red Hat OpenShift 修复 、隔离和维护 工作负载中的修复节点健康检查
  • Self Node Remediation Operator。如需更多信息,请参阅 在 Red Hat OpenShift Remediation、隔离和维护 的工作负载 中使用自节点补救

    注意

    当 pod 使用本地存储且运行此 pod 的 worker 节点失败时,即使使用 Self Node Remediation Operator 时,可能需要手动干预。

  • Fence Agents Remediation Operator。如需更多信息,请参阅在 Red Hat OpenShift 修复 、隔离和维护工作负载 中使用 Fence Agents Remediation

与 Self Node Remediation Operator、Fence Agents Remediation Operator 结合使用并配置 Node Health Check Operator,或者同时允许这些 Operator 控制 worker 节点被声明或 无法访问 的时间,从而减少 pod 保持与失败 worker 节点绑定的时间。

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat