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-serverOauth-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

流程

  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
      --etcd-storage-class=<etcd-storage-class> 6
    1
    指定托管集群的名称,如 example
    2
    指定 worker 数,如 2
    3
    指定 pull secret 的路径,例如 /user/name/pullsecret
    4
    为 memory 指定一个值,如 6Gi
    5
    为 CPU 指定一个值,例如 2
    6
    指定 etcd 存储类名称,如 lvm-storageclass
    注意

    您可以使用 --release-image 标志使用特定的 OpenShift Container Platform 发行版本设置托管集群。

    根据 --node-pool-replicas 标志,为集群创建具有两个虚拟机 worker 副本的集群的默认节点池。

  2. 片刻后,输入以下命令验证托管的 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 分钟才能被完全置备。

  3. 要检查托管集群的状态,请输入以下命令查看对应的 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
    1
    指定托管集群的名称,如 example
    2
    指定 worker 数,如 2
    3
    指定 pull secret 的路径,例如 /user/name/pullsecret
    4
    为 memory 指定一个值,如 6Gi
    5
    为 CPU 指定一个值,例如 2
    6
    指定基础架构命名空间,如 clusters-example
    7
    指定基础架构集群的 kubeconfig 文件的路径,如 /user/name/external-infra-kubeconfig

    输入该命令后,control plane pod 托管在运行 HyperShift Operator 的管理集群上,并且 KubeVirt 虚拟机托管在单独的基础架构集群中。

4.3.3.3. 使用控制台创建托管集群

要使用控制台创建带有 KubeVirt 平台的托管集群,请完成以下步骤。

流程

  1. 打开 OpenShift Container Platform Web 控制台,并输入您的管理员凭证登录。
  2. 在控制台标头中,确保选择了 All Clusters
  3. Infrastructure > Clusters
  4. Create cluster > Red Hat OpenShift Virtualization > Hosted
  5. Create cluster 页中,按照提示输入集群和节点池详情。

    注意
    • 如果要使用预定义的值来自动填充控制台中的字段,您可以创建 OpenShift Virtualization 凭证。如需更多信息,请参阅为内部环境创建凭证
    • Cluster details 页中,pull secret 是用于访问 OpenShift Container Platform 资源的 OpenShift Container Platform pull secret。如果选择了 OpenShift Virtualization 凭证,则会自动填充 pull secret。
  6. 检查您的条目并点 Create

    此时会显示 Hosted 集群视图。

  7. 托管集群视图中监控托管集群的部署。如果您没有看到托管集群的信息,请确保选择了 All Clusters,然后点集群名称。
  8. 等待 control plane 组件就绪。这个过程可能需要几分钟时间。
  9. 要查看节点池状态,请滚动到 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. 部署指定基域的托管集群

要创建指定基域的托管集群,请完成以下步骤。

流程

  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
    1
    指定托管集群的名称。
    2
    指定 worker 数,如 2
    3
    指定 pull secret 的路径,例如 /user/name/pullsecret
    4
    为 memory 指定一个值,如 6Gi
    5
    为 CPU 指定一个值,例如 2
    6
    指定基域,如 hypershift.lab

    因此,托管集群有一个入口通配符,它被配置为集群名称和基域,如 .apps.example.hypershift.lab。托管的集群处于 Partial 状态,因为在创建具有唯一基域的托管集群后,您必须配置所需的 DNS 记录和负载均衡器。

  2. 输入以下命令来查看托管集群的状态:

    $ 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

  3. 输入以下命令访问集群:

    $ 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 条目。

流程

  1. 公开托管集群入口的 NodePort 服务已存在。您可以导出节点端口并创建以这些端口为目标的负载均衡器服务。

    1. 输入以下命令来获取 HTTP 节点端口:

      $ oc --kubeconfig <hosted_cluster_name>-kubeconfig get services -n openshift-ingress router-nodeport-default -o jsonpath='{.spec.ports[?(@.name=="http")].nodePort}'

      请注意在下一步中要使用的 HTTP 节点端口值。

    2. 输入以下命令来获取 HTTPS 节点端口:

      $ oc --kubeconfig <hosted_cluster_name>-kubeconfig get services -n openshift-ingress router-nodeport-default -o jsonpath='{.spec.ports[?(@.name=="https")].nodePort}'

      请注意下一步要使用的 HTTPS 节点端口值。

  2. 运行以下命令来创建负载均衡器服务:

    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
    1
    指定您在上一步中记录的 HTTPS 节点端口值。
    2
    指定您在上一步中记录的 HTTP 节点端口值。

4.3.5.3. 设置通配符 DNS

设置通配符 DNS 记录或 CNAME,该记录引用负载均衡器服务的外部 IP。

流程

  1. 输入以下命令来获取外部 IP 地址:

    $ oc -n clusters-<hosted_cluster_name> get service <hosted-cluster-name>-apps -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

    输出示例

    192.168.20.30

  2. 配置引用外部 IP 地址的通配符 DNS 条目。查看以下示例 DNS 条目:

    *.apps.<hosted_cluster_name\>.<base_domain\>.

    DNS 条目必须能够在集群内部和外部路由。

    DNS 解析示例

    dig +short test.apps.example.hypershift.lab
    
    192.168.20.30

  3. 输入以下命令检查托管集群状态是否已从 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:

  1. 通过在 configure-metallb.yaml 文件中保存以下示例 YAML 内容来创建 MetalLB 资源:

    apiVersion: metallb.io/v1beta1
    kind: MetalLB
    metadata:
      name: metallb
      namespace: metallb-system
  2. 输入以下命令应用 YAML 内容:

    $ oc apply -f configure-metallb.yaml

    输出示例

    metallb.metallb.io/metallb created

  3. 通过在 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 地址池。
  4. 输入以下命令应用 YAML 内容:

    $ oc apply -f create-ip-address-pool.yaml

    输出示例

    ipaddresspool.metallb.io/metallb created

  5. 通过在 l2advertisement.yaml 文件中保存以下示例 YAML 内容来创建 L2Advertisement 资源:

    apiVersion: metallb.io/v1beta1
    kind: L2Advertisement
    metadata:
      name: l2advertisement
      namespace: metallb-system
    spec:
      ipAddressPools:
       - metallb
  6. 输入以下命令应用 YAML 内容:

    $ oc apply -f l2advertisement.yaml

    输出示例

    l2advertisement.metallb.io/metallb created

其他资源

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>
1
指定托管集群的名称,如 example
2
指定 worker 节点数,例如 2
3
指定 pull secret 的路径,例如 /user/name/pullsecret
4
指定内存值,如 8Gi
5
指定 CPU 值,例如 2
6
-additional-network 参数的值设置为 name:<namespace/name>。将 <namespace/name> 替换为 NetworkAttachmentDefinition 的命名空间和名称。
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
    1
    指定托管集群的名称,如 example
    2
    指定 worker 节点数,例如 2
    3
    指定 pull secret 的路径,例如 /user/name/pullsecret
    4
    指定内存值,如 8Gi
    5
    指定 CPU 值,例如 2
    6
    --attach-default-network false 参数禁用默认的 pod 网络。
    7
    指定要添加到节点的额外网络,例如 name:my-namespace/my-network

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
    1
    指定托管集群的名称,如 example
    2
    指定 worker 节点数,例如 2
    3
    指定 pull secret 的路径,例如 /user/name/pullsecret
    4
    指定内存值,如 8Gi
    5
    指定 CPU 值,例如 2
    6
    --qos-class Guaranteed 参数保证为虚拟机分配了指定的 CPU 资源数量。

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
    1
    指定托管集群的名称,如 example
    2
    指定 worker 节点数,例如 2
    3
    指定 pull secret 的路径,例如 /user/name/pullsecret
    4
    指定内存值,如 8Gi
    5
    指定 CPU 值,例如 2
    6
    --vm-node-selector 标志定义包含键值对的特定节点集合。将 <label_key><label_value> 分别替换为标签的键和值。

4.3.8. 扩展节点池

您可以使用 oc scale 命令手动扩展节点池。

流程

  1. 运行以下命令:

    NODEPOOL_NAME=${CLUSTER_NAME}-work
    NODEPOOL_REPLICAS=5
    
    $ oc scale nodepool/$NODEPOOL_NAME --namespace clusters --replicas=$NODEPOOL_REPLICAS
  2. 片刻后,输入以下命令查看节点池的状态:

    $ 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 要求)为托管集群创建节点池。

流程

  1. 要创建节点池,请输入以下信息:在本例中,节点池会将更多 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
  2. 通过列出 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 版本。

  3. 一段时间后,您可以输入以下命令来检查节点池的状态:

    $ 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

  4. 输入以下命令验证节点池是否处于您期望的状态:

    $ 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 上验证托管集群创建

要验证托管集群是否已成功创建,请完成以下步骤。

流程

  1. 输入以下命令验证 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

  2. 输入以下命令验证托管集群中的所有集群 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

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.