4.3. 在 OpenShift Virtualization 上部署托管的 control plane
使用托管的 control plane 和 OpenShift Virtualization,您可以使用 KubeVirt 虚拟机托管的 worker 节点创建 OpenShift Container Platform 集群。OpenShift Virtualization 上的托管 control plane 提供了几个优点:
- 通过在相同的底层裸机基础架构中打包托管的 control plane 和托管集群来提高资源使用量
- 分离托管的 control plane 和托管集群,以提供强大的隔离
- 通过删除裸机节点 bootstrap 过程来减少集群置备时间
- 管理同一基本 OpenShift Container Platform 集群中的多个发行版本
托管的 control plane 功能默认启用。
您可以使用托管的 control plane 命令行界面 hcp
创建 OpenShift Container Platform 托管的集群。托管的集群自动导入为受管集群。如果要禁用此自动导入功能,请参阅"禁用托管集群自动导入到多集群引擎 operator"。
其他资源
4.3.1. 在 OpenShift Virtualization 上部署托管 control plane 的要求
当您准备在 OpenShift Virtualization 上部署托管 control plane 时,请考虑以下信息:
- 在托管 control plane 的同一平台上运行 hub 集群和 worker。
- 每个托管集群都必须具有集群范围的唯一名称。托管的集群名称不能与任何现有的受管集群相同,以便多集群引擎 Operator 可以管理它。
-
不要使用
clusters
作为托管的集群名称。 - 无法在多集群引擎 Operator 受管集群的命名空间中创建托管集群。
- 当您为托管 control plane 配置存储时,请考虑推荐的 etcd 实践。要确保您满足延迟要求,请将快速存储设备专用于每个 control-plane 节点上运行的所有托管 control plane etcd 实例。您可以使用 LVM 存储为托管的 etcd pod 配置本地存储类。如需更多信息,请参阅"推荐 etcd 实践"和"使用逻辑卷管理器存储的持久性存储"。
4.3.1.1. 先决条件
您必须满足以下先决条件,才能在 OpenShift Virtualization 上创建 OpenShift Container Platform 集群:
-
您可以访问 OpenShift Container Platform 集群,版本 4.14 或更高版本,在
KUBECONFIG
环境变量中指定的。 OpenShift Container Platform 管理集群启用了通配符路由 DNS 路由,如以下 DNS 所示:
$ oc patch ingresscontroller -n openshift-ingress-operator default --type=json -p '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'
- OpenShift Container Platform 管理集群安装了 OpenShift Virtualization 版本 4.14 或更高版本。如需更多信息,请参阅"使用 Web 控制台安装 OpenShift Virtualization"。
- OpenShift Container Platform 管理集群是内部裸机。
- OpenShift Container Platform 管理集群将 OVNKubernetes 配置为默认 pod 网络 CNI。
OpenShift Container Platform 管理集群有一个默认存储类。如需更多信息,请参阅"安装后存储配置"。以下示例演示了如何设置默认存储类:
$ oc patch storageclass ocs-storagecluster-ceph-rbd -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
-
您有
quay.io/openshift-release-dev
仓库的有效 pull secret 文件。如需更多信息,请参阅"在任何带有用户置备的基础架构的 x86_64 平台上安装 OpenShift"。 - 已安装托管的 control plane 命令行界面。
- 您已配置了负载均衡器。如需更多信息,请参阅"配置 MetalLB"。
- 为了获得最佳网络性能,您需要在托管 KubeVirt 虚拟机的 OpenShift Container Platform 集群中使用网络最大传输单元(MTU)为 9000 或更高。如果您使用较低的 MTU 设置,则托管 pod 的网络延迟和吞吐量会受到影响。只有在 MTU 为 9000 或更高时,在节点池中启用 multiqueue。
multicluster engine Operator 至少有一个受管 OpenShift Container Platform 集群。
local-cluster
会自动导入。有关local-cluster
的更多信息,请参阅 multicluster engine Operator 文档中的"高级配置"。您可以运行以下命令来检查 hub 集群的状态:$ oc get managedclusters local-cluster
-
在托管 OpenShift Virtualization 虚拟机的 OpenShift Container Platform 集群中,您使用
ReadWriteMany
(RWX)存储类,以便启用实时迁移。
4.3.1.2. 防火墙和端口要求
确保满足防火墙和端口要求,以便端口可以在管理集群、control plane 和托管的集群间进行通信:
kube-apiserver
服务默认在端口 6443 上运行,需要入口访问 control plane 组件之间的通信。-
如果使用
NodePort
发布策略,请确保公开分配给kube-apiserver
服务的节点端口。 - 如果使用 MetalLB 负载均衡,允许入口访问用于负载均衡器 IP 地址的 IP 范围。
-
如果使用
-
如果使用
NodePort
发布策略,请为ignition-server
和Oauth-server
设置使用防火墙规则。 konnectivity
代理建立一个反向隧道,允许在托管集群上进行双向通信,需要在端口 6443 上访问集群 API 服务器地址。通过该出口访问权限,代理可以访问kube-apiserver
服务。- 如果集群 API 服务器地址是一个内部 IP 地址,允许从工作负载子网访问端口 6443 上的 IP 地址。
- 如果地址是一个外部 IP 地址,允许从节点通过端口 6443 出口到该外部 IP 地址。
- 如果您更改了 6443 的默认端口,请调整规则以反映该更改。
- 确保打开集群中运行的工作负载所需的端口。
- 使用防火墙规则、安全组或其他访问控制来仅限制对所需源的访问。除非需要,否则请避免公开公开端口。
- 对于生产环境部署,请使用负载均衡器来简化通过单个 IP 地址的访问。
4.3.2. 计算节点实时迁移
虽然托管集群(VM)的管理集群正在进行更新或维护,但托管集群虚拟机可以自动实时迁移,以防止破坏托管集群工作负载。因此,可以在不影响 KubeVirt 平台托管集群的可用性和操作的情况下更新管理集群。
KubeVirt 虚拟机的实时迁移默认是启用的,虚拟机对根卷和映射到 kubevirt-csi
CSI 供应商的存储类使用 ReadWriteMany
(RWX)存储。
您可以通过检查 NodePool
对象的 status
部分中的 KubeVirtNodesLiveMigratable
条件来验证节点池中的虚拟机是否能够实时迁移。
在以下示例中,无法实时迁移虚拟机,因为不使用 RWX 存储。
虚拟机无法实时迁移的配置示例
- lastTransitionTime: "2024-10-08T15:38:19Z" message: | 3 of 3 machines are not live migratable Machine user-np-ngst4-gw2hz: DisksNotLiveMigratable: user-np-ngst4-gw2hz is not a live migratable machine: cannot migrate VMI: PVC user-np-ngst4-gw2hz-rhcos is not shared, live migration requires that all PVCs must be shared (using ReadWriteMany access mode) Machine user-np-ngst4-npq7x: DisksNotLiveMigratable: user-np-ngst4-npq7x is not a live migratable machine: cannot migrate VMI: PVC user-np-ngst4-npq7x-rhcos is not shared, live migration requires that all PVCs must be shared (using ReadWriteMany access mode) Machine user-np-ngst4-q5nkb: DisksNotLiveMigratable: user-np-ngst4-q5nkb is not a live migratable machine: cannot migrate VMI: PVC user-np-ngst4-q5nkb-rhcos is not shared, live migration requires that all PVCs must be shared (using ReadWriteMany access mode) observedGeneration: 1 reason: DisksNotLiveMigratable status: "False" type: KubeVirtNodesLiveMigratable
在下一个示例中,虚拟机满足实时迁移的要求。
虚拟机可实时迁移的配置示例
- lastTransitionTime: "2024-10-08T15:38:19Z" message: "All is well" observedGeneration: 1 reason: AsExpected status: "True" type: KubeVirtNodesLiveMigratable
虽然实时迁移可以防止虚拟机正常中断,但基础架构节点故障等事件可能会导致在故障节点上托管的任何虚拟机都硬重启。要使实时迁移成功,在其上托管虚拟机的源节点必须正常工作。
当节点池中的虚拟机无法实时迁移时,在管理集群中的维护过程中可能会发生对托管集群的工作负载中断。默认情况下,托管 control plane 控制器会尝试排空在虚拟机停止前无法实时迁移的 KubeVirt 虚拟机上托管的工作负载。在停止虚拟机前排空托管集群节点可让 pod 中断预算保护托管集群中的工作负载可用性。
4.3.3. 使用 KubeVirt 平台创建托管集群
在 OpenShift Container Platform 4.14 及更新的版本中,您可以使用 KubeVirt 创建集群,使其包含使用外部基础架构创建。
4.3.3.1. 使用 CLI 创建带有 KubeVirt 平台的托管集群
要创建托管集群,您可以使用托管的 control plane 命令行界面 hcp
。
流程
输入以下命令:
$ hcp create cluster kubevirt \ --name <hosted-cluster-name> \ 1 --node-pool-replicas <worker-count> \ 2 --pull-secret <path-to-pull-secret> \ 3 --memory <value-for-memory> \ 4 --cores <value-for-cpu> \ 5 --etcd-storage-class=<etcd-storage-class> 6
注意您可以使用
--release-image
标志使用特定的 OpenShift Container Platform 发行版本设置托管集群。根据
--node-pool-replicas
标志,为集群创建具有两个虚拟机 worker 副本的集群的默认节点池。片刻后,输入以下命令验证托管的 control plane pod 是否正在运行:
$ oc -n clusters-<hosted-cluster-name> get pods
输出示例
NAME READY STATUS RESTARTS AGE capi-provider-5cc7b74f47-n5gkr 1/1 Running 0 3m catalog-operator-5f799567b7-fd6jw 2/2 Running 0 69s certified-operators-catalog-784b9899f9-mrp6p 1/1 Running 0 66s cluster-api-6bbc867966-l4dwl 1/1 Running 0 66s . . . redhat-operators-catalog-9d5fd4d44-z8qqk 1/1 Running 0 66s
具有 KubeVirt 虚拟机支持的 worker 节点托管的集群通常需要 10-15 分钟才能被完全置备。
要检查托管集群的状态,请输入以下命令查看对应的
HostedCluster
资源:$ oc get --namespace clusters hostedclusters
请参见以下示例输出,它演示了一个完全置备的
HostedCluster
对象:NAMESPACE NAME VERSION KUBECONFIG PROGRESS AVAILABLE PROGRESSING MESSAGE clusters example 4.x.0 example-admin-kubeconfig Completed True False The hosted control plane is available
将
4.x.0
替换为您要使用的受支持 OpenShift Container Platform 版本。
4.3.3.2. 使用外部基础架构创建带有 KubeVirt 平台的托管集群
默认情况下,HyperShift Operator 同时托管托管集群的 control plane pod 和同一集群中的 KubeVirt worker 虚拟机。使用外部基础架构功能,您可以将 worker 节点虚拟机放在与 control plane pod 的独立集群中。
- 管理集群是运行 HyperShift Operator 的 OpenShift Container Platform 集群,用于托管托管集群的 control plane pod。
- 基础架构集群是为托管集群运行 KubeVirt worker 虚拟机的 OpenShift Container Platform 集群。
- 默认情况下,管理集群也充当托管虚拟机的基础架构集群。但是,对于外部基础架构,管理和基础架构集群会有所不同。
先决条件
- 您必须在外部基础架构集群中有一个命名空间,才能托管 KubeVirt 节点。
-
您必须具有外部基础架构集群的
kubeconfig
文件。
流程
您可以使用 hcp
命令行界面创建托管集群。
要将 KubeVirt worker 虚拟机放在基础架构集群中,请使用
--infra-kubeconfig-file
和--infra-namespace
参数,如下例所示:$ hcp create cluster kubevirt \ --name <hosted-cluster-name> \ 1 --node-pool-replicas <worker-count> \ 2 --pull-secret <path-to-pull-secret> \ 3 --memory <value-for-memory> \ 4 --cores <value-for-cpu> \ 5 --infra-namespace=<hosted-cluster-namespace>-<hosted-cluster-name> \ 6 --infra-kubeconfig-file=<path-to-external-infra-kubeconfig> 7
输入该命令后,control plane pod 托管在运行 HyperShift Operator 的管理集群上,并且 KubeVirt 虚拟机托管在单独的基础架构集群中。
4.3.3.3. 使用控制台创建托管集群
要使用控制台创建带有 KubeVirt 平台的托管集群,请完成以下步骤。
流程
- 打开 OpenShift Container Platform Web 控制台,并输入您的管理员凭证登录。
- 在控制台标头中,确保选择了 All Clusters。
- 点 Infrastructure > Clusters。
- 点 Create cluster > Red Hat OpenShift Virtualization > Hosted。
在 Create cluster 页中,按照提示输入集群和节点池详情。
注意- 如果要使用预定义的值来自动填充控制台中的字段,您可以创建 OpenShift Virtualization 凭证。如需更多信息,请参阅为内部环境创建凭证。
- 在 Cluster details 页中,pull secret 是用于访问 OpenShift Container Platform 资源的 OpenShift Container Platform pull secret。如果选择了 OpenShift Virtualization 凭证,则会自动填充 pull secret。
检查您的条目并点 Create。
此时会显示 Hosted 集群视图。
- 在托管集群视图中监控托管集群的部署。如果您没有看到托管集群的信息,请确保选择了 All Clusters,然后点集群名称。
- 等待 control plane 组件就绪。这个过程可能需要几分钟时间。
- 要查看节点池状态,请滚动到 NodePool 部分。安装节点的过程需要大约 10 分钟。您还可以点 Nodes 来确认节点是否加入托管集群。
其他资源
- 要创建在使用控制台创建托管集群时重复使用 的凭证,请参阅为内部环境创建凭证。
- 要访问托管集群,请参阅访问托管集群。
4.3.4. 为 OpenShift Virtualization 上托管的 control plane 配置默认入口和 DNS
每个 OpenShift Container Platform 集群都包含一个默认应用程序 Ingress Controller,它必须具有与其关联的通配符 DNS 记录。默认情况下,使用 HyperShift KubeVirt 供应商创建的托管集群会自动成为 KubeVirt 虚拟机在其上运行的 OpenShift Container Platform 集群的子域。
例如,OpenShift Container Platform 集群可能具有以下默认入口 DNS 条目:
*.apps.mgmt-cluster.example.com
因此,名为 guest
的 KubeVirt 托管集群,在该底层 OpenShift Container Platform 集群上运行的集群有以下默认入口:
*.apps.guest.apps.mgmt-cluster.example.com
流程
要使默认入口 DNS 正常工作,托管 KubeVirt 虚拟机的集群必须允许通配符 DNS 路由。
您可以输入以下命令来配置此行为:
$ oc patch ingresscontroller -n openshift-ingress-operator default --type=json -p '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'
当您使用默认托管集群入口时,连接仅限于通过端口 443 的 HTTPS 流量。通过端口 80 的普通 HTTP 流量被拒绝。这个限制只适用于默认的入口行为。
4.3.5. 自定义入口和 DNS 行为
如果您不想使用默认的 ingress 和 DNS 行为,您可以在创建时配置带有唯一基域的 KubeVirt 托管集群。此选项需要在创建过程中手动配置步骤,并涉及三个主要步骤:集群创建、负载均衡器创建和通配符 DNS 配置。
4.3.5.1. 部署指定基域的托管集群
要创建指定基域的托管集群,请完成以下步骤。
流程
输入以下命令:
$ hcp create cluster kubevirt \ --name <hosted_cluster_name> \ 1 --node-pool-replicas <worker_count> \ 2 --pull-secret <path_to_pull_secret> \ 3 --memory <value_for_memory> \ 4 --cores <value_for_cpu> \ 5 --base-domain <basedomain> 6
因此,托管集群有一个入口通配符,它被配置为集群名称和基域,如
.apps.example.hypershift.lab
。托管的集群处于Partial
状态,因为在创建具有唯一基域的托管集群后,您必须配置所需的 DNS 记录和负载均衡器。输入以下命令来查看托管集群的状态:
$ oc get --namespace clusters hostedclusters
输出示例
NAME VERSION KUBECONFIG PROGRESS AVAILABLE PROGRESSING MESSAGE example example-admin-kubeconfig Partial True False The hosted control plane is available
输入以下命令访问集群:
$ hcp create kubeconfig --name <hosted_cluster_name> > <hosted_cluster_name>-kubeconfig
$ oc --kubeconfig <hosted_cluster_name>-kubeconfig get co
输出示例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE console 4.x.0 False False False 30m RouteHealthAvailable: failed to GET route (https://console-openshift-console.apps.example.hypershift.lab): Get "https://console-openshift-console.apps.example.hypershift.lab": dial tcp: lookup console-openshift-console.apps.example.hypershift.lab on 172.31.0.10:53: no such host ingress 4.x.0 True False True 28m The "default" ingress controller reports Degraded=True: DegradedConditions: One or more other status conditions indicate a degraded state: CanaryChecksSucceeding=False (CanaryChecksRepetitiveFailures: Canary route checks for the default ingress controller are failing)
将
4.x.0
替换为您要使用的受支持 OpenShift Container Platform 版本。
后续步骤
要修复输出中的错误,请完成"设置负载均衡器"和"设置通配符 DNS"中的步骤。
如果您的托管集群位于裸机上,您可能需要 MetalLB 设置负载均衡器服务。如需更多信息,请参阅"配置 MetalLB"。
4.3.5.2. 设置负载均衡器
设置负载均衡器服务,将入口流量路由到 KubeVirt 虚拟机,并为负载均衡器 IP 地址分配通配符 DNS 条目。
流程
公开托管集群入口的
NodePort
服务已存在。您可以导出节点端口并创建以这些端口为目标的负载均衡器服务。输入以下命令来获取 HTTP 节点端口:
$ oc --kubeconfig <hosted_cluster_name>-kubeconfig get services -n openshift-ingress router-nodeport-default -o jsonpath='{.spec.ports[?(@.name=="http")].nodePort}'
请注意在下一步中要使用的 HTTP 节点端口值。
输入以下命令来获取 HTTPS 节点端口:
$ oc --kubeconfig <hosted_cluster_name>-kubeconfig get services -n openshift-ingress router-nodeport-default -o jsonpath='{.spec.ports[?(@.name=="https")].nodePort}'
请注意下一步要使用的 HTTPS 节点端口值。
运行以下命令来创建负载均衡器服务:
oc apply -f - apiVersion: v1 kind: Service metadata: labels: app: <hosted_cluster_name> name: <hosted_cluster_name>-apps namespace: clusters-<hosted_cluster_name> spec: ports: - name: https-443 port: 443 protocol: TCP targetPort: <https_node_port> 1 - name: http-80 port: 80 protocol: TCP targetPort: <http-node-port> 2 selector: kubevirt.io: virt-launcher type: LoadBalancer
4.3.5.3. 设置通配符 DNS
设置通配符 DNS 记录或 CNAME,该记录引用负载均衡器服务的外部 IP。
流程
输入以下命令来获取外部 IP 地址:
$ oc -n clusters-<hosted_cluster_name> get service <hosted-cluster-name>-apps -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
输出示例
192.168.20.30
配置引用外部 IP 地址的通配符 DNS 条目。查看以下示例 DNS 条目:
*.apps.<hosted_cluster_name\>.<base_domain\>.
DNS 条目必须能够在集群内部和外部路由。
DNS 解析示例
dig +short test.apps.example.hypershift.lab 192.168.20.30
输入以下命令检查托管集群状态是否已从
Partial
变为Completed
:$ oc get --namespace clusters hostedclusters
输出示例
NAME VERSION KUBECONFIG PROGRESS AVAILABLE PROGRESSING MESSAGE example 4.x.0 example-admin-kubeconfig Completed True False The hosted control plane is available
将
4.x.0
替换为您要使用的受支持 OpenShift Container Platform 版本。
4.3.6. 配置 MetalLB
在配置 MetalLB 前,您必须安装 MetalLB Operator。
流程
完成以下步骤,在托管集群中配置 MetalLB:
通过在
configure-metallb.yaml
文件中保存以下示例 YAML 内容来创建MetalLB
资源:apiVersion: metallb.io/v1beta1 kind: MetalLB metadata: name: metallb namespace: metallb-system
输入以下命令应用 YAML 内容:
$ oc apply -f configure-metallb.yaml
输出示例
metallb.metallb.io/metallb created
通过在
create-ip-address-pool.yaml
文件中保存以下示例 YAML 内容来创建IPAddressPool
资源:apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: name: metallb namespace: metallb-system spec: addresses: - 192.168.216.32-192.168.216.122 1
- 1
- 在节点网络中创建带有可用 IP 地址范围的地址池。将 IP 地址范围替换为网络中未使用的可用 IP 地址池。
输入以下命令应用 YAML 内容:
$ oc apply -f create-ip-address-pool.yaml
输出示例
ipaddresspool.metallb.io/metallb created
通过在
l2advertisement.yaml
文件中保存以下示例 YAML 内容来创建L2Advertisement
资源:apiVersion: metallb.io/v1beta1 kind: L2Advertisement metadata: name: l2advertisement namespace: metallb-system spec: ipAddressPools: - metallb
输入以下命令应用 YAML 内容:
$ oc apply -f l2advertisement.yaml
输出示例
l2advertisement.metallb.io/metallb created
其他资源
- 有关 MetalLB 的更多信息,请参阅安装 MetalLB Operator。
4.3.7. 为节点池配置额外网络、保证 CPU 和虚拟机调度
如果您需要为节点池配置额外网络,请为虚拟机(VM)请求保证的 CPU 访问权限,或者管理 KubeVirt 虚拟机的调度,请参阅以下步骤。
4.3.7.1. 将多个网络添加到节点池中
默认情况下,节点池生成的节点附加到 pod 网络。您可以使用 Multus 和 NetworkAttachmentDefinition 将额外网络附加到节点。
流程
要将多个网络添加到节点,请运行以下命令来使用 --additional-network
参数:
$ hcp create cluster kubevirt \ --name <hosted_cluster_name> \ 1 --node-pool-replicas <worker_node_count> \ 2 --pull-secret <path_to_pull_secret> \ 3 --memory <memory> \ 4 --cores <cpu> \ 5 --additional-network name:<namespace/name> \ 6 –-additional-network name:<namespace/name>
4.3.7.1.1. 使用额外网络作为默认
您可以通过禁用默认 pod 网络,将额外网络添加为节点的默认网络。
流程
要将额外网络作为默认添加到节点,请运行以下命令:
$ hcp create cluster kubevirt \ --name <hosted_cluster_name> \ 1 --node-pool-replicas <worker_node_count> \ 2 --pull-secret <path_to_pull_secret> \ 3 --memory <memory> \ 4 --cores <cpu> \ 5 --attach-default-network false \ 6 --additional-network name:<namespace>/<network_name> 7
4.3.7.2. 请求保证的 CPU 资源
默认情况下,KubeVirt 虚拟机可能会与节点上的其他工作负载共享其 CPU。这可能会影响虚拟机的性能。为了避免性能影响,您可以为虚拟机请求保证的 CPU 访问。
流程
要请求保证的 CPU 资源,请运行以下命令将
--qos-class
参数设置为Guaranteed
:$ hcp create cluster kubevirt \ --name <hosted_cluster_name> \ 1 --node-pool-replicas <worker_node_count> \ 2 --pull-secret <path_to_pull_secret> \ 3 --memory <memory> \ 4 --cores <cpu> \ 5 --qos-class Guaranteed 6
4.3.7.3. 在一组节点上调度 KubeVirt 虚拟机
默认情况下,由节点池创建的 KubeVirt 虚拟机会调度到任何可用的节点。您可以将 KubeVirt 虚拟机调度到有足够能力来运行虚拟机的特定节点上。
流程
要在特定节点组中的节点池中调度 KubeVirt 虚拟机,请运行以下命令来使用
--vm-node-selector
参数:$ hcp create cluster kubevirt \ --name <hosted_cluster_name> \ 1 --node-pool-replicas <worker_node_count> \ 2 --pull-secret <path_to_pull_secret> \ 3 --memory <memory> \ 4 --cores <cpu> \ 5 --vm-node-selector <label_key>=<label_value>,<label_key>=<label_value> 6
4.3.8. 扩展节点池
您可以使用 oc scale
命令手动扩展节点池。
流程
运行以下命令:
NODEPOOL_NAME=${CLUSTER_NAME}-work NODEPOOL_REPLICAS=5 $ oc scale nodepool/$NODEPOOL_NAME --namespace clusters --replicas=$NODEPOOL_REPLICAS
片刻后,输入以下命令查看节点池的状态:
$ oc --kubeconfig $CLUSTER_NAME-kubeconfig get nodes
输出示例
NAME STATUS ROLES AGE VERSION example-9jvnf Ready worker 97s v1.27.4+18eadca example-n6prw Ready worker 116m v1.27.4+18eadca example-nc6g4 Ready worker 117m v1.27.4+18eadca example-thp29 Ready worker 4m17s v1.27.4+18eadca example-twxns Ready worker 88s v1.27.4+18eadca
4.3.8.1. 添加节点池
您可以通过指定名称、副本数和任何其他信息(如内存和 CPU 要求)为托管集群创建节点池。
流程
要创建节点池,请输入以下信息:在本例中,节点池会将更多 CPU 分配给虚拟机:
export NODEPOOL_NAME=${CLUSTER_NAME}-extra-cpu export WORKER_COUNT="2" export MEM="6Gi" export CPU="4" export DISK="16" $ hcp create nodepool kubevirt \ --cluster-name $CLUSTER_NAME \ --name $NODEPOOL_NAME \ --node-count $WORKER_COUNT \ --memory $MEM \ --cores $CPU \ --root-volume-size $DISK
通过列出
cluster
命名空间中的nodepool
资源来检查节点池的状态:$ oc get nodepools --namespace clusters
输出示例
NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE example example 5 5 False False 4.x.0 example-extra-cpu example 2 False False True True Minimum availability requires 2 replicas, current 0 available
将
4.x.0
替换为您要使用的受支持 OpenShift Container Platform 版本。一段时间后,您可以输入以下命令来检查节点池的状态:
$ oc --kubeconfig $CLUSTER_NAME-kubeconfig get nodes
输出示例
NAME STATUS ROLES AGE VERSION example-9jvnf Ready worker 97s v1.27.4+18eadca example-n6prw Ready worker 116m v1.27.4+18eadca example-nc6g4 Ready worker 117m v1.27.4+18eadca example-thp29 Ready worker 4m17s v1.27.4+18eadca example-twxns Ready worker 88s v1.27.4+18eadca example-extra-cpu-zh9l5 Ready worker 2m6s v1.27.4+18eadca example-extra-cpu-zr8mj Ready worker 102s v1.27.4+18eadca
输入以下命令验证节点池是否处于您期望的状态:
$ oc get nodepools --namespace clusters
输出示例
NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE example example 5 5 False False 4.x.0 example-extra-cpu example 2 2 False False 4.x.0
将
4.x.0
替换为您要使用的受支持 OpenShift Container Platform 版本。
其他资源
- 要将数据平面缩减为零,请参阅将数据平面缩减为零。
4.3.9. 在 OpenShift Virtualization 上验证托管集群创建
要验证托管集群是否已成功创建,请完成以下步骤。
流程
输入以下命令验证
HostedCluster
资源是否已过渡到completed
状态:$ oc get --namespace clusters hostedclusters <hosted_cluster_name>
输出示例
NAMESPACE NAME VERSION KUBECONFIG PROGRESS AVAILABLE PROGRESSING MESSAGE clusters example 4.12.2 example-admin-kubeconfig Completed True False The hosted control plane is available
输入以下命令验证托管集群中的所有集群 Operator 是否在线:
$ hcp create kubeconfig --name <hosted_cluster_name> > <hosted_cluster_name>-kubeconfig
$ oc get co --kubeconfig=<hosted_cluster_name>-kubeconfig
输出示例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE console 4.12.2 True False False 2m38s csi-snapshot-controller 4.12.2 True False False 4m3s dns 4.12.2 True False False 2m52s image-registry 4.12.2 True False False 2m8s ingress 4.12.2 True False False 22m kube-apiserver 4.12.2 True False False 23m kube-controller-manager 4.12.2 True False False 23m kube-scheduler 4.12.2 True False False 23m kube-storage-version-migrator 4.12.2 True False False 4m52s monitoring 4.12.2 True False False 69s network 4.12.2 True False False 4m3s node-tuning 4.12.2 True False False 2m22s openshift-apiserver 4.12.2 True False False 23m openshift-controller-manager 4.12.2 True False False 23m openshift-samples 4.12.2 True False False 2m15s operator-lifecycle-manager 4.12.2 True False False 22m operator-lifecycle-manager-catalog 4.12.2 True False False 23m operator-lifecycle-manager-packageserver 4.12.2 True False False 23m service-ca 4.12.2 True False False 4m41s storage 4.12.2 True False False 4m43s