3.4. 使用 Topology CR 控制服务 pod 放置

流程

1. 在工作站上创建一个文件，它定义了一个 Topology CR，将服务 pod 分散到 worker 节点上，如 default_ctlplane_topology.yaml ：

   apiVersion: topology.openstack.org/v1beta1
   kind: Topology
   metadata:
     name: default-ctlplane-topology
     namespace: openstack
   spec:
     topologySpreadConstraints:
     - maxSkew: 1
       topologyKey: kubernetes.io/hostname
       whenUnsatisfiable: ScheduleAnyway
       matchLabelKeys:
         - pod-template-hash
         - controller-revision-hash

   • metadata.name ：名称必须是唯一的，仅包含小写字母数字字符，以及 -(hyphens)或 . （句点），以字母数字字符开头和结尾。

   • topologySpreadConstraints.whenUnsatisfiable ：指定调度程序在无法满足分布式约束的情况下如何处理 pod：

     • DoNotSchedule ：构建调度程序而不是调度 pod。这是默认的行为。为确保部署具有高可用性(HA)，请将 HA 服务 rabbitmq 和 galera 设置为 DoNotSchedule。
     • ScheduleAnyway ：构建调度程序以在任何位置调度 pod，但为拓扑赋予更高的优先级，以最小化 skew。如果将 HA 服务设置为 ScheduleAnyway，则当无法满足分布式约束时，该 pod 会放置到不同的主机 worker 节点上。然后，在主机运行后，您必须手动将 pod 移到正确的主机上。有关如何手动移动 pod 的更多信息，请参阅 RHOCP 节点中的 控制 pod 放置到节点上。
   • topologySpreadConstraints.matchLabelKeys ：指定用于对关联性规则应用到的 pod 的标签键的可选字段。使用此字段确保关联性规则仅在调度时应用到来自同一 statefulset 或 deployment 资源的 pod。matchLabelKeys 字段可让资源使用新 pod 更新，而分散约束规则仅应用到新的 pod 集合。

2. 在工作站上创建一个文件，它定义了一个 Topology CR，为 HA 服务 pod 强制严格的分布限制，如 ha_ctlplane_topology.yaml ：

   apiVersion: topology.openstack.org/v1beta1
   kind: Topology
   metadata:
     name: ha-ctlplane-topology
     namespace: openstack
   spec:
     topologySpreadConstraints:
     - maxSkew: 1
       topologyKey: kubernetes.io/hostname
       whenUnsatisfiable: DoNotSchedule
       matchLabelKeys:
         - pod-template-hash
         - controller-revision-hash

3. 创建 Topology CR：

   $ oc create -f default_ctlplane_topology.yaml
   $ oc create -f ha_ctlplane_topology.yaml

4. 在工作站上打开 OpenStackControlPlane CR 文件。

5. 指定在创建时的服务 pod 会分散到 control plane 中的 worker 节点上：

   apiVersion: core.openstack.org/v1beta1
   kind: OpenStackControlPlane
   metadata:
     name: openstack-control-plane
     namespace: openstack
   spec:
     topologyRef:
       name: default-ctlplane-topology

6. 更新 rabbitmq 和 galera 服务的规格，以确保在创建时将 HA 服务 pod 放置到 worker 节点上，当可以满足分布式约束时：

   apiVersion: core.openstack.org/v1beta1
   kind: OpenStackControlPlane
   metadata:
     name: openstack-control-plane
     namespace: openstack
   spec:
     topologyRef:
       name: default-ctlplane-topology
     ...
     galera:
       topologyRef:
         name: ha-ctlplane-topology
       ...
     rabbitmq:
       topologyRef:
         name: ha-ctlplane-topology
       ...

7. 更新 control plane：

   $ oc apply -f openstack_control_plane.yaml -n openstack

8. 等待 RHOCP 创建与 OpenStackControlPlane CR 相关的资源。运行以下命令来检查状态：

   $ oc get openstackcontrolplane -n openstack
   NAME 						STATUS 	MESSAGE
   openstack-control-plane 	Unknown 	Setup started

   当状态为 "Setup complete" 时，会创建 OpenStackControlPlane 资源。

   提示

   将 -w 选项附加到 get 命令的末尾，以跟踪部署进度。

9. 验证服务 pod 是否在正确的 worker 节点上运行。

   Example

   $ oc -n openstack get pods | grep -iE "(rabbitmq|galera)"
   openstack-galera-0           1/1     Running     0             24m     192.172.28.33   worker-0
   openstack-galera-1           1/1     Running     0             24m     192.172.16.63   worker-1
   openstack-galera-2           1/1     Running     0             24m     192.172.12.82   worker-2
   rabbitmq-server-0            1/1     Running     0             24m     192.168.24.95   worker-2
   rabbitmq-server-1            1/1     Running     0             24m     192.168.16.84   worker-0
   rabbitmq-server-2            1/1     Running     0             24m     192.168.20.137  worker-1