1.7. 托管 control plane（技术预览）
使用 multicluster engine operator 集群管理，您可以使用两个不同的 control plane 配置部署 OpenShift Container Platform 集群：独立或托管的 control plane。独立配置使用专用虚拟机或物理机器来托管 OpenShift Container Platform control plane。使用 OpenShift Container Platform 托管 control plane，您可以在托管集群中创建 pod 作为 control plane，而无需为每个 control plane 专用物理机器。
为 OpenShift Container Platform 托管 control plane 作为 Amazon Web Services (AWS)、裸机和 Red Hat OpenShift Virtualization 的技术预览功能提供。您可以在 OpenShift Container Platform 版本 4.13 上托管 control plane。
注： 在托管 control plane 的同一平台上运行 hub 集群和 worker。
control plane 作为单一命名空间中包含的 pod 运行，并与托管的 control plane 集群关联。当 OpenShift Container Platform 创建这种类型的托管集群时，它会创建一个独立于 control plane 的 worker 节点。
托管 control plane 集群有几个优点：
- 通过删除对专用 control plane 节点的需求来降低成本
- 引入 control plane 和工作负载的隔离，改进了隔离并减少可能需要更改的配置错误
- 通过删除 control plane 节点 bootstrap 的要求来减少集群创建时间
- 支持 turn-key 部署或完全自定义的 OpenShift Container Platform 置备
请参阅以下高可用性托管的 control plane 要求，这些要求已使用 OpenShift Container Platform 版本 4.12.9 及更新版本进行测试：
- 78 个 pod
- Etcd 的三个 4 Gi PV，用于 OVN 三个 1Gi PV
- 最小 CPU：大约 5.5 个内核
- 最小内存：大约 19 GB
有关托管 control plane 的更多信息，请继续阅读以下主题：
1.7.1. 在 AWS 上配置托管集群（技术预览）
要配置托管的 control plane，您需要托管集群和一个托管的集群。通过使用 hypershift-addon 受管集群附加组件在现有受管集群上部署 HyperShift Operator，您可以将该集群启用为托管集群，并开始创建托管集群。
multicluster engine operator 2.3 仅支持默认的 local-cluster 和 hub 集群作为托管集群。
托管 control plane 是一个技术预览功能，因此相关组件默认是禁用的。
您可以通过将现有集群配置为充当托管集群来部署托管 control plane。托管集群是托管 control plane 的 Red Hat OpenShift Container Platform 集群。Red Hat Advanced Cluster Management 2.8 可以使用 hub 集群，也称为 local-cluster，作为托管集群。请参阅以下主题以了解如何将 local-cluster 配置为托管集群。
最佳实践： 确保在托管 control plane 的同一平台上运行 hub 集群和 worker。
1.7.1.1. 先决条件
您必须具有以下先决条件才能配置托管集群：
- Kubernetes operator 2.3 及更新版本的多集群引擎安装在 OpenShift Container Platform 集群中。安装 Red Hat Advanced Cluster Management 时会自动安装 multicluster engine operator。在没有 Red Hat Advanced Cluster Management 作为来自 OpenShift Container Platform OperatorHub 的 Operator 的情况下，也可以安装 multicluster engine operator。
multicluster engine operator 必须至少有一个受管 OpenShift Container Platform 集群。
local-cluster在多集群引擎 operator 2.3 及更新的版本中自动导入。有关local-cluster的更多信息，请参阅高级配置。您可以运行以下命令来检查 hub 集群的状态：oc get managedclusters local-cluster
- 托管集群至少有 3 个 worker 节点来运行 HyperShift Operator。
- AWS 命令行界面。
1.7.1.2. 创建 Amazon Web Services S3 存储桶和 S3 OIDC secret
如果您计划在 AWS 上创建和管理托管集群，请完成以下步骤：
创建一个 S3 存储桶，其具有集群托管 OIDC 发现文档的公共访问权限。
要在 us-east-1 区域中创建存储桶，请输入以下代码：
BUCKET_NAME=<your_bucket_name> aws s3api create-bucket --bucket $BUCKET_NAME aws s3api delete-public-access-block --bucket $BUCKET_NAME echo '{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::${BUCKET_NAME}/*" } ] }' | envsubst > policy.json aws s3api put-bucket-policy --bucket $BUCKET_NAME --policy file://policy.json要在 us-east-1 区域以外的区域中创建存储桶，请输入以下代码：
BUCKET_NAME=your-bucket-name REGION=us-east-2 aws s3api create-bucket --bucket $BUCKET_NAME \ --create-bucket-configuration LocationConstraint=$REGION \ --region $REGION aws s3api delete-public-access-block --bucket $BUCKET_NAME echo '{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::${BUCKET_NAME}/*" } ] }' | envsubst > policy.json aws s3api put-bucket-policy --bucket $BUCKET_NAME --policy file://policy.json
-
为 HyperShift Operator 创建名为
hypershift-operator-oidc-provider-s3-credentials的 OIDC S3 secret。 -
将 secret 保存到
local-cluster命名空间中。 请参阅下表来验证 secret 是否包含以下字段：
字段名称 描述 bucket包含对 HyperShift 集群托管 OIDC 发现文档的公共访问权限的 S3 存储桶。
credentials对包含可以访问存储桶的
default配置集凭证的文件的引用。默认情况下，HyperShift 仅使用default配置集来运行bucket。region指定 S3 存储桶的区域。
以下示例显示了 AWS secret 模板示例：
oc create secret generic hypershift-operator-oidc-provider-s3-credentials --from-file=credentials=$HOME/.aws/credentials --from-literal=bucket=<s3-bucket-for-hypershift> --from-literal=region=<region> -n local-cluster
注：不会自动启用 secret 的恢复备份。运行以下命令添加启用
hypershift-operator-oidc-provider-s3-credentialssecret 的标签，以便为灾难恢复进行备份：oc label secret hypershift-operator-oidc-provider-s3-credentials -n local-cluster cluster.open-cluster-management.io/backup=true
1.7.1.3. 创建可路由的公共区
要访问客户机集群中的应用程序，必须路由公共区。如果 public 区域存在，请跳过这一步。否则，公共区将影响现有功能。
运行以下命令为集群 DNS 记录创建一个公共区：
BASE_DOMAIN=www.example.com aws route53 create-hosted-zone --name $BASE_DOMAIN --caller-reference $(whoami)-$(date --rfc-3339=date)
1.7.1.4. 启用外部 DNS
因为 control plane 和数据平面在托管的 control plane 中是分开的，所以您可以在两个独立区中配置 DNS：
-
托管集群中工作负载的 Ingress，如以下域：..
apps.service-consumer-domain.com -
管理集群中的服务端点的 Ingress，如 API 或 OAUTH 端点，通过服务供应商域：...
service-provider-domain.com
hostedCluster.spec.dns 的输入指定托管集群中工作负载的 Ingress。hostedCluster.spec.services.servicePublishingStrategy.route.hostname 的输入指定管理集群中的服务端点的 Ingress。
外部 DNS 为托管的集群服务创建名称记录，用于指定 LoadBalancer 或 Route 的发布类型，并为该发布类型提供主机名。对于使用 Private 或 PublicAndPrivate 端点访问类型的托管集群，只有 APIServer 和 OAuth 服务支持主机名。对于私有托管集群，DNS 记录解析为 VPC 中虚拟私有云(VPC)端点的专用 IP。
一个托管的 control plane 会公开四个服务：
-
APIServer -
OAuthServer -
Konnectivity -
Ignition
这些服务各自通过在 HostedCluster 规格中使用 servicePublishingStrategy 来公开。默认情况下，对于 LoadBalancer 和 Route 类型的 servicePublishingStrategy，您可以以以下两种方式之一发布该服务：
-
使用处于
LoadBalancer类型的Service状态的负载均衡器的主机名 -
在
Route的status.host字段中
但是，当您在受管服务上下文中部署托管的 control plane 时，这些方法可以公开底层管理集群的 Ingress 子域，以及管理集群生命周期和灾难恢复的限制选项。
当在 LoadBalancer 和 Route 发布类型上分层 DNS 间接时，受管服务操作员可以使用服务级别域发布所有公共托管的集群服务。此架构允许在 DNS 名称上重新映射到新的 LoadBalancer 或 Route，且不会公开管理集群的 Ingress 域。托管 control plane 使用外部 DNS 实现该间接层。
您可以在管理集群的 hypershift 命名空间中部署 external-dns 和 hypershift Operator。外部 DNS 监视具有 external-dns.alpha.kubernetes.io/hostname 注解的服务或路由。该注解用于创建指向服务的 DNS 记录，如一个记录，或路由，如一个 CNAME 记录。
1.7.1.4.1. 先决条件
在为托管的 control plane 设置外部 DNS 前，您必须满足以下先决条件：
- 您可以指向的外部公共域
- 访问 AWS Route53 管理控制台
1.7.1.4.2. 为托管的 control plane 设置外部 DNS
如果您计划使用服务级别 DNS （外部 DNS）置备托管的 control plane 集群，请完成以下步骤：
-
为 HyperShift Operator 创建一个 AWS 凭证 secret，并在
local-cluster命名空间中将其命名为hypershift-operator-external-dns-credentials。 请参阅下表来验证 secret 是否具有所需字段：
字段名称 描述 可选或必需的 provider管理服务级别 DNS 区的 DNS 提供程序。
必需
domain-filter服务级别域。
必需
credentials支持所有外部 DNS 类型的凭据文件。
当使用 AWS 密钥时可选
aws-access-key-id凭证访问密钥 id。
使用 AWS DNS 服务时的可选
aws-secret-access-key凭证访问密钥 secret。
使用 AWS DNS 服务时的可选
以下示例显示了
hypershift-operator-external-dns-credentialssecret 模板示例：oc create secret generic hypershift-operator-external-dns-credentials --from-literal=provider=aws --from-literal=domain-filter=service.my.domain.com --from-file=credentials=<credentials-file> -n local-cluster
注：不会自动启用 secret 的恢复备份。要添加启用
hypershift-operator-external-dns-credentialssecret 的标签，以便进行灾难恢复，请输入以下命令：oc label secret hypershift-operator-external-dns-credentials -n local-cluster cluster.open-cluster-management.io/backup=""
1.7.1.4.3. 创建公共 DNS 托管区
您可以在 AWS Route 53 管理控制台中创建公共 DNS 托管区来用作外部 DNS domain-filter：
- 在 Route 53 管理控制台中，单击 Create hosted zone。
- 在 Hosted zone configuration 页面上，输入域名，验证 Publish 托管区域 是否选为类型，然后单击 Create hosted zone。
- 创建区域后，在 Records 选项卡上，记录 Value/Route 流量到 列中的值。
- 在主域中，创建一个 NS 记录，将 DNS 请求重定向到委派的区域。在 Value 字段中，输入您在上一步中记下的值。
- 点 Create records。
通过在新的子区中创建测试条目并使用类似以下示例的
dig命令测试 DNS 托管区来验证 DNS 托管区是否正常工作：dig +short test.user-dest-public.aws.kerberos.com 192.168.1.1
要创建为
LoadBalancer和Route服务设置主机名的托管集群，请输入以下命令，其中external-dns-domain与您创建的公共托管区匹配：hypershift create cluster aws --name=example --endpoint-access=PublicAndPrivate --external-dns-domain=service-provider-domain.com ...
本例显示了为托管集群生成的 服务 块：
platform:
aws:
endpointAccess: PublicAndPrivate
...
services:
- service: APIServer
servicePublishingStrategy:
route:
hostname: api-example.service-provider-domain.com
type: Route
- service: OAuthServer
servicePublishingStrategy:
route:
hostname: oauth-example.service-provider-domain.com
type: Route
- service: Konnectivity
servicePublishingStrategy:
type: Route
- service: Ignition
servicePublishingStrategy:
type: Route
当 Control Plane Operator 创建 Services 和 Routes 时，它会使用 external-dns.alpha.kubernetes.io/hostname 注解为它们添加注解。值是该类型的 servicePublishingStrategy 中的 hostname 字段。Control Plane Operator 将该名称用于服务端点，它预期如果设置了主机名，则存在一个机制，如 external-dns 或 otherwise，可以创建 DNS 记录。
只有公共服务才能有服务级别 DNS 间接。私有服务使用 hypershift.local 私有区，它不适用于为给定端点访问类型私有的服务设置主机名。
下表包括在什么时候它可以用来对于服务和端点组合设置主机名：
| 服务 | 公开 | PublicAndPrivate | 私有 |
|---|---|---|---|
|
| Y | Y | N |
|
| Y | Y | N |
|
| Y | N | N |
|
| Y | N | N |
1.7.1.4.4. 使用命令行界面和外部 DNS 部署集群
当外部公共托管区已存在时，您需要部署 hypershift 和 external-dns Operator。输入以下命令确保 external-dns Operator 正在运行，并且内部标记指向公共托管区：
export KUBECONFIG=<path_to_management_cluster_kubeconfig>
export AWS_CREDS=~/.aws/credentials
export REGION=<region>
hypershift create cluster aws \
--aws-creds ${AWS_CREDS} \
--instance-type m6i.xlarge \
--region ${REGION} \
--auto-repair \
--generate-ssh \
--name <cluster_name> \
--namespace clusters \
--base-domain service-consumer-domain.com \ 1
--node-pool-replicas 2 \
--pull-secret ${HOME}/pull_secret.json \
--release-image quay.io/openshift-release-dev/ocp-release:4.12.0-ec.3-x86_64 \
--external-dns-domain=service-provider-domain.com \ 2
--endpoint-access=PublicAndPrivate 31.7.1.5. 启用 AWS PrivateLink
如果您计划使用 PrivateLink 在 AWS 平台上置备托管的 control plane 集群，请完成以下步骤：
-
为 HyperShift Operator 创建一个 AWS 凭证 secret，并将其命名为
hypershift-operator-private-link-credentials。secret 必须驻留在受管集群命名空间中，该命名空间用作托管集群。如果使用local-cluster，请在local-cluster命名空间中创建 secret。 请参阅下表确认 secret 包含必填字段：
字段名称
描述
可选或必需的
region用于私有链接的区域
必需
aws-access-key-id凭证访问密钥 id。
必需
aws-secret-access-key凭证访问密钥 secret。
必需
以下示例显示了
hypershift-operator-private-link-credentialssecret 模板示例：oc create secret generic hypershift-operator-private-link-credentials --from-literal=aws-access-key-id=<aws-access-key-id> --from-literal=aws-secret-access-key=<aws-secret-access-key> --from-literal=region=<region> -n local-cluster
注：不会自动启用 secret 的恢复备份。运行以下命令添加启用
hypershift-operator-private-link-credentialssecret 的标签，以便备份灾难恢复：oc label secret hypershift-operator-private-link-credentials -n local-cluster cluster.open-cluster-management.io/backup=""
1.7.1.6. 启用托管的 control plane 功能
托管的 control plane 功能默认禁用。启用该功能还会自动启用 hypershift-addon 受管集群附加组件。
您可以运行以下命令来启用该功能：
oc patch mce multiclusterengine --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift-preview","enabled": true}]}}}' 1- 1
- 默认
MultiClusterEngine资源实例名称为multiclusterengine，但您可以通过运行以下命令来从集群中获取MultiClusterEngine名称：$ oc get mce。
oc patch mce multiclusterengine --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift-local-hosting","enabled": true}]}}}' 1- 1
- 默认
MultiClusterEngine资源实例名称为multiclusterengine，但您可以通过运行以下命令来从集群中获取MultiClusterEngine名称：$ oc get mce。
运行以下命令，以验证
MultiClusterEngine自定义资源中是否启用了hypershift-preview和hypershift-local-hosting功能：oc get mce multiclusterengine -o yaml 1- 1
- 默认
MultiClusterEngine资源实例名称为multiclusterengine，但您可以通过运行以下命令来从集群中获取MultiClusterEngine名称：$ oc get mce。
输出类似以下示例：
apiVersion: multicluster.openshift.io/v1 kind: MultiClusterEngine metadata: name: multiclusterengine spec: overrides: components: - name: hypershift-preview enabled: true - name: hypershift-local-hosting enabled: true
1.7.1.6.1. 为 local-cluster 手动启用 hypershift-addon 受管集群附加组件
启用托管的 control plane 功能会自动启用 hypershift-addon 受管集群附加组件。如果您需要手动启用 hypershift-addon 受管集群附加组件，请完成以下步骤，使用 hypershift-addon 在 local-cluster 上安装 HyperShift Operator：
通过创建一个类似以下示例的文件来创建
ManagedClusterAddonHyperShift 附加组件：apiVersion: addon.open-cluster-management.io/v1alpha1 kind: ManagedClusterAddOn metadata: name: hypershift-addon namespace: local-cluster spec: installNamespace: open-cluster-management-agent-addon
运行以下命令来应用该文件：
oc apply -f <filename>
使用您创建的文件的名称替换
filename。运行以下命令确认已安装
hypershift-addon:oc get managedclusteraddons -n local-cluster hypershift-addon
如果安装了附加组件，输出类似以下示例：
NAME AVAILABLE DEGRADED PROGRESSING hypershift-addon True
您的 HyperShift 附加组件已安装，托管集群可用于创建和管理托管集群。
1.7.1.7. 安装托管的 control plane 命令行界面
托管 control plane (hypershift)命令行界面用于创建和管理 OpenShift Container Platform 托管 control plane 集群。启用托管的 control plane 功能后，您可以通过完成以下步骤来安装托管的 control plane 命令行界面：
- 在 OpenShift Container Platform 控制台中点 Help 图标 > Command Line Tools。
为您的平台点 Download hypershift CLI。
注： 下载只有在启用了
hypershift-preview功能时才可见。运行以下命令来解包下载的归档：
tar xvzf hypershift.tar.gz
运行以下命令使二进制文件可执行：
chmod +x hypershift
运行以下命令，将二进制文件移到路径的目录中：
sudo mv hypershift /usr/local/bin/.
现在，您可以使用 hypershift create cluster 命令来创建和管理托管集群。使用以下命令列出可用的参数：
hypershift create cluster aws --help
1.7.1.8. 托管集群的灾难恢复
托管 control plane 在 multicluster engine operator hub 集群上运行。data plane 在您选择的独立平台上运行。当从灾难中恢复多集群引擎 operator hub 集群时，您可能还想恢复托管的 control plane。
请参阅 AWS 区域托管的集群的灾难恢复，以了解如何备份托管的 control plane 集群并在不同的集群中恢复它。
重要： 托管集群的灾难恢复只在 AWS 上可用。
1.7.1.9. 其他资源
有关 AWS 上托管 control plane 的更多信息，请参阅以下资源：
- 现在，您可以部署 SR-IOV Operator。如需更多信息，请参阅为托管的 control plane 部署 SR-IOV Operator。
1.7.2. 在 AWS 上管理托管的 control plane 集群（技术预览）
您可以使用 multicluster engine for Kubernetes operator 控制台创建 Red Hat OpenShift Container Platform 托管的集群。托管 control plane 在 Amazon Web Services (AWS)上作为技术预览提供。如果在 AWS 上使用托管的 control plane，您可以使用控制台创建托管集群，也可以使用控制台或命令行界面导入托管集群。
1.7.2.1. 先决条件
您必须先配置托管的 control plane，然后才能创建托管的 control plane 集群。如需更多信息，请参阅配置托管的 control plane （技术预览）。
1.7.2.2. 使用控制台在 AWS 上创建托管的 control plane 集群
要从多集群引擎 operator 控制台创建托管的 control plane 集群，请进入到 Infrastructure > Clusters。在 Clusters 页面中，点 Create cluster > Amazon Web Services > Hosted 并完成控制台中的步骤。
重要： 当您创建集群时，多集群引擎 operator 控制器为集群及其资源创建一个命名空间。确保只在该命名空间中包含该集群实例的资源。销毁集群会删除命名空间和所有资源。
如果要将集群添加到现有的集群集中，则需要在集群设置上具有正确的权限来添加它。如果在创建集群时没有 cluster-admin 权限，则必须选择一个具有 clusterset-admin 权限的集群集。如果您在指定的集群集中没有正确的权限，集群创建会失败。如果您没有任何集群设置选项，请联络您的集群管理员，为您提供 clusterset-admin 权限。
每个受管集群都必须与受管集群集关联。如果您没有将受管集群分配给 ManagedClusterSet，则会自动添加到 default 受管集群集中。
发行镜像标识用于创建集群的 OpenShift Container Platform 镜像的版本。托管的 control plane 集群必须使用其中一个提供的发行镜像。
基础架构环境中提供的代理信息会自动添加到代理字段中。您可以使用现有信息，覆盖它，或者添加信息（如果要启用代理）。以下列表包含创建代理所需的信息：
-
HTTP 代理 URL：用作
HTTP流量的代理的 URL。 -
HTTPS 代理 URL：用于
HTTPS流量的安全代理 URL。如果没有提供值，则使用相同的值HTTP Proxy URL，用于HTTP和HTTPS。 -
无代理域：应当绕过代理的以逗号分隔的域列表。使用一个句点 (
.) 开始的域名，包含该域中的所有子域。添加一个星号*以绕过所有目的地的代理。 - Additional trust bundle：访问镜像 registry 所需的证书文件内容。
注： 您必须运行随集群提供的集群详情的 oc 命令，以导入集群。创建集群时，它不会使用 Red Hat Advanced Cluster Management 管理自动配置。
1.7.2.3. 在 AWS 的多个区中创建托管集群
输入以下命令创建集群，指定公共区的 BASE_DOMAIN ：
REGION=us-east-1
ZONES=us-east-1a,us-east-1b
CLUSTER_NAME=example
BASE_DOMAIN=example.com
AWS_CREDS="$HOME/.aws/credentials"
PULL_SECRET="$HOME/pull-secret"
hypershift create cluster aws \
--name $CLUSTER_NAME \
--node-pool-replicas=3 \
--base-domain $BASE_DOMAIN \
--pull-secret $PULL_SECRET \
--aws-creds $AWS_CREDS \
--region $REGION \
--zones $ZONES 1- 1
--zones标志必须在--region标志指定的区域中指定可用区。--zones标志也可以在hypershift create infra aws命令中提供，该命令用于单独创建基础架构。
为所有指定区创建以下每个区基础架构：
- 公共子网
- 专用子网
- NAT 网关
- 专用路由表（公共路由表在公共子网之间共享）
为每个区创建一个 NodePool 资源。节点池名称按区域名称后缀。区的专用子网在 spec.platform.aws.subnet.id 中设置。
1.7.2.4. 在 AWS 上部署托管集群
设置托管的 control plane (hypershift)命令行界面并启用 local-cluster 作为托管集群后，您可以通过完成以下步骤在 AWS 上部署托管集群。要部署私有集群，请参阅在 AWS 上部署私有集群。
按如下方式设置环境变量，根据需要将变量替换为您的凭证：
export REGION=us-east-1 export CLUSTER_NAME=clc-name-hs1 export INFRA_ID=clc-name-hs1 export BASE_DOMAIN=dev09.red-chesterfield.com export AWS_CREDS=$HOME/name-aws export PULL_SECRET=/Users/username/pull-secret.txt export BUCKET_NAME=acmqe-hypershift export BUCKET_REGION=us-east-1
验证
CLUSTER_NAME和INFRA_ID是否有相同的值，否则集群可能无法在 Kubernetes operator 控制台的多集群引擎中显示。要查看每个变量的描述，请运行以下命令hypershift create cluster aws --help
- 验证您是否已登录到 hub 集群。
运行以下命令来创建托管集群：
hypershift create cluster aws \ --name $CLUSTER_NAME \ --infra-id $INFRA_ID \ --base-domain $BASE_DOMAIN \ --aws-creds $AWS_CREDS \ --pull-secret $PULL_SECRET \ --region $REGION \ --generate-ssh \ --node-pool-replicas 3 \ --namespace <hypershift-hosting-service-cluster>注： 默认情况下，所有
HostedCluster和NodePool自定义资源都是在集群命名空间中创建的。如果指定了--namespace <namespace> 参数，则会在您选择的命名空间中创建HostedCluster和NodePool自定义资源。您可以运行以下命令来检查托管集群的状态：
oc get hostedclusters -n <hypershift-hosting-service-cluster>
您可以运行以下命令来检查节点池：
oc get nodepools --namespace clusters
1.7.2.5. 访问托管集群
您可以通过直接从资源获取 kubeconfig 文件和 kubeadmin 凭证，或使用 hypershift CLI 生成 kubeconfig 文件来访问托管集群。
要通过直接从资源获取
kubeconfig文件和凭证来访问托管集群，您需要熟悉托管 control plane 集群的访问 secret。secret 存储在托管的集群（托管）命名空间中。托管的集群（托管） 命名空间包含托管的集群资源，托管的 control plane 命名空间是托管的 control plane 运行的位置。secret 名称格式如下：
-
kubeconfigsecret: <hostingNamespace>-<name>-admin-kubeconfig(clusters-hypershift-demo-admin-kubeconfig) kubeadminpassword secret: <hostingNamespace>-<name>-kubeadmin-password(clusters-hypershift-demo-kubeadmin-password)kubeconfigsecret 包含 Base64 编码的kubeconfig字段，您可以使用以下命令解码并保存到文件中：oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get nodes
kubeadmin密码 secret 也采用 Base64 编码。您可以解码它，并使用密码登录到托管集群的 API 服务器或控制台。-
要使用
hypershiftCLI 访问托管集群来生成kubeconfig文件，请执行以下步骤：输入以下命令生成
kubeconfig文件：hypershift create kubeconfig --namespace ${CLUSTERS_NAMESPACE} --name ${HOSTED_CLUSTER_NAME} > ${HOSTED_CLUSTER_NAME}.kubeconfig保存
kubeconfig文件后，您可以输入以下示例命令来访问托管集群：oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get nodes
1.7.2.6. 在 AWS 上导入托管的 control plane 集群
您可以使用控制台导入托管的 control plane 集群。
- 点 Infrastructure > Clusters 并选择您要导入的托管集群。
点 Import hosted cluster。
注： 对于 发现的 托管集群，您还可以从控制台导入，但集群必须处于可升级状态。如果托管集群没有处于可升级状态，则在集群中导入会被禁用，因为托管的 control plane 不可用。点 Import 开始进程。当集群接收更新时，状态为
Importing，然后变为Ready。
您还可以通过完成以下步骤，使用命令行界面在 AWS 上导入托管的 control plane 集群：
运行以下命令，在
HostedCluster自定义资源中添加注解：oc edit hostedcluster <cluster_name> -n clusters
将
<cluster_name> 替换为托管集群的名称。运行以下命令，将注解添加到
HostedCluster自定义资源中：cluster.open-cluster-management.io/hypershiftdeployment: local-cluster/<cluster_name> cluster.open-cluster-management.io/managedcluster-name: <cluster_name>
将
<cluster_name> 替换为托管集群的名称。使用以下示例 YAML 文件创建
ManagedCluster资源：apiVersion: cluster.open-cluster-management.io/v1 kind: ManagedCluster metadata: annotations: import.open-cluster-management.io/hosting-cluster-name: local-cluster import.open-cluster-management.io/klusterlet-deploy-mode: Hosted open-cluster-management/created-via: other labels: cloud: auto-detect cluster.open-cluster-management.io/clusterset: default name: <cluster_name> vendor: OpenShift name: <cluster_name> spec: hubAcceptsClient: true leaseDurationSeconds: 60将
<cluster_name> 替换为托管集群的名称。运行以下命令以应用资源：
oc apply -f <file_name>
将 <file_name> 替换为您在上一步中创建的 YAML 文件名。
使用以下示例 YAML 文件创建
KlusterletAddonConfig资源。这只适用于 Red Hat Advanced Cluster Management。如果您只安装了 multicluster engine operator，请跳过这一步：apiVersion: agent.open-cluster-management.io/v1 kind: KlusterletAddonConfig metadata: name: <cluster_name> namespace: <cluster_name> spec: clusterName: <cluster_name> clusterNamespace: <cluster_name> clusterLabels: cloud: auto-detect vendor: auto-detect applicationManager: enabled: true certPolicyController: enabled: true iamPolicyController: enabled: true policyController: enabled: true searchCollector: enabled: false将
<cluster_name> 替换为托管集群的名称。运行以下命令以应用资源：
oc apply -f <file_name>
将 <file_name> 替换为您在上一步中创建的 YAML 文件名。
导入过程完成后，您的托管集群会在控制台中可见。您还可以运行以下命令来检查托管集群的状态：
oc get managedcluster <cluster_name>
1.7.2.7. 在 ARM64 OpenShift Container Platform 集群上启用托管的 control plane
您可以启用 ARM64-hosted control plane，以便在管理集群环境中使用 OpenShift Container Platform ARM64 data plane。此功能仅适用于 AWS 上的托管 control plane。
1.7.2.7.1. 先决条件
开始之前，您必须满足以下先决条件：
- 您必须在 64 位 ARM 基础架构上安装 OpenShift Container Platform 集群。如需更多信息，请参阅创建 OpenShift 集群：AWS (ARM)。
-
您必须有一个基于 64 位 ARM 基础架构构建的 HyperShift Operator。您可以进入 hypershift/hypershift-operator repository 并选择带有
4.13-arm64标记的构建来获取 HyperShift Operator。
要在 ARM64 OpenShift Container Platform 集群上运行托管集群，请执行以下步骤：
在管理集群上安装 ARM64 的 HyperShift Operator，以覆盖默认 HyperShift Operator 镜像。
例如，通过托管的 control plane (
hypershift)命令行界面，输入以下命令，注意将存储桶名称、AWS 凭证和区域替换为您的信息：hypershift install \ --oidc-storage-provider-s3-bucket-name $BUCKET_NAME \ --oidc-storage-provider-s3-credentials $AWS_CREDS \ --oidc-storage-provider-s3-region $REGION \ --hypershift-image quay.io/hypershift/hypershift-operator:4.13-arm64
创建一个托管集群，以使用多架构发行镜像覆盖默认发行镜像。
例如，通过托管的 control plane (
hypershift)命令行界面，输入以下命令，将集群名称、节点池副本、基域、pull secret、AWS 凭证和区域替换为您的信息：hypershift create cluster aws \ --name $CLUSTER_NAME \ --node-pool-replicas=$NODEPOOL_REPLICAS \ --base-domain $BASE_DOMAIN \ --pull-secret $PULL_SECRET \ --aws-creds $AWS_CREDS \ --region $REGION \ --release-image quay.io/openshift-release-dev/ocp-release:4.13.0-rc.0-multi
本例通过
--node-pool-replicas标志添加默认的NodePool对象。将 64 位 x86
NodePool对象添加到托管集群。例如，通过托管的 control plane (
hypershift)命令行界面，输入以下命令，注意将集群名称、节点池名称和节点池副本替换为您的信息：hypershift create nodepool aws \ --cluster-name $CLUSTER_NAME \ --name $NODEPOOL_NAME \ --node-count=$NODEPOOL_REPLICAS
1.7.2.8. 销毁 AWS 上的托管集群
要销毁托管的集群及其受管集群资源，请完成以下步骤：
运行以下命令来删除托管集群及其后端资源：
hypershift destroy cluster aws --name <cluster_name> --infra-id <infra_id> --aws-creds <aws-credentials> --base-domain <base_domain>
根据需要替换名称。
运行以下命令，删除 multicluster engine operator 上的受管集群资源：
oc delete managedcluster <cluster_name>
将
cluster_name替换为集群的名称。
1.7.2.9. 在 AWS 上部署私有集群（技术预览）
设置托管的 control plane (hypershift)命令行界面并启用 local-cluster 作为托管集群后，您可以在 AWS 上部署托管集群或私有托管集群。要在 AWS 上部署公共托管集群，请参阅在 AWS 上部署托管集群。
默认情况下，托管的 control plane 客户机集群可以通过公共 DNS 和管理集群的默认路由器进行公开访问。
对于 AWS 上的私有集群，所有与客户机集群的通信都通过 AWS PrivateLink 进行。要为 AWS 上的私有集群配置托管的 control plane，请执行以下步骤。
重要： 虽然公共集群可以在任何区域中创建，但只能在 --aws-private-region 指定的区域中创建私有集群。
1.7.2.9.1. 先决条件
要为 AWS 启用私有托管集群，您必须首先启用 AWS PrivateLink。如需更多信息，请参阅启用 AWS PrivateLink。
1.7.2.9.2. 在 AWS 上创建私有集群
输入以下命令来创建私有集群 IAM 策略文档：
cat << EOF >> policy.json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:CreateVpcEndpointServiceConfiguration", "ec2:DescribeVpcEndpointServiceConfigurations", "ec2:DeleteVpcEndpointServiceConfigurations", "ec2:DescribeVpcEndpointServicePermissions", "ec2:ModifyVpcEndpointServicePermissions", "ec2:CreateTags", "elasticloadbalancing:DescribeLoadBalancers" ], "Resource": "\*" } ] }输入以下命令在 AWS 中创建 IAM 策略：
aws iam create-policy --policy-name=hypershift-operator-policy --policy-document=file://policy.json
输入以下命令来创建
hypershift-operatorIAM 用户：aws iam create-user --user-name=hypershift-operator
输入以下命令将策略附加到
hypershift-operator用户，将$POLICY_ARN替换为您创建的策略的 ARN：aws iam attach-user-policy --user-name=hypershift-operator --policy-arn=$POLICY_ARN
输入以下命令为用户创建 IAM 访问密钥：
aws iam create-access-key --user-name=hypershift-operator
输入以下命令创建私有集群，根据需要将变量替换为您的值：
CLUSTER_NAME=example BASE_DOMAIN=example.com AWS_CREDS="$HOME/.aws/credentials" PULL_SECRET="$HOME/pull-secret" hypershift create cluster aws \ --name $CLUSTER_NAME \ --node-pool-replicas=3 \ --base-domain $BASE_DOMAIN \ --pull-secret $PULL_SECRET \ --aws-creds $AWS_CREDS \ --region $REGION \ --endpoint-access Private 1- 1
--endpoint-access标志指定集群是公共还是私有。
集群的 API 端点可以通过私有 DNS 区域访问：
-
api.$CLUSTER_NAME.hypershift.local -
*.apps.$CLUSTER_NAME.hypershift.local
1.7.2.9.3. 访问 AWS 上的私有托管集群
要访问私有集群，您可以使用堡垒。
输入以下命令启动 bastion 实例，将
$SSH_KEY替换为要连接到堡垒的凭证：hypershift create bastion aws --aws-creds=$AWS_CREDS --infra-id=$INFRA_ID --region=$REGION --ssh-key-file=$SSH_KEY
输入以下命令在集群节点池中查找节点的专用 IP：
aws ec2 describe-instances --filter="Name=tag:kubernetes.io/cluster/$INFRA_ID,Values=owned" | jq '.Reservations[] | .Instances[] | select(.PublicDnsName=="") | .PrivateIpAddress'
输入以下命令为集群创建
kubeconfig文件，它可以复制到节点：hypershift create kubeconfig > $CLUSTER_KUBECONFIG
输入以下命令使用
create bastion命令打印的 IP 通过堡垒 SSH 到其中一个节点：ssh -o ProxyCommand="ssh ec2-user@$BASTION_IP -W %h:%p" core@$NODE_IP
在 SSH shell 中，输入以下命令将
kubeconfig文件内容复制到节点上的文件中：cat << EOF >> kubeconfig <paste kubeconfig contents> export KUBECONFIG=$PWD/kubeconfig
在 SSH shell 中，观察客户机集群状态或运行其他
oc命令，如下例所示：oc get clusteroperators oc get clusterversion
1.7.2.9.4. 其他资源
有关在 AWS 上部署公共托管集群的更多信息，请参阅在 AWS 上部署托管集群。
1.7.2.10. 为托管 control plane 管理 AWS 基础架构和 IAM 权限（技术预览）
当您在 AWS 上为 Red Hat OpenShift Container Platform 使用托管的 control plane 时，基础架构要求会因您的设置而异。
1.7.2.10.1. 先决条件
您必须先配置托管的 control plane，然后才能创建托管的 control plane 集群。如需更多信息，请参阅配置托管的 control plane （技术预览）。
1.7.2.10.2. AWS 基础架构要求
当您在 AWS 上使用托管的 control plane 时，基础架构要求适合以下类别：
- 在任意 AWS 帐户中为 HyperShift Operator 预必需和非受管基础架构
- 托管的集群 AWS 帐户中的 Prerequired 和 unmanaged 基础架构
- 在管理 AWS 帐户中托管 control planes 管理的基础架构
- 在托管的集群 AWS 帐户中托管 control plane 管理的基础架构
- 托管集群 AWS 帐户中的 Kubernetes 管理的基础架构
Prerequired 表示托管 control plane 需要 AWS 基础架构才能正常工作。Unmanaged 意味着没有 Operator 或控制器为您创建基础架构。以下小节包含有关创建 AWS 资源的详细信息。
1.7.2.10.2.1. 在任意 AWS 帐户中为 HyperShift Operator 预必需和非受管基础架构
任意 AWS 帐户取决于托管的 control plane 服务的供应商。
在自我管理的托管 control plane 中，集群服务提供商控制 AWS 帐户。集群服务提供商 是托管集群 control plane 的管理员，它负责正常运行时间。在托管的托管 control plane 中，AWS 帐户属于红帽。
在 HyperShift Operator 的预必需且非受管基础架构中，以下基础架构要求适用于管理集群 AWS 帐户：
一个 S3 Bucket
- OpenID Connect(OIDC)
路由 53 托管区域
- 托管托管集群的专用和公共条目的域
1.7.2.10.2.2. 托管的集群 AWS 帐户中的 Prerequired 和 unmanaged 基础架构
当您的基础架构在托管集群 AWS 帐户中预必需且非受管时，所有访问模式的基础架构要求如下：
- 一个 VPC
- 一个 DHCP 选项
两个子网
- 是内部数据平面子网的专用子网
- 允许从数据平面访问互联网的公共子网
- 一个互联网网关
- 一个弹性 IP
- 一个 NAT 网关
- 一个安全组(worker 节点)
- 两个路由表（一个私有和一个公共）
- 两个 Route 53 托管区域
有足够的配额用于以下项目：
- 公共托管集群的一个 Ingress 服务负载均衡器
- 私有托管集群的一个私有链接端点
注： 要使私有链路网络正常工作，托管集群 AWS 帐户中的端点区域必须与管理集群 AWS 帐户中的服务端点解析的实例区匹配。在 AWS 中，区域名称是别名，如 us-east-2b，它们不一定映射到不同帐户中的同一区域。因此，为了使私有链接正常工作，管理集群必须在其区域的所有区域中都有子网或 worker。
1.7.2.10.2.3. 在管理 AWS 帐户中托管 control planes 管理的基础架构
当您的基础架构由管理 AWS 帐户中的托管 control plane 管理时，基础架构要求因您的集群是公共、私有还是组合而不同。
对于具有公共集群的帐户，基础架构要求如下：
网络负载均衡器：负载均衡器 Kube API 服务器
- Kubernetes 创建一个安全组
卷
- 对于 etcd （取决于高可用性，一个或多个三个）
- 对于 OVN-Kube
对于带有私有集群的帐户，基础架构要求如下：
- 网络负载均衡器：负载均衡器私有路由器
- 端点服务（专用链接）
对于具有公共和私有集群的帐户，基础架构要求如下：
- 网络负载均衡器：负载均衡器公共路由器
- 网络负载均衡器：负载均衡器私有路由器
- 端点服务（专用链接）
卷：
- 对于 etcd （取决于高可用性，一个或多个三个）
- 对于 OVN-Kube
1.7.2.10.2.4. 在托管的集群 AWS 帐户中托管 control plane 管理的基础架构
当您的基础架构由托管的集群 AWS 帐户中的托管 control plane 管理时，基础架构要求会有所不同，具体取决于您的集群是公共、私有还是组合。
对于具有公共集群的帐户，基础架构要求如下：
-
节点池必须具有定义
Role和RolePolicy的 EC2 实例。
对于带有私有集群的帐户，基础架构要求如下：
- 每个可用区的一个私有链接端点
- 用于节点池的 EC2 实例
对于具有公共和私有集群的帐户，基础架构要求如下：
- 每个可用区的一个私有链接端点
- 用于节点池的 EC2 实例
1.7.2.10.2.5. 托管集群 AWS 帐户中的 Kubernetes 管理的基础架构
当 Kubernetes 在托管集群 AWS 帐户中管理您的基础架构时，基础架构要求如下：
- 默认入口的网络负载均衡器
- registry 的 S3 存储桶
1.7.2.10.3. Identity and Access Management (IAM)权限
在托管 control plane 的上下文中，使用者负责创建 Amazon 资源名称(ARN)角色。使用者 是生成权限文件的自动过程。消费者可能是命令行界面或 OpenShift Cluster Manager。托管 control plane 尝试使粒度遵守最低特权组件的原则，这意味着每个组件都使用自己的角色来运行或创建 AWS 对象，并且角色仅限于产品正常正常工作所需的角色。
托管的集群作为输入接收 ARN 角色，消费者为每个组件创建一个 AWS 权限配置。因此，组件可以通过 STS 和预配置的 OIDC IDP 进行身份验证。
以下角色由 control plane 上运行的托管 control plane 的一些组件使用，并在 data plane 上运行：
-
controlPlaneOperatorARN -
imageRegistryARN -
ingressARN -
kubeCloudControllerARN -
nodePoolManagementARN -
storageARN -
networkARN
以下示例显示了对来自托管集群的 IAM 角色的引用：
...
endpointAccess: Public
region: us-east-2
resourceTags:
- key: kubernetes.io/cluster/example-cluster-bz4j5
value: owned
rolesRef:
controlPlaneOperatorARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-control-plane-operator
imageRegistryARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-openshift-image-registry
ingressARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-openshift-ingress
kubeCloudControllerARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-cloud-controller
networkARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-cloud-network-config-controller
nodePoolManagementARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-node-pool
storageARN: arn:aws:iam::820196288204:role/example-cluster-bz4j5-aws-ebs-csi-driver-controller
type: AWS
...托管 control plane 使用的角色在以下示例中显示：
ingressARN{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "elasticloadbalancing:DescribeLoadBalancers", "tag:GetResources", "route53:ListHostedZones" ], "Resource": "\*" }, { "Effect": "Allow", "Action": [ "route53:ChangeResourceRecordSets" ], "Resource": [ "arn:aws:route53:::PUBLIC_ZONE_ID", "arn:aws:route53:::PRIVATE_ZONE_ID" ] } ] }imageRegistryARN{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:CreateBucket", "s3:DeleteBucket", "s3:PutBucketTagging", "s3:GetBucketTagging", "s3:PutBucketPublicAccessBlock", "s3:GetBucketPublicAccessBlock", "s3:PutEncryptionConfiguration", "s3:GetEncryptionConfiguration", "s3:PutLifecycleConfiguration", "s3:GetLifecycleConfiguration", "s3:GetBucketLocation", "s3:ListBucket", "s3:GetObject", "s3:PutObject", "s3:DeleteObject", "s3:ListBucketMultipartUploads", "s3:AbortMultipartUpload", "s3:ListMultipartUploadParts" ], "Resource": "\*" } ] }storageARN{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:AttachVolume", "ec2:CreateSnapshot", "ec2:CreateTags", "ec2:CreateVolume", "ec2:DeleteSnapshot", "ec2:DeleteTags", "ec2:DeleteVolume", "ec2:DescribeInstances", "ec2:DescribeSnapshots", "ec2:DescribeTags", "ec2:DescribeVolumes", "ec2:DescribeVolumesModifications", "ec2:DetachVolume", "ec2:ModifyVolume" ], "Resource": "\*" } ] }networkARN{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:DescribeInstances", "ec2:DescribeInstanceStatus", "ec2:DescribeInstanceTypes", "ec2:UnassignPrivateIpAddresses", "ec2:AssignPrivateIpAddresses", "ec2:UnassignIpv6Addresses", "ec2:AssignIpv6Addresses", "ec2:DescribeSubnets", "ec2:DescribeNetworkInterfaces" ], "Resource": "\*" } ] }kubeCloudControllerARN{ "Version": "2012-10-17", "Statement": [ { "Action": [ "ec2:DescribeInstances", "ec2:DescribeImages", "ec2:DescribeRegions", "ec2:DescribeRouteTables", "ec2:DescribeSecurityGroups", "ec2:DescribeSubnets", "ec2:DescribeVolumes", "ec2:CreateSecurityGroup", "ec2:CreateTags", "ec2:CreateVolume", "ec2:ModifyInstanceAttribute", "ec2:ModifyVolume", "ec2:AttachVolume", "ec2:AuthorizeSecurityGroupIngress", "ec2:CreateRoute", "ec2:DeleteRoute", "ec2:DeleteSecurityGroup", "ec2:DeleteVolume", "ec2:DetachVolume", "ec2:RevokeSecurityGroupIngress", "ec2:DescribeVpcs", "elasticloadbalancing:AddTags", "elasticloadbalancing:AttachLoadBalancerToSubnets", "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer", "elasticloadbalancing:CreateLoadBalancer", "elasticloadbalancing:CreateLoadBalancerPolicy", "elasticloadbalancing:CreateLoadBalancerListeners", "elasticloadbalancing:ConfigureHealthCheck", "elasticloadbalancing:DeleteLoadBalancer", "elasticloadbalancing:DeleteLoadBalancerListeners", "elasticloadbalancing:DescribeLoadBalancers", "elasticloadbalancing:DescribeLoadBalancerAttributes", "elasticloadbalancing:DetachLoadBalancerFromSubnets", "elasticloadbalancing:DeregisterInstancesFromLoadBalancer", "elasticloadbalancing:ModifyLoadBalancerAttributes", "elasticloadbalancing:RegisterInstancesWithLoadBalancer", "elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer", "elasticloadbalancing:AddTags", "elasticloadbalancing:CreateListener", "elasticloadbalancing:CreateTargetGroup", "elasticloadbalancing:DeleteListener", "elasticloadbalancing:DeleteTargetGroup", "elasticloadbalancing:DescribeListeners", "elasticloadbalancing:DescribeLoadBalancerPolicies", "elasticloadbalancing:DescribeTargetGroups", "elasticloadbalancing:DescribeTargetHealth", "elasticloadbalancing:ModifyListener", "elasticloadbalancing:ModifyTargetGroup", "elasticloadbalancing:RegisterTargets", "elasticloadbalancing:SetLoadBalancerPoliciesOfListener", "iam:CreateServiceLinkedRole", "kms:DescribeKey" ], "Resource": [ "\*" ], "Effect": "Allow" } ] }nodePoolManagementARN{ "Version": "2012-10-17", "Statement": [ { "Action": [ "ec2:AllocateAddress", "ec2:AssociateRouteTable", "ec2:AttachInternetGateway", "ec2:AuthorizeSecurityGroupIngress", "ec2:CreateInternetGateway", "ec2:CreateNatGateway", "ec2:CreateRoute", "ec2:CreateRouteTable", "ec2:CreateSecurityGroup", "ec2:CreateSubnet", "ec2:CreateTags", "ec2:DeleteInternetGateway", "ec2:DeleteNatGateway", "ec2:DeleteRouteTable", "ec2:DeleteSecurityGroup", "ec2:DeleteSubnet", "ec2:DeleteTags", "ec2:DescribeAccountAttributes", "ec2:DescribeAddresses", "ec2:DescribeAvailabilityZones", "ec2:DescribeImages", "ec2:DescribeInstances", "ec2:DescribeInternetGateways", "ec2:DescribeNatGateways", "ec2:DescribeNetworkInterfaces", "ec2:DescribeNetworkInterfaceAttribute", "ec2:DescribeRouteTables", "ec2:DescribeSecurityGroups", "ec2:DescribeSubnets", "ec2:DescribeVpcs", "ec2:DescribeVpcAttribute", "ec2:DescribeVolumes", "ec2:DetachInternetGateway", "ec2:DisassociateRouteTable", "ec2:DisassociateAddress", "ec2:ModifyInstanceAttribute", "ec2:ModifyNetworkInterfaceAttribute", "ec2:ModifySubnetAttribute", "ec2:ReleaseAddress", "ec2:RevokeSecurityGroupIngress", "ec2:RunInstances", "ec2:TerminateInstances", "tag:GetResources", "ec2:CreateLaunchTemplate", "ec2:CreateLaunchTemplateVersion", "ec2:DescribeLaunchTemplates", "ec2:DescribeLaunchTemplateVersions", "ec2:DeleteLaunchTemplate", "ec2:DeleteLaunchTemplateVersions" ], "Resource": [ "\*" ], "Effect": "Allow" }, { "Condition": { "StringLike": { "iam:AWSServiceName": "elasticloadbalancing.amazonaws.com" } }, "Action": [ "iam:CreateServiceLinkedRole" ], "Resource": [ "arn:*:iam::*:role/aws-service-role/elasticloadbalancing.amazonaws.com/AWSServiceRoleForElasticLoadBalancing" ], "Effect": "Allow" }, { "Action": [ "iam:PassRole" ], "Resource": [ "arn:*:iam::*:role/*-worker-role" ], "Effect": "Allow" } ] }controlPlaneOperatorARN{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:CreateVpcEndpoint", "ec2:DescribeVpcEndpoints", "ec2:ModifyVpcEndpoint", "ec2:DeleteVpcEndpoints", "ec2:CreateTags", "route53:ListHostedZones" ], "Resource": "\*" }, { "Effect": "Allow", "Action": [ "route53:ChangeResourceRecordSets", "route53:ListResourceRecordSets" ], "Resource": "arn:aws:route53:::%s" } ] }
1.7.2.10.4. 单独创建 AWS 基础架构和 IAM 资源
默认情况下，hypershift create cluster aws 命令创建带有托管集群的云基础架构并应用它。您可以单独创建云基础架构部分，以便 hypershift create cluster aws 命令只能用于创建集群，或者呈现它，以便在应用它前修改它。
要单独创建云基础架构部分，您需要创建 AWS 基础架构，创建 AWS Identity and Access (IAM)资源，并创建集群。
1.7.2.10.4.1. 创建 AWS 基础架构
运行以下命令来创建 AWS 基础架构：
hypershift create infra aws --name CLUSTER_NAME \ 1 --aws-creds AWS_CREDENTIALS_FILE \ 2 --base-domain BASEDOMAIN \ 3 --infra-id INFRA_ID \ 4 --region REGION \ 5 --output-file OUTPUT_INFRA_FILE 6
- 1
- 将
CLUSTER_NAME替换为您要创建的托管集群的名称。这个值用于为集群创建 Route 53 私有托管区。 - 2
- 将
AWS_CREDENTIALS_FILE替换为 AWS 凭证文件的名称，该文件具有为集群创建基础架构资源的权限，如 VPC、子网和 NAT 网关。这个值必须与 worker 所在的客户机集群的 AWS 帐户对应。 - 3
- 将
BASEDOMAIN替换为您计划用于托管集群 Ingress 的基域的名称。这个值必须与您可以在其中创建记录的 Route 53 公共区对应。 - 4
- 将
INFRA_ID替换为使用标签标识基础架构的唯一名称。这个值供 Kubernetes 中的云控制器管理器和集群 API 管理器使用，以识别集群的基础架构。通常，这个值是集群的名称(CLUSTER_NAME)，后缀附加到其中。 - 5
- 使用您要为集群创建基础架构的区域替换
REGION。 - 6
- 将
OUTPUT_INFRA_FILE替换为您要以 JSON 格式存储基础架构的 ID 的文件名称。您可以使用此文件作为hypershift create cluster aws命令的输入，来填充HostedCluster和NodePoolresouces 中的字段。
输入以下命令后，会创建以下资源：
- 一个 VPC
- 一个 DHCP 选项
- 一个专用子网
- 一个公共子网
- 一个互联网网关
- 一个 NAT 网关
- 一个用于 worker 节点的安全组
- 两个路由表：1 个私有和 1 个公共
- 两个私有托管区：1 用于集群 Ingress，1 代表 PrivateLink，如果您创建一个私有集群
所有这些资源都包含 kubernetes.io/cluster/INFRA_ID=owned 标签，其中 INFRA_ID 是您在命令中指定的值。
1.7.2.10.4.2. 创建 AWS IAM 资源
运行以下命令来创建 AWS IAM 资源：
hypershift create iam aws --infra-id INFRA_ID \ 1 --aws-creds AWS_CREDENTIALS_FILE \ 2 --oidc-storage-provider-s3-bucket-name OIDC_BUCKET_NAME \ 3 --oidc-storage-provider-s3-region OIDC_BUCKET_REGION \ 4 --region REGION \ 5 --public-zone-id PUBLIC_ZONE_ID \ 6 --private-zone-id PRIVATE_ZONE_ID \ 7 --local-zone-id LOCAL_ZONE_ID \ 8 --output-file OUTPUT_IAM_FILE 9
- 1
- 将
INFRA_ID替换为您在create infra aws命令中指定的相同 ID。这个值标识与托管集群关联的 IAM 资源。 - 2
- 将
AWS_CREDENTIALS_FILE替换为具有创建 IAM 资源权限的 AWS 凭证文件的名称，如角色。此文件不需要是您为创建基础架构指定的相同凭据文件，但它必须与相同的 AWS 帐户对应。 - 3
- 将
OIDC_BUCKET_NAME替换为存储 OIDC 文档的存储桶的名称。此存储桶是作为安装托管 control plane 的先决条件创建的。bucket 的名称用于为这个命令创建的 OIDC 供应商构建 URL。 - 4
- 将
OIDC_BUCKET_REGION替换为 OIDC 存储桶所在的区域。 - 5
- 将
REGION替换为集群基础架构所在的区域。这个值用于为属于托管集群的机器创建 worker 实例配置集。 - 6
- 将
PUBLIC_ZONE_ID替换为客户机集群公共区的 ID。这个值用于为 Ingress Operator 创建策略。您可以在create infra aws命令生成的OUTPUT_INFRA_FILE中找到这个值。 - 7
- 将
PRIVATE_ZONE_ID替换为客户机集群的私有区 ID。这个值用于为 Ingress Operator 创建策略。您可以在create infra aws命令生成的OUTPUT_INFRA_FILE中找到这个值。 - 8
- 在创建私有集群时，将
LOCAL_ZONE_ID替换为客户机集群的本地区 ID。这个值用于为 Control Plane Operator 创建策略，以便它可以管理 PrivateLink 端点的记录。您可以在create infra aws命令生成的OUTPUT_INFRA_FILE中找到这个值。 - 9
- 将
OUTPUT_IAM_FILE替换为计划以 JSON 格式存储 IAM 资源的 ID 的文件名称。然后，您可以将此文件作为hypershift create cluster aws命令的输入来填充HostedCluster和NodePool资源中的字段。
输入以下命令后，会创建以下资源：
- 一个 OIDC 供应商，需要启用 STS 验证
- 七家角色，每个组件都分开与提供程序交互，如 Kubernetes 控制器管理器、集群 API 供应商和 registry
- 一个实例配置集，它是分配给集群中的所有 worker 实例的配置集
1.7.2.10.4.3. 创建集群
运行以下命令来创建集群：
hypershift create cluster aws \ 1 --infra-id INFRA_ID \ 2 --name CLUSTER_NAME \ 3 --aws-creds AWS_CREDENTIALS \ 4 --infra-json OUTPUT_INFRA_FILE \ 5 --iam-json OUTPUT_IAM_FILE \ 6 --pull-secret PULL_SECRET_FILE \ 7 --generate-ssh \ 8 --node-pool-replicas 3
- 1
- 将
INFRA_ID替换为您在create infra aws命令中指定的相同 ID。这个值标识与托管集群关联的 IAM 资源。 - 2
- 将
CLUSTER_NAME替换为您在create infra aws命令中指定的相同名称。 - 3
- 将
AWS_CREDENTIALS替换为您在create infra aws命令中指定的相同值。 - 4
- 将
OUTPUT_INFRA_FILE替换为保存create infra aws命令的输出的文件的名称。 - 5
- 将
OUTPUT_IAM_FILE替换为保存create iam aws命令的输出的文件的名称。 - 6
- 将
PULL_SECRET_FILE替换为包含有效 OpenShift Container Platform pull secret 的文件的名称。 - 7 8
--generate-ssh标志是可选的，但在您需要 SSH 到 worker 时包括。为您生成 SSH 密钥，并作为 secret 存储在与托管集群相同的命名空间中。
您还可以在命令中添加 --render 标志，并将输出重定向到可编辑资源的文件，然后再将它们应用到集群。
运行命令后，以下资源会应用到集群：
- 一个命名空间
- 带有 pull secret 的 secret
-
A
HostedCluster -
A
NodePool - control plane 组件的三个 AWS STS secret
-
如果您指定了
--generate-ssh标志，则一个 SSH 密钥 secret。
1.7.3. 在裸机上配置托管集群（技术预览）
您可以通过将集群配置为充当托管集群来部署托管 control plane。托管的集群是托管 control plane 的 OpenShift Container Platform 集群。托管集群也称为 管理集群。
注： 管理集群 与受管集群 不同。受管集群是一个 hub 集群管理的集群。
您可以使用 hypershift 附加组件将受管集群启用为托管集群，以将 HyperShift Operator 部署到该集群中。然后，您可以开始创建托管集群。
multicluster engine operator 2.3 只支持默认的 local-cluster，它是一个托管的 hub 集群，以及 hub 集群作为托管集群。
托管 control plane 是一个技术预览功能，因此相关组件默认是禁用的。
在 Red Hat Advanced Cluster Management 2.7 中，您可以使用受管 hub 集群（也称为 local-cluster ），作为托管集群。
重要：
- 在托管 control plane 的同一平台上运行 hub 集群和 worker。
- 要在裸机上置备托管的 control plane，您可以使用 Agent 平台。Agent 平台使用中央基础架构管理服务将 worker 节点添加到托管集群。有关中央基础架构管理服务简介，请参阅 Kube API - 入门指南。
-
每个裸机主机都必须使用中央基础架构管理提供的发现镜像启动。您可以使用
Cluster-Baremetal-Operator手动启动主机或通过自动化启动主机。每个主机启动后，它运行一个 Agent 进程来发现主机详情并完成安装。Agent自定义资源代表每个主机。 - 当使用 Agent 平台创建托管集群时，HyperShift 在托管的 control plane 命名空间中安装 Agent Cluster API 供应商。
- 当您扩展节点池时，会创建一个机器。Cluster API 供应商找到一个经过批准的代理，正在传递验证，当前没有被使用，并满足节点池规格中指定的要求。您可以通过检查其状态和条件来监控代理的安装。
- 当您缩减节点池时，代理会从对应的集群中绑定。在重复使用集群前，您必须使用 Discovery 镜像更新节点数量来重启它们。
1.7.3.1. 先决条件
您必须具有以下先决条件才能配置托管集群：
- 您需要 multicluster engine for Kubernetes operator 2.3 及更新的版本，并在 OpenShift Container Platform 集群上安装。安装 Red Hat Advanced Cluster Management 时会自动安装 multicluster engine operator。您还可以在没有 Red Hat Advanced Cluster Management 作为 OpenShift Container Platform OperatorHub 的 Operator 的情况下安装 multicluster engine operator。
您需要 multicluster engine operator，必须至少有一个受管 OpenShift Container Platform 集群。
local-cluster在多集群引擎 operator 2.3 及更新的版本中自动导入。有关local-cluster的更多信息，请参阅高级配置。您可以运行以下命令来检查 hub 集群的状态：oc get managedclusters local-cluster
- 您需要至少 3 个 worker 节点的托管集群来运行 HyperShift Operator。
- 您需要启用中央基础架构管理。如需更多信息 ，请参阅启用中央基础架构管理服务。
- 您必须启用托管的 control plane 功能。如需更多信息，请参阅启用托管的 control plane 功能。
1.7.3.2. 裸机基础架构要求
Agent 平台不创建任何基础架构，但它对基础架构有以下要求：
- Agent ：代理代表使用发现镜像引导的主机，并准备好作为 OpenShift Container Platform 节点置备。
- DNS ：API 和 Ingress 端点必须可以被路由。
1.7.3.3. 在裸机上配置托管的控制平面
满足先决条件后，完成以下步骤以在裸机上配置托管的 control plane：
1.7.3.4. 在裸机上配置 DNS （技术预览）
托管集群的 API 服务器作为 NodePort 服务公开。必须存在 api.${HOSTED_CLUSTER_NAME}.${BASEDOMAIN} 的 DNS 条目，指向可访问 API 服务器的目的地。
DNS 条目可以像一个记录一样简单，指向运行托管 control plane 的受管集群中的一个节点。该条目也可以指向部署的负载均衡器，以将传入的流量重定向到 Ingress pod。
请参见以下 DNS 配置示例：
api.example.krnl.es. IN A 192.168.122.20 api.example.krnl.es. IN A 192.168.122.21 api.example.krnl.es. IN A 192.168.122.22 api-int.example.krnl.es. IN A 192.168.122.20 api-int.example.krnl.es. IN A 192.168.122.21 api-int.example.krnl.es. IN A 192.168.122.22 `*`.apps.example.krnl.es. IN A 192.168.122.23
1.7.3.5. 为裸机上托管 control plane 创建 InfraEnv 资源（技术预览）
InfraEnv 是启动实时 ISO 的主机可以加入为代理的环境。在这种情况下，代理会在与您托管的 control plane 相同的命名空间中创建。
创建
InfraEnv资源：创建 YAML 文件使其包含配置：
apiVersion: agent-install.openshift.io/v1beta1 kind: InfraEnv metadata: name: ${HOSTED_CLUSTER_NAME} namespace: ${HOSTED_CONTROL_PLANE_NAMESPACE} spec: pullSecretRef: name: pull-secret sshAuthorizedKey: ${SSH_PUB_KEY}-
将文件保存为
infraenv-config.yaml。 - 输入以下命令应用配置：
oc apply -f infraenv-config.yaml
要获取用于下载允许虚拟机或裸机作为代理加入的实时 ISO 的 URL，请输入以下命令：
oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get InfraEnv ${HOSTED_CLUSTER_NAME} -ojsonpath="{.status.isoDownloadURL}"
1.7.3.6. 在 InfraEnv 资源中添加代理（技术预览）
您可以通过手动将机器配置为使用 live ISO 或使用 Metal3 来添加代理。
1.7.3.6.1. 手动添加代理
-
下载 live ISO，并使用它来启动主机（裸机或虚拟机）。live ISO 的 URL 可以在
InfraEnv资源（在status.isoDownloadURL字段中）中找到。在启动时，主机与 Assisted Service 通信，并注册为与InfraEnv资源相同的命名空间中的代理。 要列出代理及其某些属性，请输入以下命令：
oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agents请参见以下示例输出：
NAME CLUSTER APPROVED ROLE STAGE 86f7ac75-4fc4-4b36-8130-40fa12602218 auto-assign e57a637f-745b-496e-971d-1abbf03341ba auto-assign
创建每个代理后，您可以选择在规格中设置
installation_disk_id和hostname，并输入以下命令批准代理：oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} patch agent 86f7ac75-4fc4-4b36-8130-40fa12602218 -p '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-0.example.krnl.es"}}' --type merge oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} patch agent 23d0c614-2caa-43f5-b7d3-0b3564688baa -p '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-1.example.krnl.es"}}' --type merge要验证代理是否已批准使用，请输入以下命令并检查输出：
oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agents请参见以下示例输出：
NAME CLUSTER APPROVED ROLE STAGE 86f7ac75-4fc4-4b36-8130-40fa12602218 true auto-assign e57a637f-745b-496e-971d-1abbf03341ba true auto-assign
1.7.3.6.2. 使用 Metal3 添加代理
重要： 因为 BareMetalHost 对象是在裸机 Operator 命名空间外创建的，所以您必须将 Operator 配置为监视所有命名空间。
输入以下命令：
oc patch provisioning provisioning-configuration --type merge -p '{"spec":{"watchAllNamespaces": true }}'metal3pod 在openshift-machine-api命名空间中重启。输入以下命令，它会持续检查 pod 的状态，并在它就绪时返回状态：
oc wait -n openshift-machine-api $(oc get pods -n openshift-machine-api -l baremetal.openshift.io/cluster-baremetal-operator=metal3-state -o name) --for condition=containersready --timeout 5m
运行以下命令来创建
BareMetalHost对象。您需要配置几个启动裸机主机所需的变量。export BMC_USERNAME=$(echo -n "root" | base64 -w0) 1 export BMC_PASSWORD=$(echo -n "calvin" | base64 -w0) 2 export BMC_IP="192.168.124.228" 3 export WORKER_NAME="ocp-worker-0" 4 export BOOT_MAC_ADDRESS="aa:bb:cc:dd:ee:ff" 5 export UUID="1" 6 export REDFISH_SCHEME="redfish-virtualmedia" 7 export REDFISH="${REDFISH_SCHEME}://${BMC_IP}/redfish/v1/Systems/${UUID}" 8
- 1
- 连接到 BMC 的用户名。
- 2
- 连接到 BMC 的密码。
- 3
- Metal3 用于连接到 BMC 的 IP 地址。
- 4
BareMetalHost对象的名称。这个值也用作主机名。- 5
- 连接到机器网络的 NIC 的 MAC 地址。
- 6
- Redfish UUID。这个值通常是
1。如果您使用 sushy-tools，这个值是一个较长的 UUID。如果您使用 iDrac，则该值为System.Embedded.1。您可能需要与供应商进行检查。 - 7
- 要使用的 Redfish 供应商。如果您使用使用标准 Redfish 实现的硬件，您可以将此值设置为
redfish-virtualmedia。如果使用 iDrac，则这个值为idrac-virtualmedia。如果您使用 iLO5，则这个值为ilo5-virtualmedia。您可能需要与供应商进行检查。 - 8
- Redfish 连接端点。
按照以下步骤创建
BareMetalHost对象：创建 BMC Secret：
oc apply -f - apiVersion: v1 data: password: ${BMC_PASSWORD} username: ${BMC_USERNAME} kind: Secret metadata: name: ${WORKER_NAME}-bmc-secret namespace: ${HOSTED_CONTROL_PLANE_NAMESPACE} type: Opaque创建
BareMetalHost对象：注：
infraenvs.agent-install.openshift.io标签用于指定用于启动BareMetalHost的InfraEnv。bmac.agent-install.openshift.io/hostname标签用于手动设置主机名。如果要手动指定安装磁盘，您可以使用
BareMetalHost规格中的rootDeviceHints。如果没有提供rootDeviceHints，代理会选择最适合安装要求的安装磁盘。有关rootDeviceHints的更多信息，请参阅BareMetalHost文档中的 rootDeviceHints 部分。oc apply -f - apiVersion: metal3.io/v1alpha1 kind: BareMetalHost metadata: name: ${WORKER_NAME} namespace: ${HOSTED_CONTROL_PLANE_NAMESPACE} labels: infraenvs.agent-install.openshift.io: ${HOSTED_CLUSTER_NAME} annotations: inspect.metal3.io: disabled bmac.agent-install.openshift.io/hostname: ${WORKER_NAME} spec: automatedCleaningMode: disabled bmc: disableCertificateVerification: True address: ${REDFISH} credentialsName: ${WORKER_NAME}-bmc-secret bootMACAddress: ${BOOT_MAC_ADDRESS} online: true代理被自动批准。如果没有批准，请确认
bootMACAddress正确。BareMetalHost被置备：oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get bmh请参见以下示例输出：
NAME STATE CONSUMER ONLINE ERROR AGE ocp-worker-0 provisioning true 2m50s
BareMetalHost最终达到置备状态：oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get bmh请参见以下示例输出：
NAME STATE CONSUMER ONLINE ERROR AGE ocp-worker-0 provisioned true 72s
provisioned 意味着主机被配置为从 virtualCD 正确启动。显示代理需要一些时间：
oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agent请参见以下示例输出：
NAME CLUSTER APPROVED ROLE STAGE 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 true auto-assign
代理被自动批准。
对所有其他主机重复此步骤：
oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agent请参见以下示例输出：
NAME CLUSTER APPROVED ROLE STAGE 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 true auto-assign d9198891-39f4-4930-a679-65fb142b108b true auto-assign da503cf1-a347-44f2-875c-4960ddb04091 true auto-assign
1.7.3.6.3. 其他资源
有关 rootDeviceHints 的更多信息，请参阅 BareMetalHost 文档中的 rootDeviceHints 部分。
1.7.3.7. 在裸机上创建托管集群（技术预览）
验证您是否为集群配置了默认存储类。否则，可能会以待处理的 PVC 结束。
输入以下命令，将任何示例变量替换为您的信息：
export CLUSTERS_NAMESPACE="clusters" export HOSTED_CLUSTER_NAME="example" export HOSTED_CONTROL_PLANE_NAMESPACE="${CLUSTERS_NAMESPACE}-${HOSTED_CLUSTER_NAME}" 1 export BASEDOMAIN="krnl.es" export PULL_SECRET_FILE=$PWD/pull-secret export MACHINE_CIDR=192.168.122.0/24 oc create ns ${HOSTED_CONTROL_PLANE_NAMESPACE} hypershift create cluster agent \ --name=${HOSTED_CLUSTER_NAME} \ --pull-secret=${PULL_SECRET_FILE} \ --agent-namespace=${HOSTED_CONTROL_PLANE_NAMESPACE} \ --base-domain=${BASEDOMAIN} \ --api-server-address=api.${HOSTED_CLUSTER_NAME}.${BASEDOMAIN} \- 1
- 通常，命名空间由 HyperShift Operator 创建，但代理集群创建会生成需要命名空间已存在的集群 API 供应商角色。
片刻后，输入以下命令验证托管的 control plane pod 是否正在运行：
oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get pods请参见以下示例输出：
NAME READY STATUS RESTARTS AGE capi-provider-7dcf5fc4c4-nr9sq 1/1 Running 0 4m32s catalog-operator-6cd867cc7-phb2q 2/2 Running 0 2m50s certified-operators-catalog-884c756c4-zdt64 1/1 Running 0 2m51s cluster-api-f75d86f8c-56wfz 1/1 Running 0 4m32s cluster-autoscaler-7977864686-2rz4c 1/1 Running 0 4m13s cluster-network-operator-754cf4ffd6-lwfm2 1/1 Running 0 2m51s cluster-policy-controller-784f995d5-7cbrz 1/1 Running 0 2m51s cluster-version-operator-5c68f7f4f8-lqzcm 1/1 Running 0 2m51s community-operators-catalog-58599d96cd-vpj2v 1/1 Running 0 2m51s control-plane-operator-f6b4c8465-4k5dh 1/1 Running 0 4m32s etcd-0 1/1 Running 0 4m13s hosted-cluster-config-operator-c4776f89f-dt46j 1/1 Running 0 2m51s ignition-server-7cd8676fc5-hjx29 1/1 Running 0 4m22s ingress-operator-75484cdc8c-zhdz5 1/2 Running 0 2m51s konnectivity-agent-c5485c9df-jsm9s 1/1 Running 0 4m13s konnectivity-server-85dc754888-7z8vm 1/1 Running 0 4m13s kube-apiserver-db5fb5549-zlvpq 3/3 Running 0 4m13s kube-controller-manager-5fbf7b7b7b-mrtjj 1/1 Running 0 90s kube-scheduler-776c59d757-kfhv6 1/1 Running 0 3m12s machine-approver-c6b947895-lkdbk 1/1 Running 0 4m13s oauth-openshift-787b87cff6-trvd6 2/2 Running 0 87s olm-operator-69c4657864-hxwzk 2/2 Running 0 2m50s openshift-apiserver-67f9d9c5c7-c9bmv 2/2 Running 0 89s openshift-controller-manager-5899fc8778-q89xh 1/1 Running 0 2m51s openshift-oauth-apiserver-569c78c4d-568v8 1/1 Running 0 2m52s packageserver-ddfffb8d7-wlz6l 2/2 Running 0 2m50s redhat-marketplace-catalog-7dd77d896-jtxkd 1/1 Running 0 2m51s redhat-operators-catalog-d66b5c965-qwhn7 1/1 Running 0 2m51s
接下来，您可以按照访问托管集群 中的步骤 访问托管集群。
1.7.3.8. 验证托管集群创建（技术预览）
部署过程完成后，您可以验证托管集群是否已成功创建。在创建托管集群后，按照以下步骤操作。
输入 extract 命令获取新托管集群的 kubeconfig ：
oc extract -n kni21 secret/kni21-admin-kubeconfig --to=- > kubeconfig-kni21 # kubeconfig
使用 kubeconfig 查看托管集群的集群 Operator。输入以下命令：
oc get co --kubeconfig=kubeconfig-kni21
请参见以下示例输出：
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE console 4.10.26 True False False 2m38s csi-snapshot-controller 4.10.26 True False False 4m3s dns 4.10.26 True False False 2m52s image-registry 4.10.26 True False False 2m8s ingress 4.10.26 True False False 22m kube-apiserver 4.10.26 True False False 23m kube-controller-manager 4.10.26 True False False 23m kube-scheduler 4.10.26 True False False 23m kube-storage-version-migrator 4.10.26 True False False 4m52s monitoring 4.10.26 True False False 69s network 4.10.26 True False False 4m3s node-tuning 4.10.26 True False False 2m22s openshift-apiserver 4.10.26 True False False 23m openshift-controller-manager 4.10.26 True False False 23m openshift-samples 4.10.26 True False False 2m15s operator-lifecycle-manager 4.10.26 True False False 22m operator-lifecycle-manager-catalog 4.10.26 True False False 23m operator-lifecycle-manager-packageserver 4.10.26 True False False 23m service-ca 4.10.26 True False False 4m41s storage 4.10.26 True False False 4m43s
您还可以输入以下命令查看托管集群中运行的 pod：
oc get pods -A --kubeconfig=kubeconfig-kni21
请参见以下示例输出：
NAMESPACE NAME READY STATUS RESTARTS AGE kube-system konnectivity-agent-khlqv 0/1 Running 0 3m52s kube-system konnectivity-agent-nrbvw 0/1 Running 0 4m24s kube-system konnectivity-agent-s5p7g 0/1 Running 0 4m14s kube-system kube-apiserver-proxy-asus3-vm1.kni.schmaustech.com 1/1 Running 0 5m56s kube-system kube-apiserver-proxy-asus3-vm2.kni.schmaustech.com 1/1 Running 0 6m37s kube-system kube-apiserver-proxy-asus3-vm3.kni.schmaustech.com 1/1 Running 0 6m17s openshift-cluster-node-tuning-operator cluster-node-tuning-operator-798fcd89dc-9cf2k 1/1 Running 0 20m openshift-cluster-node-tuning-operator tuned-dhw5p 1/1 Running 0 109s openshift-cluster-node-tuning-operator tuned-dlp8f 1/1 Running 0 110s openshift-cluster-node-tuning-operator tuned-l569k 1/1 Running 0 109s openshift-cluster-samples-operator cluster-samples-operator-6b5bcb9dff-kpnbc 2/2 Running 0 20m openshift-cluster-storage-operator cluster-storage-operator-5f784969f5-vwzgz 1/1 Running 1 (113s ago) 20m openshift-cluster-storage-operator csi-snapshot-controller-6b7687b7d9-7nrfw 1/1 Running 0 3m8s openshift-cluster-storage-operator csi-snapshot-controller-6b7687b7d9-csksg 1/1 Running 0 3m9s openshift-cluster-storage-operator csi-snapshot-controller-operator-7f4d9fc5b8-hkvrk 1/1 Running 0 20m openshift-cluster-storage-operator csi-snapshot-webhook-6759b5dc8b-7qltn 1/1 Running 0 3m12s openshift-cluster-storage-operator csi-snapshot-webhook-6759b5dc8b-f8bqk 1/1 Running 0 3m12s openshift-console-operator console-operator-8675b58c4c-flc5p 1/1 Running 1 (96s ago) 20m openshift-console console-5cbf6c7969-6gk6z 1/1 Running 0 119s openshift-console downloads-7bcd756565-6wj5j 1/1 Running 0 4m3s openshift-dns-operator dns-operator-77d755cd8c-xjfbn 2/2 Running 0 21m openshift-dns dns-default-jwjkz 2/2 Running 0 113s openshift-dns dns-default-kfqnh 2/2 Running 0 113s openshift-dns dns-default-xlqsm 2/2 Running 0 113s openshift-dns node-resolver-jzxnd 1/1 Running 0 110s openshift-dns node-resolver-xqdr5 1/1 Running 0 110s openshift-dns node-resolver-zl6h4 1/1 Running 0 110s openshift-image-registry cluster-image-registry-operator-64fcfdbf5-r7d5t 1/1 Running 0 20m openshift-image-registry image-registry-7fdfd99d68-t9pq9 1/1 Running 0 53s openshift-image-registry node-ca-hkfnr 1/1 Running 0 56s openshift-image-registry node-ca-vlsdl 1/1 Running 0 56s openshift-image-registry node-ca-xqnsw 1/1 Running 0 56s openshift-ingress-canary ingress-canary-86z6r 1/1 Running 0 4m13s openshift-ingress-canary ingress-canary-8jhxk 1/1 Running 0 3m52s openshift-ingress-canary ingress-canary-cv45h 1/1 Running 0 4m24s openshift-ingress router-default-6bb8944f66-z2lxr 1/1 Running 0 20m openshift-kube-storage-version-migrator-operator kube-storage-version-migrator-operator-56b57b4844-p9zgp 1/1 Running 1 (2m16s ago) 20m openshift-kube-storage-version-migrator migrator-58bb4d89d5-5sl9w 1/1 Running 0 3m30s openshift-monitoring alertmanager-main-0 6/6 Running 0 100s openshift-monitoring cluster-monitoring-operator-5bc5885cd4-dwbc4 2/2 Running 0 20m openshift-monitoring grafana-78f798868c-wd84p 3/3 Running 0 94s openshift-monitoring kube-state-metrics-58b8f97f6c-6kp4v 3/3 Running 0 104s openshift-monitoring node-exporter-ll7cp 2/2 Running 0 103s openshift-monitoring node-exporter-tgsqg 2/2 Running 0 103s openshift-monitoring node-exporter-z99gr 2/2 Running 0 103s openshift-monitoring openshift-state-metrics-677b9fb74f-qqp6g 3/3 Running 0 104s openshift-monitoring prometheus-adapter-f69fff5f9-7tdn9 0/1 Running 0 17s openshift-monitoring prometheus-k8s-0 6/6 Running 0 93s openshift-monitoring prometheus-operator-6b9d4fd9bd-tqfcx 2/2 Running 0 2m2s openshift-monitoring telemeter-client-74d599658c-wqw5j 3/3 Running 0 101s openshift-monitoring thanos-querier-64c8757854-z4lll 6/6 Running 0 98s openshift-multus multus-additional-cni-plugins-cqst9 1/1 Running 0 6m14s openshift-multus multus-additional-cni-plugins-dbmkj 1/1 Running 0 5m56s openshift-multus multus-additional-cni-plugins-kcwl9 1/1 Running 0 6m14s openshift-multus multus-admission-controller-22cmb 2/2 Running 0 3m52s openshift-multus multus-admission-controller-256tn 2/2 Running 0 4m13s openshift-multus multus-admission-controller-mz9jm 2/2 Running 0 4m24s openshift-multus multus-bxgvr 1/1 Running 0 6m14s openshift-multus multus-dmkdc 1/1 Running 0 6m14s openshift-multus multus-gqw2f 1/1 Running 0 5m56s openshift-multus network-metrics-daemon-6cx4x 2/2 Running 0 5m56s openshift-multus network-metrics-daemon-gz4jp 2/2 Running 0 6m13s openshift-multus network-metrics-daemon-jq9j4 2/2 Running 0 6m13s openshift-network-diagnostics network-check-source-8497dc8f86-cn4nm 1/1 Running 0 5m59s openshift-network-diagnostics network-check-target-d8db9 1/1 Running 0 5m58s openshift-network-diagnostics network-check-target-jdbv8 1/1 Running 0 5m58s openshift-network-diagnostics network-check-target-zzmdv 1/1 Running 0 5m55s openshift-network-operator network-operator-f5b48cd67-x5dcz 1/1 Running 0 21m openshift-sdn sdn-452r2 2/2 Running 0 5m56s openshift-sdn sdn-68g69 2/2 Running 0 6m openshift-sdn sdn-controller-4v5mv 2/2 Running 0 5m56s openshift-sdn sdn-controller-crscc 2/2 Running 0 6m1s openshift-sdn sdn-controller-fxtn9 2/2 Running 0 6m1s openshift-sdn sdn-n5jm5 2/2 Running 0 6m openshift-service-ca-operator service-ca-operator-5bf7f9d958-vnqcg 1/1 Running 1 (2m ago) 20m openshift-service-ca service-ca-6c54d7944b-v5mrw 1/1 Running 0 3m8s
1.7.4. 在裸机上管理托管的 control plane 集群（技术预览）
您可以使用 Kubernetes operator 的多集群引擎来创建和管理 Red Hat OpenShift Container Platform 托管的集群。托管 control plane 在裸机上作为技术预览提供。
1.7.4.1. 先决条件
您必须先为裸机配置托管的 control plane，然后才能创建托管的 control plane 集群。如需更多信息 ，请参阅在裸机上配置托管集群（技术预览）。
1.7.4.2. 为托管集群扩展 NodePool 对象
您可以通过扩展 NodePool 对象将节点添加到托管集群。
将 NodePool 对象扩展到两个节点：
oc -n ${CLUSTERS_NAMESPACE} scale nodepool ${NODEPOOL_NAME} --replicas 2Cluster API 代理供应商随机选择两个代理，然后分配给托管集群。这些代理通过不同的状态，最后将托管集群作为 OpenShift Container Platform 节点加入。代理按以下顺序传递状态：
-
binding -
发现 -
insufficient -
installing -
installing-in-progress added-to-existing-clusteroc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agent请参见以下示例输出：
NAME CLUSTER APPROVED ROLE STAGE 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 hypercluster1 true auto-assign d9198891-39f4-4930-a679-65fb142b108b true auto-assign da503cf1-a347-44f2-875c-4960ddb04091 hypercluster1 true auto-assign oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agent -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}' BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: binding BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: known-unbound BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: insufficient
-
在代理到达
add-to-existing-cluster状态后，输入以下命令验证您可以看到 OpenShift Container Platform 节点：oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get nodes请参见以下示例输出：
NAME STATUS ROLES AGE VERSION ocp-worker-1 Ready worker 5m41s v1.24.0+3882f8f ocp-worker-2 Ready worker 6m3s v1.24.0+3882f8f
集群 Operator 首先通过将工作负载添加到节点来协调。
输入以下命令验证在扩展
NodePool对象时是否创建了两台机器：oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get machines请参见以下示例输出：
NAME CLUSTER NODENAME PROVIDERID PHASE AGE VERSION hypercluster1-c96b6f675-m5vch hypercluster1-b2qhl ocp-worker-1 agent://da503cf1-a347-44f2-875c-4960ddb04091 Running 15m 4.12z hypercluster1-c96b6f675-tl42p hypercluster1-b2qhl ocp-worker-2 agent://4dac1ab2-7dd5-4894-a220-6a3473b67ee6 Running 15m 4.12z
clusterversion协调过程最终到达缺少 Ingress 和 Console 集群 Operator 的点：oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get clusterversion,co NAME VERSION AVAILABLE PROGRESSING SINCE STATUS clusterversion.config.openshift.io/version False True 40m Unable to apply 4.12z: the cluster operator console has not yet successfully rolled out NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE clusteroperator.config.openshift.io/console 4.12z False False False 11m RouteHealthAvailable: failed to GET route (https://console-openshift-console.apps.hypercluster1.domain.com): Get "https://console-openshift-console.apps.hypercluster1.domain.com": dial tcp 10.19.3.29:443: connect: connection refused clusteroperator.config.openshift.io/csi-snapshot-controller 4.12z True False False 10m clusteroperator.config.openshift.io/dns 4.12z True False False 9m16s clusteroperator.config.openshift.io/image-registry 4.12z True False False 9m5s clusteroperator.config.openshift.io/ingress 4.12z True False True 39m 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) clusteroperator.config.openshift.io/insights 4.12z True False False 11m clusteroperator.config.openshift.io/kube-apiserver 4.12z True False False 40m clusteroperator.config.openshift.io/kube-controller-manager 4.12z True False False 40m clusteroperator.config.openshift.io/kube-scheduler 4.12z True False False 40m clusteroperator.config.openshift.io/kube-storage-version-migrator 4.12z True False False 10m clusteroperator.config.openshift.io/monitoring 4.12z True False False 7m38s clusteroperator.config.openshift.io/network 4.12z True False False 11m clusteroperator.config.openshift.io/openshift-apiserver 4.12z True False False 40m clusteroperator.config.openshift.io/openshift-controller-manager 4.12z True False False 40m clusteroperator.config.openshift.io/openshift-samples 4.12z True False False 8m54s clusteroperator.config.openshift.io/operator-lifecycle-manager 4.12z True False False 40m clusteroperator.config.openshift.io/operator-lifecycle-manager-catalog 4.12z True False False 40m clusteroperator.config.openshift.io/operator-lifecycle-manager-packageserver 4.12z True False False 40m clusteroperator.config.openshift.io/service-ca 4.12z True False False 11m clusteroperator.config.openshift.io/storage 4.12z True False False 11m
1.7.4.3. 处理裸机上托管的集群中的入口
每个 OpenShift Container Platform 集群都会设置有一个默认的应用程序入口控制器，该控制器预期关联有外部 DNS 记录。例如，如果您创建一个名为 example 的 HyperShift 集群，其基域为 krnl.es，您可以预期通配符域 *.apps.example.krnl.es 可以被路由。
您可以为 If apps 设置负载均衡器和通配符 DNS 记录。此过程需要部署 MetalLB，配置路由到入口部署的新负载均衡器服务，并将通配符 DNS 条目分配给负载均衡器 IP 地址。
设置 MetalLB，以便在创建
LoadBalancer类型的服务时，MetalLB 为该服务添加外部 IP 地址。创建包含 MetalLB Operator 配置的 YAML 文件：
apiVersion: v1 kind: Namespace metadata: name: metallb labels: openshift.io/cluster-monitoring: "true" annotations: workload.openshift.io/allowed: management --- apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: metallb-operator-operatorgroup namespace: metallb --- apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: metallb-operator namespace: metallb spec: channel: "stable" name: metallb-operator source: redhat-operators sourceNamespace: openshift-marketplace-
将文件保存为
metallb-operator-config.yaml。 - 输入以下命令应用配置：
oc apply -f metallb-operator-config.yaml
Operator 运行后，创建 MetalLB 实例：
创建包含 MetalLB 实例配置的 YAML 文件：
apiVersion: metallb.io/v1beta1 kind: MetalLB metadata: name: metallb namespace: metallb
-
将文件保存为
metallb-instance-config.yaml。 - 输入以下命令来创建 MetalLB 实例：
oc apply -f metallb-instance-config.yaml
通过创建两个资源来配置 MetalLB Operator：
-
具有单个 IP 地址的
IPAddressPool资源。此 IP 地址必须与集群节点使用的网络位于同一个子网中。 一个
BGPAdvertisement资源，用于公告IPAddressPool资源通过 BGP 协议提供的负载均衡器 IP 地址。重要： 更改
INGRESS_IP环境变量以匹配您的环境地址。创建 YAML 文件使其包含配置：
export INGRESS_IP=192.168.122.23 apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: name: ingress-public-ip namespace: metallb spec: protocol: layer2 autoAssign: false addresses: - ${INGRESS_IP}-${INGRESS_IP} --- apiVersion: metallb.io/v1beta1 kind: BGPAdvertisement metadata: name: ingress-public-ip namespace: metallb spec: ipAddressPools: - ingress-public-ip-
将文件保存为
ipaddresspool-bgpadvertisement-config.yaml。 - 运行以下命令来创建资源：
oc apply -f ipaddresspool-bgpadvertisement-config.yaml
-
具有单个 IP 地址的
按照以下步骤，通过 MetalLB 公开 OpenShift Container Platform Router：
创建 YAML 文件来设置将入口流量路由到 ingress 部署的 LoadBalancer 服务：
kind: Service apiVersion: v1 metadata: annotations: metallb.universe.tf/address-pool: ingress-public-ip name: metallb-ingress namespace: openshift-ingress spec: ports: - name: http protocol: TCP port: 80 targetPort: 80 - name: https protocol: TCP port: 443 targetPort: 443 selector: ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default type: LoadBalancer-
将文件保存为
metallb-loadbalancer-service.yaml。 输入以下命令应用 YAML 文件中的配置：
oc apply -f metallb-loadbalancer-service.yaml
输入以下命令访问 OpenShift Container Platform 控制台：
curl -kI https://console-openshift-console.apps.example.krnl.es HTTP/1.1 200 OK
检查
clusterversion和clusteroperator值，以验证一切是否正在运行。输入以下命令：oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get clusterversion,co请参见以下示例输出：
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS clusterversion.config.openshift.io/version 4.12z True False 3m32s Cluster version is 4.12z NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE clusteroperator.config.openshift.io/console 4.12z True False False 3m50s clusteroperator.config.openshift.io/csi-snapshot-controller 4.12z True False False 25m clusteroperator.config.openshift.io/dns 4.12z True False False 23m clusteroperator.config.openshift.io/image-registry 4.12z True False False 23m clusteroperator.config.openshift.io/ingress 4.12z True False False 53m clusteroperator.config.openshift.io/insights 4.12z True False False 25m clusteroperator.config.openshift.io/kube-apiserver 4.12z True False False 54m clusteroperator.config.openshift.io/kube-controller-manager 4.12z True False False 54m clusteroperator.config.openshift.io/kube-scheduler 4.12z True False False 54m clusteroperator.config.openshift.io/kube-storage-version-migrator 4.12z True False False 25m clusteroperator.config.openshift.io/monitoring 4.12z True False False 21m clusteroperator.config.openshift.io/network 4.12z True False False 25m clusteroperator.config.openshift.io/openshift-apiserver 4.12z True False False 54m clusteroperator.config.openshift.io/openshift-controller-manager 4.12z True False False 54m clusteroperator.config.openshift.io/openshift-samples 4.12z True False False 23m clusteroperator.config.openshift.io/operator-lifecycle-manager 4.12z True False False 54m clusteroperator.config.openshift.io/operator-lifecycle-manager-catalog 4.12z True False False 54m clusteroperator.config.openshift.io/operator-lifecycle-manager-packageserver 4.12z True False False 54m clusteroperator.config.openshift.io/service-ca 4.12z True False False 25m clusteroperator.config.openshift.io/storage 4.12z True False False 25m
如需有关 MetalLB 的更多信息，请参阅 OpenShift Container Platform 文档中的 关于 MetalLB 和 MetalLB Operator。
1.7.4.4. 为托管集群启用节点自动扩展
当托管集群和备用代理中需要更多容量时，您可以启用自动扩展来安装新代理。
要启用自动扩展，请输入以下命令。在这种情况下，最少的节点数量为 2，最大数量为 5。您可以添加的最大节点数由可用代理数量绑定。
oc -n ${CLUSTERS_NAMESPACE} patch nodepool ${HOSTED_CLUSTER_NAME} --type=json -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'如果 10 分钟通过不需要额外容量，则代理将停用，并再次放在备用队列中。
创建需要新节点的工作负载。
创建一个包含工作负载配置的 YAML 文件，如下例所示：
apiVersion: apps/v1 kind: Deployment metadata: creationTimestamp: null labels: app: reversewords name: reversewords namespace: default spec: replicas: 40 selector: matchLabels: app: reversewords strategy: {} template: metadata: creationTimestamp: null labels: app: reversewords spec: containers: - image: quay.io/mavazque/reversewords:latest name: reversewords resources: requests: memory: 2Gi status: {}-
将文件保存为
workload-config.yaml。 - 输入以下命令应用 YAML：
oc apply -f workload-config.yaml
输入以下命令验证剩余的代理是否已部署。在本例中，置备备用代理
d9198891-39f4-4930-a679-65fb142b108b：oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agent -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'请参见以下示例输出：
BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: added-to-existing-cluster BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: installing-in-progress BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: added-to-existing-cluster
如果输入以下命令来检查节点，则输出中会显示新节点。在本例中，
ocp-worker-0添加到集群中：oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get nodes请参见以下示例输出：
NAME STATUS ROLES AGE VERSION ocp-worker-0 Ready worker 35s v1.24.0+3882f8f ocp-worker-1 Ready worker 40m v1.24.0+3882f8f ocp-worker-2 Ready worker 41m v1.24.0+3882f8f
要删除节点，请输入以下命令删除工作负载：
oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig -n default delete deployment reversewords等待 10 分钟，然后输入以下命令确认节点已被删除：
oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get nodes请参见以下示例输出：
NAME STATUS ROLES AGE VERSION ocp-worker-1 Ready worker 51m v1.24.0+3882f8f ocp-worker-2 Ready worker 52m v1.24.0+3882f8f
oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agent -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}' BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: added-to-existing-cluster BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: known-unbound BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: added-to-existing-cluster
1.7.4.5. 在裸机上销毁托管集群
您可以使用控制台销毁裸机托管集群。完成以下步骤以在裸机上销毁托管集群：
- 在控制台中，进入到 Infrastructure > Clusters。
- 在 Clusters 页面中，选择要销毁的集群。
- 在 Actions 菜单中，选择 Destroy 集群 来删除集群。
1.7.4.6. 其他资源
- 现在，您可以部署 SR-IOV Operator。请参阅为托管 control plane 部署 SR-IOV Operator，以了解更多有关部署 SR-IOV Operator 的信息。
1.7.5. 在 OpenShift Virtualization 中管理托管的 control plane 集群（技术预览）
使用托管的 control plane 和 Red Hat OpenShift Virtualization，您可以创建带有由 KubeVirt 虚拟机托管的 worker 节点的 OpenShift Container Platform 集群。在 OpenShift Virtualization 上托管的 control plane 提供了几个优点：
- 通过在相同的底层裸机基础架构中打包托管的 control plane 和托管集群来提高资源使用量
- 分隔托管的 control plane 和客户机集群，以提供强大的隔离
- 通过消除裸机节点 bootstrap 过程来减少集群置备时间
- 管理同一基本 OpenShift Container Platform 集群下的多个发行版本
要了解如何在 OpenShift Virtualization 上创建托管的 control plane 集群，请查看以下部分：
1.7.5.1. 先决条件
您必须满足以下先决条件才能在 OpenShift Virtualization 上创建 OpenShift Container Platform 集群：
-
您需要管理员访问
KUBECONFIG环境变量指定的 OpenShift Container Platform 集群，版本 4.12 或更高版本。 OpenShift Container Platform 受管集群必须启用通配符 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。如需更多信息，请参阅使用 Web 控制台安装 OpenShift Virtualization。
- 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 功能。如需更多信息，请参阅启用托管的 control plane 功能。
-
启用托管的 control plane 功能后，您需要安装托管的 control plane (
hypershift)命令行界面二进制。 - 在置备集群前，您需要配置负载均衡器。如需更多信息 ，请参阅配置负载均衡器。
1.7.5.2. 使用 KubeVirt 平台创建托管集群
要创建客户机集群，请使用环境变量和
hypershift命令行界面：export CLUSTER_NAME=example export PULL_SECRET="$HOME/pull-secret" export MEM="6Gi" export CPU="2" export WORKER_COUNT="2" hypershift create cluster kubevirt \ --name $CLUSTER_NAME \ --node-pool-replicas $WORKER_COUNT \ --pull-secret $PULL_SECRET \ --memory $MEM \ --cores $CPU
根据需要替换值。
注： 您可以使用
--release-image标志使用特定的 OpenShift Container Platform 发行版本设置托管集群。根据
--node-pool-replicas标志，为集群创建一个默认节点池，它有两个虚拟机 worker 副本。片刻后，您可以输入以下命令验证托管的 control plane pod 是否正在运行：
oc -n clusters-$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.12.7 example-admin-kubeconfig Completed True False The hosted control plane is available
1.7.5.3. 访问托管集群
要获取对客户机集群的命令行界面访问权限，请检索客户机集群 kubeconfig 环境变量。
要使用
hypershift命令行界面检索客户机集群 kubeconfig 环境变量，请输入以下命令：hypershift create kubeconfig --name $CLUSTER_NAME > $CLUSTER_NAME-kubeconfig
输入以下命令访问集群：
oc --kubeconfig $CLUSTER_NAME-kubeconfig get nodes
输出示例
NAME STATUS ROLES AGE VERSION example-n6prw Ready worker 32m v1.25.4+18eadca example-nc6g4 Ready worker 32m v1.25.4+18eadca
输入以下命令检查集群版本：
oc --kubeconfig $CLUSTER_NAME-kubeconfig get clusterversion
输出示例
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.12.7 True False 5m39s Cluster version is 4.12.7
1.7.5.4. 默认入口和 DNS 行为
每个 OpenShift Container Platform 集群都包括一个默认的应用程序 Ingress 控制器，它必须关联有通配符 DNS 记录。默认情况下，使用 HyperShift KubeVirt 供应商创建的客户机集群会自动成为 KubeVirt 虚拟机所运行底层 OpenShift Container Platform 集群的子域。
例如，OpenShift Container Platform 集群可能有以下默认 Ingress DNS 条目：
*.apps.mgmt-cluster.example.com
因此，名为 guest 的 KubeVirt 客户机集群，并在该底层 OpenShift Container Platform 集群上运行有以下默认入口：
*.apps.guest.apps.mgmt-cluster.example.com
注： 要使默认 Ingress DNS 正常工作，托管 KubeVirt 虚拟机的底层集群必须允许通配符 DNS 路由。您可以输入以下命令来配置此行为： oc patch ingresscontroller -n openshift-ingress-operator default --type=json -p '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'
1.7.5.5. 自定义 Ingress 和 DNS 行为
如果您不想使用默认的 Ingress 和 DNS 行为，您可以在创建时配置带有唯一基域的 KubeVirt 客户机集群。这个选项需要创建过程中手动配置步骤，并涉及三个主要步骤：集群创建、负载均衡器创建和通配符 DNS 配置。
1.7.5.5.1. 部署指定基域的托管集群
要创建指定基域的托管集群，请输入以下命令：
export CLUSTER_NAME=example 1 export PULL_SECRET="$HOME/pull-secret" export MEM="6Gi" export CPU="2" export WORKER_COUNT="2" export BASE_DOMAIN=hypershift.lab 2 hypershift create cluster kubevirt \ --name $CLUSTER_NAME \ --node-pool-replicas $WORKER_COUNT \ --pull-secret $PULL_SECRET \ --memory $MEM \ --cores $CPU \ --base-domain $BASE_DOMAIN
结果是一个托管集群，它有一个 Ingress 通配符，它为集群名称和基域配置，或者如本例所示，即
.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
输入以下命令访问集群：
hypershift create kubeconfig --name $CLUSTER_NAME > $CLUSTER_NAME-kubeconfig
oc --kubeconfig $CLUSTER_NAME-kubeconfig get co
输出示例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE console 4.12.7 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.12.7 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)
后续步骤修复了输出中的错误。
注： 如果集群位于裸机上，您可能需要 MetalLB，以便您可以设置负载均衡器服务。如需更多信息，请参阅 可选：配置 MetalLB。
1.7.5.5.2. 设置负载均衡器
设置路由到 KubeVirt 虚拟机的负载均衡器，并为负载均衡器 IP 地址分配通配符 DNS 条目。您需要创建一个负载均衡器服务，将入口流量路由到 KubeVirt 虚拟机。公开托管集群 Ingress 的 NodePort 服务已存在，以便您可以导出节点端口并创建以这些端口为目标的负载均衡器服务。
输入以下命令导出节点端口：
export HTTP_NODEPORT=$(oc --kubeconfig $CLUSTER_NAME-kubeconfig get services -n openshift-ingress router-nodeport-default -o jsonpath='{.spec.ports[?(@.name=="http")].nodePort}') export HTTPS_NODEPORT=$(oc --kubeconfig $CLUSTER_NAME-kubeconfig get services -n openshift-ingress router-nodeport-default -o jsonpath='{.spec.ports[?(@.name=="https")].nodePort}')运行以下命令来创建负载均衡器服务：
oc apply -f - apiVersion: v1 kind: Service metadata: labels: app: $CLUSTER_NAME name: $CLUSTER_NAME-apps namespace: clusters-$CLUSTER_NAME spec: ports: - name: https-443 port: 443 protocol: TCP targetPort: ${HTTPS_NODEPORT} - name: http-80 port: 80 protocol: TCP targetPort: ${HTTP_NODEPORT} selector: kubevirt.io: virt-launcher type: LoadBalancer
1.7.5.5.3. 设置通配符 DNS
设置引用负载均衡器服务外部 IP 的通配符 DNS 记录或 CNAME。
输入以下命令导出外部 IP：
export EXTERNAL_IP=$(oc -n clusters-$CLUSTER_NAME get service $CLUSTER_NAME-apps -o jsonpath='{.status.loadBalancer.ingress[0].ip}')配置通配符 DNS 条目来引用存储在
$EXTERNAL_IP路径中的 IP。查看以下 DNS 条目示例：*.apps.<hosted-cluster-name\>.<base-domain\>.
DNS 条目必须能够在集群内部和外部路由。如果您使用第 1 步中的示例输入，对于具有外部 IP 值为
192.168.20.30的集群，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.12.7 example-admin-kubeconfig Completed True False The hosted control plane is available
1.7.5.6. 可选：配置 MetalLB
您必须使用负载均衡器，如 MetalLB。以下示例显示了在安装 MetalLB 后配置 MetalLB 的步骤。有关安装 MetalLB 的更多信息，请参阅 OpenShift Container Platform 文档中的安装 MetalLB Operator。
创建 MetalLB 实例：
oc create -f - apiVersion: metallb.io/v1beta1 kind: MetalLB metadata: name: metallb namespace: metallb-system
创建在节点网络中可用 IP 地址范围的地址池。将以下 IP 地址范围替换为网络中的可用 IP 地址池。
oc create -f - apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: name: metallb namespace: metallb-system spec: addresses: - 192.168.216.32-192.168.216.122
使用 L2 协议公告地址池：
oc create -f - apiVersion: metallb.io/v1beta1 kind: L2Advertisement metadata: name: l2advertisement namespace: metallb-system spec: ipAddressPools: - metallb
1.7.5.6.1. 其他资源
- 如需有关 MetalLB 的更多信息，请参阅安装 MetalLB Operator。
1.7.5.7. 扩展节点池
您可以使用
oc scale命令手动扩展 NodePool：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.25.4+18eadca example-n6prw Ready worker 116m v1.25.4+18eadca example-nc6g4 Ready worker 117m v1.25.4+18eadca example-thp29 Ready worker 4m17s v1.25.4+18eadca example-twxns Ready worker 88s v1.25.4+18eadca
1.7.5.8. 添加节点池
您可以通过指定名称、副本数和任何其他信息（如内存和 CPU 要求）来为客户机集群创建节点池。
要创建节点池，请输入以下信息：在本例中，节点池分配有更多 CPU:
export NODEPOOL_NAME=${CLUSTER_NAME}-extra-cpu export WORKER_COUNT="2" export MEM="6Gi" export CPU="4" export DISK="16" hypershift 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.12.7 example-extra-cpu example 2 False False True True Minimum availability requires 2 replicas, current 0 available
一段时间后，您可以输入以下命令检查节点池的状态：
oc --kubeconfig $CLUSTER_NAME-kubeconfig get nodes
输出示例
NAME STATUS ROLES AGE VERSION example-9jvnf Ready worker 97s v1.25.4+18eadca example-n6prw Ready worker 116m v1.25.4+18eadca example-nc6g4 Ready worker 117m v1.25.4+18eadca example-thp29 Ready worker 4m17s v1.25.4+18eadca example-twxns Ready worker 88s v1.25.4+18eadca example-extra-cpu-zh9l5 Ready worker 2m6s v1.25.4+18eadca example-extra-cpu-zr8mj Ready worker 102s v1.25.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.12.7 example-extra-cpu example 2 2 False False 4.12.7 Delete a HostedCluster
1.7.5.9. 在 OpenShift Virtualization 上验证托管集群创建
要验证托管集群是否已成功创建，请执行以下步骤。
输入以下命令验证
HostedCluster资源是否过渡到completed状态：oc get --namespace clusters hostedclusters ${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 是否在线：
hypershift create kubeconfig --name $CLUSTER_NAME > $CLUSTER_NAME-kubeconfig
oc get co --kubeconfig=$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
1.7.5.10. 在 OpenShift Virtualization 上销毁托管集群
要删除 OpenShift Virtualization 上的托管集群，请在命令行中输入以下命令：
hypershift destroy cluster kubevirt --name $CLUSTER_NAME
根据需要替换名称。
1.7.6. 分发托管集群工作负载（技术预览）
作为集群管理员，您可以在管理集群节点中使用以下标签和污点来调度 control plane 工作负载：
-
HyperShift.openshift.io/control-plane: true -
HyperShift.openshift.io/cluster: ${HostedControlPlane Namespace}
托管集群的 Pod 具有容限，调度程序使用关联性规则来调度它们。Pod 容限污点用于 control-plane 和 cluster 用于 pod。调度程序将 pod 调度到标记为 hypershift.openshift.io/control-plane 和 hypershift.openshift.io/cluster: ${HostedControlPlane Namespace} 的节点。
对于 ControllerAvailabilityPolicy 选项，请使用 HighlyAvailable。当使用该选项时，您可以通过将 topology.kubernetes.io/zone 设置为拓扑键，在不同的故障域中为每个部署调度 pod。
要启用托管集群需要将其 pod 调度到 infra 节点，请设置 HostedCluster.spec.nodeSelector，如下例所示：
spec:
nodeSelector:
role.kubernetes.io/infra: ""这样，每个租户托管的 control plane 有资格具有基础架构节点工作负载，您不需要授权底层的 OpenShift Container Platform 节点。
1.7.6.1. 优先级类
四个内置优先级类会影响托管集群 pod 的优先级和抢占。您可以按照从高到低的顺序在管理集群中创建 pod：
-
HyperShift-operator: HyperShift Operator pod。 -
HyperShift-etcd: etcd 的 Pod。 -
HyperShift-api-critical： API 调用和资源准入所需的 Pod 才能成功。这些 pod 包括kube-apiserver、聚合 API 服务器和 web hook 等 pod。 -
HyperShift-control-plane: control plane 中的 Pod 不是 API-critical，但仍需要提升优先级，如集群版本 Operator。
1.7.7. 禁用托管的 control plane 功能
您可以卸载 HyperShift Operator 并禁用托管的 control plane。禁用托管的 control plane 集群功能时，您必须销毁托管集群以及 multicluster engine operator 上的受管集群资源，如 管理托管的 control plane 集群 主题 中所述。
1.7.7.1. 卸载 HyperShift Operator
要卸载 HyperShift Operator 并从 local-cluster 禁用 hypershift-addon，请完成以下步骤：
运行以下命令，以确保没有托管集群正在运行：
oc get hostedcluster -A
重要： 如果托管集群正在运行，则 HyperShift Operator 不会卸载，即使
hypershift-addon被禁用。运行以下命令来禁用
hypershift-addon：oc patch mce multiclusterengine --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift-local-hosting","enabled": false}]}}}' 1- 1
- 默认
MultiClusterEngine资源实例名称为multiclusterengine，但您可以通过运行以下命令来从集群中获取MultiClusterEngine名称：$ oc get mce。
提示： 在禁用
hypershift-addon后，您还可以从 multicluster engine operator 控制台为local-cluster禁用hypershift-addon。
1.7.7.2. 禁用托管的 control plane 功能
在禁用托管的 control plane 功能前，您必须首先卸载 HyperShift Operator。运行以下命令来禁用托管的 control plane 功能：
oc patch mce multiclusterengine --type=merge -p '{"spec":{"overrides":{"components":[{"name":"hypershift-preview","enabled": false}]}}}' 1- 1
- 默认
MultiClusterEngine资源实例名称为multiclusterengine，但您可以通过运行以下命令来从集群中获取MultiClusterEngine名称：$ oc get mce。
您可以运行以下命令来验证 MultiClusterEngine 自定义资源中禁用了 hypershift-preview 和 hypershift-local-hosting 功能：
oc get mce multiclusterengine -o yaml 1- 1
- 默认
MultiClusterEngine资源实例名称为multiclusterengine，但您可以通过运行以下命令来从集群中获取MultiClusterEngine名称：$ oc get mce。
请参阅以下示例，其中 hypershift-preview 和 hypershift-local-hosting 的 enabled: 标记设为 false ：
apiVersion: multicluster.openshift.io/v1
kind: MultiClusterEngine
metadata:
name: multiclusterengine
spec:
overrides:
components:
- name: hypershift-preview
enabled: false
- name: hypershift-local-hosting
enabled: false