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.com
或 quay.io
)获取镜像的过程,并将其存储在私有 registry 中。
在以下步骤中,使用 oc-mirror
工具,它是一个使用 ImageSetConfiguration
对象的二进制文件。在文件中,您可以指定以下信息:
-
要镜像的 OpenShift Container Platform 版本。版本位于
quay.io
中。 - 要镜像的额外 Operator。单独选择软件包。
- 要添加到存储库中的额外镜像。
先决条件
在启动镜像过程前,请确保 registry 服务器正在运行。
流程
要配置镜像镜像,请完成以下步骤:
-
确保
${HOME}/.docker/config.json
文件已使用您要从镜像(mirror)的 registry 更新,并使用您要将镜像推送到的私有 registry。 通过使用以下示例,创建一个
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
输入以下命令启动镜像过程:
$ oc-mirror --v2 --config imagesetconfig.yaml docker://${REGISTRY}
镜像过程完成后,有一个名为
oc-mirror-workspace/results-XXXXXX/
的新文件夹,其中包含要应用到托管的集群的 IDMS 和目录源。通过配置
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 # ...
输入以下命令将更改应用到文件:
$ oc-mirror --v2 --config imagesetconfig.yaml docker://${REGISTRY}
- 按照 在断开连接的网络中安装 中的步骤来镜像最新的多集群引擎 Operator 镜像。
6.2.3. 在管理集群中应用对象
镜像过程完成后,您需要在管理集群中应用两个对象:
-
ImageContentSourcePolicy
(ICSP) 或ImageDigestMirrorSet
(IDMS) - 目录源
使用 oc-mirror
工具时,输出工件位于名为 oc-mirror-workspace/results-XXXXXX/
的文件夹。
ICSP 或 IDMS 启动 MachineConfig
更改,它不会重启您的节点,而是在每个节点上重启 kubelet。节点标记为 READY
后,您需要应用新生成的目录源。
目录源在 openshift-marketplace
Operator 中启动操作,如下载目录镜像并处理它来检索该镜像中包含的所有 PackageManifests
。
流程
要检查新源,请使用新的
CatalogSource
作为源运行以下命令:$ oc get packagemanifest
要应用工件,请完成以下步骤:
输入以下命令创建 ICSP 或 IDMS 工件:
$ oc apply -f oc-mirror-workspace/results-XXXXXX/imageContentSourcePolicy.yaml
等待节点就绪,然后输入以下命令:
$ oc apply -f catalogSource-XXXXXXXX-index.yaml
镜像 OLM 目录并配置托管集群以指向镜像。
当您使用
management
(默认)OLMCatalogPlacement 模式时,用于 OLM 目录的镜像流不会自动满足管理集群中 ICSP 中的覆盖信息。-
如果使用原始名称和标签将 OLM 目录正确镜像到内部 registry,请将
hypershift.openshift.io/olm-catalogs-is-registry-overrides
注解添加到HostedCluster
资源。格式为"sr1=dr1,sr2=dr2"
,其中源 registry 字符串是一个键,目标 registry 是一个值。 要绕过 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
-
-
如果使用原始名称和标签将 OLM 目录正确镜像到内部 registry,请将
在这种情况下,镜像流不会被创建,您必须在 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 添加到管理集群中,请完成以下步骤。
流程
创建类似以下示例的配置映射:
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-----
对集群范围的对象
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 节点。
流程
在
hc.spec.additionalTrustBundle
文件中,添加以下规格:spec: additionalTrustBundle: - name: user-ca-bundle 1
- 1
user-ca-bundle
条目是您在下一步中创建的配置映射。
在创建
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
。
流程
输入以下命令:
$ 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 版本。
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. 部署指定基域的托管集群
要创建指定基域的托管集群,请完成以下步骤。
流程
输入以下命令:
$ 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"。
6.2.6.4.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
6.2.6.4.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 版本。
6.2.7. 完成部署
您可以从两个视角监控托管集群的部署:control plane 和数据平面。
6.2.7.1. 监控 control plane
在部署进行时,您可以通过收集有关以下工件的信息来监控 control plane:
- HyperShift Operator
-
HostedControlPlane
pod - 裸机主机
- 代理
-
InfraEnv
资源 -
HostedCluster
和NodePool
资源
流程
输入以下命令来监控 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"