6.2. 在断开连接的环境中在 OpenShift Virtualization 上部署托管的 control plane


当您在断开连接的环境中部署托管 control plane 时,其中一些步骤因您使用的平台而异。以下步骤特定于在 OpenShift Virtualization 中部署。

6.2.1. 先决条件

  • 您有一个断开连接的 OpenShift Container Platform 环境,作为您的管理集群。
  • 您有一个内部 registry 来 mirror 镜像。如需更多信息,请参阅关于断开连接的安装镜像

6.2.2. 在断开连接的环境中为托管 control plane 配置镜像镜像

镜像镜像(mirror)是从外部 registry (如 registry.redhat.comquay.io )获取镜像的过程,并将其存储在私有 registry 中。

在以下步骤中,使用 oc-mirror 工具,它是一个使用 ImageSetConfiguration 对象的二进制文件。在文件中,您可以指定以下信息:

  • 要镜像的 OpenShift Container Platform 版本。版本位于 quay.io 中。
  • 要镜像的额外 Operator。单独选择软件包。
  • 要添加到存储库中的额外镜像。

先决条件

在启动镜像过程前,请确保 registry 服务器正在运行。

流程

要配置镜像镜像,请完成以下步骤:

  1. 确保 ${HOME}/.docker/config.json 文件已使用您要从镜像(mirror)的 registry 更新,并使用您要将镜像推送到的私有 registry。
  2. 通过使用以下示例,创建一个 ImageSetConfiguration 对象以用于镜像。根据需要替换值,使其与您的环境匹配:

    apiVersion: mirror.openshift.io/v1alpha2
    kind: ImageSetConfiguration
    storageConfig:
      registry:
        imageURL: registry.<dns.base.domain.name>:5000/openshift/release/metadata:latest 1
    mirror:
      platform:
        channels:
        - name: candidate-4.17
          minVersion: 4.x.y-build  2
          maxVersion: 4.x.y-build 3
          type: ocp
        kubeVirtContainer: true 4
        graph: true
      additionalImages:
      - name: quay.io/karmab/origin-keepalived-ipfailover:latest
      - name: quay.io/karmab/kubectl:latest
      - name: quay.io/karmab/haproxy:latest
      - name: quay.io/karmab/mdns-publisher:latest
      - name: quay.io/karmab/origin-coredns:latest
      - name: quay.io/karmab/curl:latest
      - name: quay.io/karmab/kcli:latest
      - name: quay.io/user-name/trbsht:latest
      - name: quay.io/user-name/hypershift:BMSelfManage-v4.17
      - name: registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.10
      operators:
      - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.17
        packages:
        - name: lvms-operator
        - name: local-storage-operator
        - name: odf-csi-addons-operator
        - name: odf-operator
        - name: mcg-operator
        - name: ocs-operator
        - name: metallb-operator
        - name: kubevirt-hyperconverged 5
    1
    <dns.base.domain.name> 替换为 DNS 基本域名。
    2 3
    4.x.y-build 替换为您要使用的受支持 OpenShift Container Platform 版本。
    4
    如果要为 KubeVirt 供应商为 Red Hat Enterprise Linux CoreOS (RHCOS) 引导镜像镜像容器磁盘镜像,则将此可选标志设置为 true。这个标志只可用于 oc-mirror v2。
    5
    对于使用 KubeVirt 供应商的部署,请包含这一行。
  3. 输入以下命令启动镜像过程:

    $ oc-mirror --v2 --config imagesetconfig.yaml docker://${REGISTRY}

    镜像过程完成后,有一个名为 oc-mirror-workspace/results-XXXXXX/ 的新文件夹,其中包含要应用到托管的集群的 IDMS 和目录源。

  4. 通过配置 imagesetconfig.yaml 文件,对 OpenShift Container Platform 的每日或 CI 版本进行镜像,如下所示:

    apiVersion: mirror.openshift.io/v2alpha1
    kind: ImageSetConfiguration
    mirror:
      platform:
        graph: true
        release: registry.ci.openshift.org/ocp/release:4.x.y-build 1
        kubeVirtContainer: true 2
    # ...
    1
    4.x.y-build 替换为您要使用的受支持 OpenShift Container Platform 版本。
    2
    如果要为 KubeVirt 供应商为 Red Hat Enterprise Linux CoreOS (RHCOS) 引导镜像镜像容器磁盘镜像,则将此可选标志设置为 true。这个标志只可用于 oc-mirror v2。
  5. 输入以下命令将更改应用到文件:

    $ oc-mirror --v2 --config imagesetconfig.yaml docker://${REGISTRY}
  6. 按照 在断开连接的网络中安装 中的步骤来镜像最新的多集群引擎 Operator 镜像。

6.2.3. 在管理集群中应用对象

镜像过程完成后,您需要在管理集群中应用两个对象:

  • ImageContentSourcePolicy (ICSP) 或 ImageDigestMirrorSet (IDMS)
  • 目录源

使用 oc-mirror 工具时,输出工件位于名为 oc-mirror-workspace/results-XXXXXX/ 的文件夹。

ICSP 或 IDMS 启动 MachineConfig 更改,它不会重启您的节点,而是在每个节点上重启 kubelet。节点标记为 READY 后,您需要应用新生成的目录源。

目录源在 openshift-marketplace Operator 中启动操作,如下载目录镜像并处理它来检索该镜像中包含的所有 PackageManifests

流程

  1. 要检查新源,请使用新的 CatalogSource 作为源运行以下命令:

    $ oc get packagemanifest
  2. 要应用工件,请完成以下步骤:

    1. 输入以下命令创建 ICSP 或 IDMS 工件:

      $ oc apply -f oc-mirror-workspace/results-XXXXXX/imageContentSourcePolicy.yaml
    2. 等待节点就绪,然后输入以下命令:

      $ oc apply -f catalogSource-XXXXXXXX-index.yaml
  3. 镜像 OLM 目录并配置托管集群以指向镜像。

    当您使用 management (默认)OLMCatalogPlacement 模式时,用于 OLM 目录的镜像流不会自动满足管理集群中 ICSP 中的覆盖信息。

    1. 如果使用原始名称和标签将 OLM 目录正确镜像到内部 registry,请将 hypershift.openshift.io/olm-catalogs-is-registry-overrides 注解添加到 HostedCluster 资源。格式为 "sr1=dr1,sr2=dr2",其中源 registry 字符串是一个键,目标 registry 是一个值。
    2. 要绕过 OLM 目录镜像流机制,请使用 HostedCluster 资源上的以下四个注解直接指定用于 OLM Operator 目录的四个镜像的地址:

      • hypershift.openshift.io/certified-operators-catalog-image
      • hypershift.openshift.io/community-operators-catalog-image
      • hypershift.openshift.io/redhat-marketplace-catalog-image
      • hypershift.openshift.io/redhat-operators-catalog-image

在这种情况下,镜像流不会被创建,您必须在 Operator 更新中刷新内部镜像以拉取(pull)时更新注解值。

后续步骤

通过完成 为托管 control plane 断开连接的安装部署多集群引擎 Operator 中的步骤来部署多集群引擎 Operator。

6.2.4. 为托管 control plane 的断开连接的安装部署 multicluster engine Operator

Kubernetes Operator 的多集群引擎在跨供应商部署集群时会扮演重要角色。如果您没有安装 multicluster engine Operator,请参阅以下文档来了解安装它的先决条件和步骤:

6.2.5. 为托管 control plane 的断开连接的安装配置 TLS 证书

为确保断开连接的部署中正常工作,您需要在管理集群中配置 registry CA 证书,并为托管集群配置 worker 节点。

6.2.5.1. 将 registry CA 添加到管理集群中

要将 registry CA 添加到管理集群中,请完成以下步骤。

流程

  1. 创建类似以下示例的配置映射:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: <config_map_name> 1
      namespace: <config_map_namespace> 2
    data: 3
      <registry_name>..<port>: | 4
        -----BEGIN CERTIFICATE-----
        -----END CERTIFICATE-----
      <registry_name>..<port>: |
        -----BEGIN CERTIFICATE-----
        -----END CERTIFICATE-----
      <registry_name>..<port>: |
        -----BEGIN CERTIFICATE-----
        -----END CERTIFICATE-----
    1
    指定配置映射的名称。
    2
    指定配置映射的命名空间。
    3
    data 字段中,指定 registry 名称和 registry 证书内容。将 <port> 替换为 registry 服务器运行的端口,例如 5000
    4
    确保在配置映射中的数据仅使用 | 定义,而不是有其他方法,如 | -。如果使用其他方法,pod 在读取证书时可能会出现问题。
  2. 对集群范围的对象 image.config.openshift.io 进行补丁,使其包含以下规格:

    spec:
      additionalTrustedCA:
        - name: registry-config

    因此,control plane 节点可以从私有 registry 检索镜像,HyperShift Operator 可以为托管集群部署提取 OpenShift Container Platform 有效负载。

    修补对象的过程可能需要几分钟才能完成。

6.2.5.2. 将 registry CA 添加到托管集群的 worker 节点

要让托管的集群中的 data plane worker 可以从私有 registry 检索镜像,您需要将 registry CA 添加到 worker 节点。

流程

  1. hc.spec.additionalTrustBundle 文件中,添加以下规格:

    spec:
      additionalTrustBundle:
        - name: user-ca-bundle 1
    1
    user-ca-bundle 条目是您在下一步中创建的配置映射。
  2. 在创建 HostedCluster 对象的同一命名空间中,创建 user-ca-bundle 配置映射。配置映射类似以下示例:

    apiVersion: v1
    data:
      ca-bundle.crt: |
        // Registry1 CA
        -----BEGIN CERTIFICATE-----
        -----END CERTIFICATE-----
    
        // Registry2 CA
        -----BEGIN CERTIFICATE-----
        -----END CERTIFICATE-----
    
        // Registry3 CA
        -----BEGIN CERTIFICATE-----
        -----END CERTIFICATE-----
    
    kind: ConfigMap
    metadata:
      name: user-ca-bundle
      namespace: <hosted_cluster_namespace> 1
    1
    指定创建 HostedCluster 对象的命名空间。

6.2.6. 在 OpenShift Virtualization 上创建托管集群

托管的集群是一个 OpenShift Container Platform 集群,其 control plane 和 API 端点托管在管理集群中。托管的集群包括控制平面和它的对应的数据平面。

6.2.6.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 实践"和"使用逻辑卷管理器存储的持久性存储"。

6.2.6.2. 使用 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 版本。

6.2.6.3. 为 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 流量被拒绝。这个限制只适用于默认的入口行为。

6.2.6.4. 自定义入口和 DNS 行为

如果您不想使用默认的 ingress 和 DNS 行为,您可以在创建时配置带有唯一基域的 KubeVirt 托管集群。此选项需要在创建过程中手动配置步骤,并涉及三个主要步骤:集群创建、负载均衡器创建和通配符 DNS 配置。

6.2.6.4.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"。

6.2.6.4.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 节点端口值。
6.2.6.4.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 版本。

6.2.7. 完成部署

您可以从两个视角监控托管集群的部署:control plane 和数据平面。

6.2.7.1. 监控 control plane

在部署进行时,您可以通过收集有关以下工件的信息来监控 control plane:

  • HyperShift Operator
  • HostedControlPlane pod
  • 裸机主机
  • 代理
  • InfraEnv 资源
  • HostedClusterNodePool 资源

流程

  • 输入以下命令来监控 control plane:

    $ export KUBECONFIG=/root/.kcli/clusters/hub-ipv4/auth/kubeconfig
    $ watch "oc get pod -n hypershift;echo;echo;oc get pod -n clusters-hosted-ipv4;echo;echo;oc get bmh -A;echo;echo;oc get agent -A;echo;echo;oc get infraenv -A;echo;echo;oc get hostedcluster -A;echo;echo;oc get nodepool -A;echo;echo;"

6.2.7.2. 监控数据平面

在部署进行时,您可以通过收集有关以下工件的信息来监控数据平面:

  • 集群版本
  • 特别是关于节点是否加入集群
  • 集群 Operator

流程

  • 输入以下命令:

    $ oc get secret -n clusters-hosted-ipv4 admin-kubeconfig -o jsonpath='{.data.kubeconfig}' |base64 -d > /root/hc_admin_kubeconfig.yaml
    $ export KUBECONFIG=/root/hc_admin_kubeconfig.yaml
    $ watch "oc get clusterversion,nodes,co"
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.