Hosted Control Plane

手順

1. 次の例のようなファイルを作成して、hypershift-addon という名前の ManagedClusterAddon アドオンを作成します。

   apiVersion: addon.open-cluster-management.io/v1alpha1
   kind: ManagedClusterAddOn
   metadata:
     name: hypershift-addon
     namespace: local-cluster
   spec:
     installNamespace: open-cluster-management-agent-addon

2. 以下のコマンドを実行してこのファイルを適用します。

   $ oc apply -f <filename>

   filename は、作成したファイル名に置き換えます。

3. 次のコマンドを実行して、hypershift-addon マネージドクラスターアドオンがインストールされていることを確認します。

   $ oc get managedclusteraddons -n local-cluster hypershift-addon

   アドオンがインストールされている場合、出力は以下の例のようになります。

   NAME               AVAILABLE   DEGRADED   PROGRESSING
   hypershift-addon   True

手順

1. 以下のコマンドを実行して、ホステッドクラスターが実行されていないことを確認します。

   $ oc get hostedcluster -A

   重要

   ホステッドクラスターが実行中の場合、hypershift-addon が無効になっていても、HyperShift Operator はアンインストールされません。

2. 以下のコマンドを実行して hypershift-addon を無効にします。

   $ oc patch mce multiclusterengine --type=merge -p \

   1

   
     '{"spec":{"overrides":{"components":[{"name":"hypershift-local-hosting","enabled": false}]}}}'

   1

   デフォルトの MultiClusterEngine リソースインスタンス名は multiclusterengine ですが、$ oc get mce コマンドを実行し、クラスターから MultiClusterEngine 名を取得できます。

   注記

   hypershift-addon を無効にした後、multicluster engine Operator コンソールから local-cluster の hypershift-addon を無効にすることもできます。

手順

1. 次のコマンドを実行して、Hosted Control Plane 機能を無効にします。

   $ oc patch mce multiclusterengine --type=merge -p \

   1

   
     '{"spec":{"overrides":{"components":[{"name":"hypershift","enabled": false}]}}}'

   1

   デフォルトの MultiClusterEngine リソースインスタンス名は multiclusterengine ですが、$ oc get mce コマンドを実行し、クラスターから MultiClusterEngine 名を取得できます。

2. 次のコマンドを実行すると、MultiClusterEngine カスタムリソースで hypershift および hypershift-local-hosting 機能が無効になっていることを確認できます。

   $ oc get mce multiclusterengine -o yaml 

   1

   1

   デフォルトの MultiClusterEngine リソースインスタンス名は multiclusterengine ですが、$ oc get mce コマンドを実行し、クラスターから MultiClusterEngine 名を取得できます。

   hypershift と hypershift-local-hosting の enabled: フラグが false に設定されている次の例を参照してください。

   apiVersion: multicluster.openshift.io/v1
   kind: MultiClusterEngine
   metadata:
     name: multiclusterengine
   spec:
     overrides:
       components:
       - name: hypershift
         enabled: false
       - name: hypershift-local-hosting
         enabled: false

手順

1. クラスターの OIDC 検出ドキュメントをホストするためのパブリックアクセスを持つ S3 バケットを作成します。

   1. 以下のコマンドを入力します。

      $ aws s3api create-bucket --bucket <bucket_name> \
        --create-bucket-configuration LocationConstraint=<region> \
        --region <region> 

      1

      各項目の説明:

      <bucket_name>

      作成する S3 バケットの名前を指定します。

      < 領域 >

      バケットを us-east-1 リージョン以外のリージョンに作成することを指定します。この行を追加し、<region> を使用したいリージョンに置き換えてください。us-east-1 リージョンにバケットを作成するには、この行を省略します。

   2. 以下のコマンドを入力します。

      $ aws s3api delete-public-access-block --bucket <bucket_name>

      <bucket_name> は、作成する S3 バケットの名前に置き換えます。

   3. 以下のコマンドを入力します。

      $ echo '{
          "Version": "2012-10-17",
          "Statement": [
              {
                  "Effect": "Allow",
                  "Principal": "*",
                  "Action": "s3:GetObject",
                  "Resource": "arn:aws:s3:::<bucket_name>/*"
              }
          ]
      }' | envsubst > policy.json

      <bucket_name> は、作成する S3 バケットの名前に置き換えます。

   4. 以下のコマンドを入力します。

      $ aws s3api put-bucket-policy --bucket <bucket_name> \
        --policy file://policy.json

      <bucket_name> は、作成する S3 バケットの名前に置き換えます。

      注記

      Mac コンピューターを使用している場合は、ポリシーを機能させるためにバケット名をエクスポートする必要があります。

2. HyperShift Operator 用に hypershift-operator-oidc-provider-s3-credentials という名前の OIDC S3 シークレットを作成します。
3. シークレットを local-cluster namespace に保存します。

4. 次の表を参照して、シークレットに次のフィールドが含まれていることを確認します。

   Expand

   表4.1 AWS シークレットの必須フィールド

   フィールド名	説明
   bucket	ホステッドクラスターの OIDC 検出ドキュメントをホストするためのパブリックアクセスを備えた S3 バケットが含まれています。
   credentials	バケットにアクセスできる default プロファイルの認証情報を含むファイルへの参照。デフォルトでは、HyperShift は default プロファイルのみを使用して bucket を操作します。
   region	S3 バケットのリージョンを指定します。

   Show more

5. AWS シークレットを作成するには、次のコマンドを実行します。

   $ oc create secret generic <secret_name> \
     --from-file=credentials=<path>/.aws/credentials \
     --from-literal=bucket=<s3_bucket> \
     --from-literal=region=<region> \
     -n local-cluster

   注記

   シークレットの障害復旧バックアップは自動的に有効になりません。障害復旧用に hypershift-operator-oidc-provider-s3-credentials シークレットのバックアップを有効にするラベルを追加するには、次のコマンドを実行します。

   $ oc label secret hypershift-operator-oidc-provider-s3-credentials \
     -n local-cluster cluster.open-cluster-management.io/backup=true

手順

1. 次のコマンドを実行して、ユーザーの Amazon Resource Name (ARN) を取得します。

   $ aws sts get-caller-identity --query "Arn" --output text

   出力例

   arn:aws:iam::1234567890:user/<aws_username>

   次のステップで、この出力を <arn> の値として使用してください。

2. ロールの信頼関係設定を含む JSON ファイルを作成します。以下の例を参照してください。

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Principal": {
                   "AWS": "<arn>"
               },
               "Action": "sts:AssumeRole"
           }
       ]
   }

   <arn> は、前のステップでメモしたユーザーの ARN に置き換えます。

3. 次のコマンドを実行して、Identity and Access Management (IAM) ロールを作成します。

   $ aws iam create-role \
     --role-name <name> \
     --assume-role-policy-document file://<file_name>.json \
     --query "Role.Arn"

   各項目の説明:

   <name>

   ロール名を指定します。たとえば、hcp-cli-role など です。

   <file_name>

   前の手順で作成した JSON ファイルの名前を指定します。

   出力例

   arn:aws:iam::820196288204:role/myrole

4. ロールの次の権限ポリシーを含む policy.json という名前の JSON ファイルを作成します。

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Sid": "EC2",
               "Effect": "Allow",
               "Action": [
                   "ec2:CreateDhcpOptions",
                   "ec2:DeleteSubnet",
                   "ec2:ReplaceRouteTableAssociation",
                   "ec2:DescribeAddresses",
                   "ec2:DescribeInstances",
                   "ec2:DeleteVpcEndpoints",
                   "ec2:CreateNatGateway",
                   "ec2:CreateVpc",
                   "ec2:DescribeDhcpOptions",
                   "ec2:AttachInternetGateway",
                   "ec2:DeleteVpcEndpointServiceConfigurations",
                   "ec2:DeleteRouteTable",
                   "ec2:AssociateRouteTable",
                   "ec2:DescribeInternetGateways",
                   "ec2:DescribeAvailabilityZones",
                   "ec2:CreateRoute",
                   "ec2:CreateInternetGateway",
                   "ec2:RevokeSecurityGroupEgress",
                   "ec2:ModifyVpcAttribute",
                   "ec2:DeleteInternetGateway",
                   "ec2:DescribeVpcEndpointConnections",
                   "ec2:RejectVpcEndpointConnections",
                   "ec2:DescribeRouteTables",
                   "ec2:ReleaseAddress",
                   "ec2:AssociateDhcpOptions",
                   "ec2:TerminateInstances",
                   "ec2:CreateTags",
                   "ec2:DeleteRoute",
                   "ec2:CreateRouteTable",
                   "ec2:DetachInternetGateway",
                   "ec2:DescribeVpcEndpointServiceConfigurations",
                   "ec2:DescribeNatGateways",
                   "ec2:DisassociateRouteTable",
                   "ec2:AllocateAddress",
                   "ec2:DescribeSecurityGroups",
                   "ec2:RevokeSecurityGroupIngress",
                   "ec2:CreateVpcEndpoint",
                   "ec2:DescribeVpcs",
                   "ec2:DeleteSecurityGroup",
                   "ec2:DeleteDhcpOptions",
                   "ec2:DeleteNatGateway",
                   "ec2:DescribeVpcEndpoints",
                   "ec2:DeleteVpc",
                   "ec2:CreateSubnet",
                   "ec2:DescribeSubnets"
               ],
               "Resource": "*"
           },
           {
               "Sid": "ELB",
               "Effect": "Allow",
               "Action": [
                   "elasticloadbalancing:DeleteLoadBalancer",
                   "elasticloadbalancing:DescribeLoadBalancers",
                   "elasticloadbalancing:DescribeTargetGroups",
                   "elasticloadbalancing:DeleteTargetGroup"
               ],
               "Resource": "*"
           },
           {
               "Sid": "IAMPassRole",
               "Effect": "Allow",
               "Action": "iam:PassRole",
               "Resource": "arn:*:iam::*:role/*-worker-role",
               "Condition": {
                   "ForAnyValue:StringEqualsIfExists": {
                       "iam:PassedToService": "ec2.amazonaws.com"
                   }
               }
           },
           {
               "Sid": "IAM",
               "Effect": "Allow",
               "Action": [
                   "iam:CreateInstanceProfile",
                   "iam:DeleteInstanceProfile",
                   "iam:GetRole",
                   "iam:UpdateAssumeRolePolicy",
                   "iam:GetInstanceProfile",
                   "iam:TagRole",
                   "iam:RemoveRoleFromInstanceProfile",
                   "iam:CreateRole",
                   "iam:DeleteRole",
                   "iam:PutRolePolicy",
                   "iam:AddRoleToInstanceProfile",
                   "iam:CreateOpenIDConnectProvider",
                   "iam:ListOpenIDConnectProviders",
                   "iam:DeleteRolePolicy",
                   "iam:UpdateRole",
                   "iam:DeleteOpenIDConnectProvider",
                   "iam:GetRolePolicy"
               ],
               "Resource": "*"
           },
           {
               "Sid": "Route53",
               "Effect": "Allow",
               "Action": [
                   "route53:ListHostedZonesByVPC",
                   "route53:CreateHostedZone",
                   "route53:ListHostedZones",
                   "route53:ChangeResourceRecordSets",
                   "route53:ListResourceRecordSets",
                   "route53:DeleteHostedZone",
                   "route53:AssociateVPCWithHostedZone",
                   "route53:ListHostedZonesByName"
               ],
               "Resource": "*"
           },
           {
               "Sid": "S3",
               "Effect": "Allow",
               "Action": [
                   "s3:ListAllMyBuckets",
                   "s3:ListBucket",
                   "s3:DeleteObject",
                   "s3:DeleteBucket"
               ],
               "Resource": "*"
           }
       ]
   }

5. 以下のコマンドを実行して、ロールのアクセス許可ポリシーを含む policy.json ファイルを添付してください。

   $ aws iam put-role-policy \
     --role-name <role_name> \
     --policy-name <policy_name> \
     --policy-document file://policy.json

   各項目の説明:

   < ロール名 >

   ロールの名前を指定します。

   <policy_name>

   保険契約名を指定します。

6. 次のコマンドを実行して、sts-creds.json という名前の JSON ファイル内の STS 認証情報を取得します。

   $ aws sts get-session-token --output json > sts-creds.json

   sts-creds.json ファイルの例

   {
       "Credentials": {
           "AccessKeyId": "<access_key_id",
           "SecretAccessKey": "<secret_access_key>”,
           "SessionToken": "<session_token>",
           "Expiration": "<time_stamp>"
       }
   }

手順

1. HyperShift Operator の AWS 認証情報シークレットを作成し、hypershift-operator-private-link-credentials という名前を付けます。このシークレットは、管理クラスターとして使用されているマネージドクラスターの namespace であるマネージドクラスター namespace に配置する必要があります。local-cluster を使用した場合は、local-cluster namespace にシークレットを作成します。

2. シークレットに必要なフィールドが含まれることを確認するには、以下の表を参照してください。

   Expand

   表4.2 AWS シークレットの必須フィールド

   フィールド名	説明	任意または必須
   region	Private Link で使用するリージョン	必須
   aws-access-key-id	認証情報アクセスキー ID。	必須
   aws-secret-access-key	認証情報アクセスキーのシークレット。	必須

   Show more

3. AWS シークレットを作成するには、次のコマンドを実行します。

   $ oc create secret generic <secret_name> \
     --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

4. シークレットの障害復旧バックアップは自動的に有効になりません。以下のコマンドを実行して、障害復旧用に hypershift-operator-private-link-credentials シークレットのバックアップを有効にするラベルを追加します。

   $ oc label secret hypershift-operator-private-link-credentials \
     -n local-cluster \
     cluster.open-cluster-management.io/backup=""

手順

1. HyperShift Operator 用の Amazon Web Services (AWS) 認証情報シークレットを作成し、local-cluster namespace で hypershift-operator-external-dns-credentials という名前を付けます。

2. シークレットに必要なフィールドが含まれていることを確認してください。ご参考までに、必須項目を以下の表に詳しく記載します。

   Expand

   表4.3 AWS シークレットの必須フィールド

   フィールド名	説明	任意または必須
   provider	サービスレベル DNS ゾーンを管理する DNS プロバイダー。	必須
   domain-filter	サービスレベルドメイン。	必須
   credentials	すべての外部 DNS タイプをサポートする認証情報ファイル。	AWS キーを使用する場合はオプション
   aws-access-key-id	認証情報アクセスキー ID。	AWS DNS サービスを使用する場合はオプション
   aws-secret-access-key	認証情報アクセスキーのシークレット。	AWS DNS サービスを使用する場合はオプション

   Show more

3. 以下のコマンドを実行して、AWS シークレットを作成します。

   $ oc create secret generic <secret_name> \
     --from-literal=provider=aws \
     --from-literal=domain-filter=<domain_name> \
     --from-file=credentials=<path_to_aws_credentials_file> -n local-cluster

   注記

   シークレットの障害復旧バックアップは自動的に有効になりません。障害復旧のためにシークレットをバックアップするには、次のコマンドを入力して hypershift-operator-external-dns-credentials を追加します。

   $ oc label secret hypershift-operator-external-dns-credentials \
     -n local-cluster \
     cluster.open-cluster-management.io/backup=""

手順

1. AWS Route 53 管理コンソールで、[ホストゾーンの作成] を クリックします。
2. Hosted zone configuration ページでドメイン名を入力し、タイプとして Public hosted zone が選択されていることを確認し、Create hosted zone をクリックします。
3. ゾーンが作成されたら、Records タブの Value/Route traffic to 列の値をメモします。
4. メインドメインで、DNS 要求を委任ゾーンにリダイレクトするための NS レコードを作成します。Value フィールドに、前の手順でメモした値を入力します。
5. Create records をクリックします。

6. 次の例のように、新しいサブゾーンにテストエントリーを作成し、dig コマンドでテストして、DNS ホストゾーンが機能していることを確認します。

   $ dig +short test.user-dest-public.aws.kerberos.com

   出力例

   192.168.1.1

7. LoadBalancer および Route サービスのホスト名を設定するホステッドクラスターを作成するには、次のコマンドを入力します。

   $ hcp create cluster aws --name=<hosted_cluster_name> \
     --endpoint-access=PublicAndPrivate \
     --external-dns-domain=<public_hosted_zone> ...

   <public_hosted_zone> は、作成したパブリックホストゾーンに置き換えます。

   ホステッドクラスターの services ブロックの例

     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 のアノテーションを付けます。Services と Routes の場合、Control Plane Operator は、サービスエンドポイントの servicePublishingStrategy フィールドの hostname パラメーターの値を使用します。DNS レコードを作成するには、external-dns デプロイメントなどのメカニズムを使用できます。

   サービスレベルの DNS 間接化をパブリックサービスにのみ設定できます。プライベートサービスは hypershift.local プライベートゾーンを使用するため、hostname を設定できません。

   次の表は、サービスとエンドポイントの組み合わせに対して hostname を設定することが有効な場合を示しています。

   Expand

   表4.4 hostname を設定するためのサービスとエンドポイントの組み合わせ

   サービス	Public	PublicAndPrivate	Private
   APIServer	Y	Y	N
   OAuthServer	Y	Y	N
   Konnectivity	Y	N	N
   Ignition	Y	N	N

   Show more

手順

1. hcp コマンドラインインターフェイス (CLI) で、以下のコマンドを入力して管理クラスターにアクセスします。

   $ export KUBECONFIG=<path_to_management_cluster_kubeconfig>

2. 次のコマンドを入力して、External DNS Operator が実行されていることを確認します。

   $ oc get pod -n hypershift -lapp=external-dns

   出力例

   NAME                            READY   STATUS    RESTARTS   AGE
   external-dns-7c89788c69-rn8gp   1/1     Running   0          40s

3. 外部 DNS を使用してホステッドクラスターを作成するには、次のコマンドを入力します。

   $ hcp create cluster aws \
       --role-arn <arn_role> \
       --instance-type <instance_type> \
       --region <region> \
       --auto-repair \
       --generate-ssh \
       --name <hosted_cluster_name> \
       --namespace clusters \
       --base-domain <service_consumer_domain> \
       --node-pool-replicas <node_replica_count> \
       --pull-secret <path_to_your_pull_secret> \
       --release-image quay.io/openshift-release-dev/ocp-release:<ocp_release_image> \
       --external-dns-domain=<service_provider_domain> \
       --endpoint-access=<endpoint_access_configuration> \
       --sts-creds <path_to_sts_credential_file>

   各項目の説明:

   <arn_role>

   Amazon Resource Name (ARN) を指定します。例: arn:aws:iam::820196288204:role/myrole。

   <instance_types>

   インスタンスタイプを指定します。例: m6i.xlarge。

   < 領域 >

   AWS リージョンを指定します。たとえば、us-east-1 など です。

   <hosted_cluster_name>

   ホステッドクラスター名を指定します。例: my-external-aws。

   < サービスコンシューマードメイン >

   サービス利用者が所有するパブリックホストゾーンを指定します。例: service-consumer-domain.com。

   <node_replica_count>

   ノードレプリカ数を指定します。たとえば、2 です。

   < プルシークレットへのパス >

   プルシークレットファイルへのパスを指定します。

   <ocp_release_image>

   使用するサポートされている OpenShift Container Platform のバージョンを指定します。たとえば、4.21.0-multi などです。

   < サービスプロバイダードメイン >

   サービスプロバイダーが所有するパブリックホストゾーンを指定します。たとえば、service-provider-domain.com などです。

   <endpoint_access_configuraton>

   外部 DNS のエンドポイントアクセス設定を指定します。PublicAndPrivate として設定します。外部 DNS は、Public または PublicAndPrivate 設定でのみ使用できます。

   <sts_credential_file へのパス >

   AWS STS 認証情報ファイルへのパスを指定します。例: /home/user/sts-creds/sts-creds.json。

手順

1. AWS 上にホステッドクラスターを作成するには、次のコマンドを実行します。

   $ hcp create cluster aws \
       --name <hosted_cluster_name> \
       --infra-id <infra_id> \
       --base-domain <basedomain> \
       --sts-creds <path_to_sts_credential_file> \
       --pull-secret <path_to_pull_secret> \
       --region <region> \
       --generate-ssh \
       --node-pool-replicas <node_pool_replica_count> \
       --namespace <hosted_cluster_namespace> \
       --role-arn <role_name> \
       --render-into <file_name>.yaml

   各項目の説明:

   <hosted_cluster_name>

   ホステッドクラスターの名前を指定します。

   <infra_id>

   インフラストラクチャー名を指定します。<hosted_cluster_name> と <infra_id> には同じ値を指定する必要があります。そうしないと、multicluster engine for Kubernetes Operator のコンソールに、クラスターが正しく表示されない可能性があります。

   < ベースドメイン >

   ベースドメインを指定します。例: example.com。

   <sts_credential_file へのパス >

   AWS STS 認証情報ファイルへのパスを指定します。例: /home/user/sts-creds/sts-creds.json。

   <path_to_pull_secret>

   プルシークレットへのパスを指定します。たとえば、/user/name/pullsecret です。

   < 領域 >

   AWS リージョン名を指定します。例: us-east-1。

   <node_pool_replica_count>

   ノードプールのレプリカ数を指定します。たとえば、3 と 指定します。

   <hosted_cluster_namespace>

   HostedCluster と NodePool の カスタムリソースを特定の名前空間に作成することを指定します。それ以外の場合、デフォルトでは、すべての HostedCluster および NodePool カスタムリソースは clusters 名前空間に作成されます。

   < ロール名 >

   Amazon Resource Name (ARN) を指定します。例: arn:aws:iam::820196288204:role/myrole。

   <file_name>

   EC2 インスタンスが共有ハードウェア上で実行されるか、シングルテナントハードウェア上で実行されるかを指定します。--render-into フラグを含めると、Kubernetes リソースが、このフィールドで指定した YAML ファイルにレンダリングされます。次のステップに進み、YAML ファイルを編集してください。

2. 前のコマンドに --render-into フラグを含めた場合は、指定した YAML ファイルを編集します。YAML ファイルの NodePool 仕様を編集して、EC2 インスタンスを共有ハードウェア上で実行するか、シングルテナントハードウェア上で実行するかを指定します。次に例を示します。

   サンプル YAML ファイル

   apiVersion: hypershift.openshift.io/v1beta1
   kind: NodePool
   metadata:
     name: <nodepool_name>
   spec:
     platform:
       aws:
         placement:
           tenancy: "default"

   各項目の説明:

   <nodepool_name>

   NodePool リソースの名前を指定します。

   spec.platform.aws.placement.tenancy

   テナントの有効な値を指定します。default、dedicated、host のいずれかです。ノードプールインスタンスを共有ハードウェア上で実行する場合は、"default" を使用します。各ノードプールインスタンスをシングルテナントハードウェア上で実行する場合は、"dedicated" を使用します。事前に割り当てられた専用ホスト上でノードプールインスタンスを実行する場合は、"host" を使用します。

3. 外部ロードバランサーを使用する場合は、次の例に示すように、HostedCluster リソースを編集してイングレスエンドポイントを設定します。エンドポイントを設定しない場合、デフォルトの動作では、サービスが Ingress を公開するノードポートがランダム化されます。イングレスコントローラーがデフォルトの Ingress ルートを公開する方法を設定するには、endpointPublishingStrategy パラメーターとその基となる関数を設定します。

   #...
   spec:
     operatorConfiguration:
       ingressOperator:
         endpointPublishingStrategy:
           type: LoadBalancerService
           loadBalancer:
             scope: Internal
   #...

   spec.operatorConfiguration.ingressOperator.endPointPublishingStrategy.type パラメーターは、ロードバランサーのエンドポイントを指定します。AWS の場合は、LoadBalancerService タイプを使用してください。

検証

1. ホステッドクラスターのステータスを確認し、AVAILABLE の値が True であることを確認します。以下のコマンドを実行します。

   $ oc get hostedclusters -n <hosted_cluster_namespace>

2. 次のコマンドを実行して、ノードプールのリストを取得します。

   $ oc get nodepools --namespace <hosted_cluster_namespace>

手順

1. 次のコマンドを入力して、ノードのプライベート IP を確認します。

   $ aws ec2 describe-instances \
     --filter="Name=tag:kubernetes.io/cluster/<infra_id>,Values=owned" \
     | jq '.Reservations[] | .Instances[] | select(.PublicDnsName=="") \
     | .PrivateIpAddress'

2. 次のコマンドを入力して、ホステッドクラスターの kubeconfig ファイルを作成し、ノードにコピーします。

   $ hcp create kubeconfig > <hosted_cluster_kubeconfig>

3. 踏み台経由でノードの 1 つに SSH 接続するために、次のコマンドを入力します。

   $ ssh -o ProxyCommand="ssh ec2-user@<bastion_ip> \
     -W %h:%p" core@<node_ip>

4. SSH シェルから、次のコマンドを入力して、kubeconfig ファイルの内容をノード上のファイルにコピーします。

   $ mv <path_to_kubeconfig_file> <new_file_name>

5. 次のコマンドを入力して、kubeconfig ファイルをエクスポートします。

   $ export KUBECONFIG=<path_to_kubeconfig_file>

6. 次のコマンドを入力して、ホステッドクラスターのステータスを確認します。

   $ oc get clusteroperators clusterversion

手順

1. 次のコマンドを入力して、ハードウェアインベントリーを保存する namespace を作成します。

   $ oc --kubeconfig ~/<directory_example>/mgmt-kubeconfig create \
     namespace <namespace_example>

   各項目の説明:

   <directory_example>

   管理クラスターの kubeconfig ファイルが保存されるディレクトリーの名前です。

   <namespace_example>

   作成する namespace の名前 (例: hardware-inventory) です。

   出力例

   namespace/hardware-inventory created

2. 次のコマンドを入力して、管理クラスターのプルシークレットをコピーします。

   $ oc --kubeconfig ~/<directory_example>/mgmt-kubeconfig \
     -n openshift-config get secret pull-secret -o yaml \
     | grep -vE "uid|resourceVersion|creationTimestamp|namespace" \
     | sed "s/openshift-config/<namespace_example>/g" \
     | oc --kubeconfig ~/<directory_example>/mgmt-kubeconfig \
     -n <namespace> apply -f -

   各項目の説明:

   <directory_example>

   管理クラスターの kubeconfig ファイルが保存されるディレクトリーの名前です。

   <namespace_example>

   作成する namespace の名前 (例: hardware-inventory) です。

   出力例

   secret/pull-secret created

3. 次のコンテンツを YAML ファイルに追加して、InfraEnv リソースを作成します。

   apiVersion: agent-install.openshift.io/v1beta1
   kind: InfraEnv
   metadata:
     name: hosted
     namespace: <namespace_example>
   spec:
     additionalNTPSources:
     - <ip_address>
     pullSecretRef:
       name: pull-secret
     sshAuthorizedKey: <ssh_public_key>
   # ...

4. 次のコマンドを入力して、YAML ファイルに変更を適用します。

   $ oc apply -f <infraenv_config>.yaml

   <infraenv_config> は、ファイルの名前に置き換えます。

5. 次のコマンドを入力して、InfraEnv リソースが作成されたことを確認します。

   $ oc --kubeconfig ~/<directory_example>/mgmt-kubeconfig \
     -n <namespace_example> get infraenv hosted

6. 次の 2 つの方法のいずれかに従ってベアメタルホストを追加します。

   • Metal3 Operator を使用しない場合は、InfraEnv リソースから検出 ISO を取得し、次のステップを実行して手動でホストをブートします。

     1. 次のコマンドを入力してライブ ISO をダウンロードします。

        $ oc get infraenv -A

        $ oc get infraenv <namespace_example> -o jsonpath='{.status.isoDownloadURL}' -n <namespace_example> <iso_url>

     2. ISO をブートします。ノードは Assisted Service と通信し、InfraEnv リソースと同じ namespace にエージェントとして登録されます。

     3. 各エージェントに対して、インストールディスク ID とホスト名を設定し、承認してエージェントが使用可能であることを示します。

        1. Hosted Control Plane ネームスペースのエージェントを取得するには、次のコマンドを入力してください。

           $ oc -n <hosted_control_plane_namespace> get agents

           この例では、2 人のエージェントがリストされています。

           出力例

           NAME                                   CLUSTER   APPROVED   ROLE          STAGE
           example-agent-1                        auto-assign
           example-agent-2                        auto-assign

        2. 最初のエージェントのインストールディスク ID とホスト名を設定するには、次のコマンドを入力してください。

           $ oc -n <hosted_control_plane_namespace> \
             patch agent example-agent-1 \
             -p '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-0.example.krnl.es"}}' \
             --type merge

        3. 2 番目のエージェントのインストールディスク ID とホスト名を設定するには、次のコマンドを入力してください。

           $ oc -n <hosted_control_plane_namespace> \
             patch agent example-agent-2 -p \
             '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-1.example.krnl.es"}}' \
             --type merge

   • Metal3 Operator を使用する場合は、次のオブジェクトを作成することで、ベアメタルホストの登録を自動化できます。

     1. YAML ファイルを作成し、そこに次のコンテンツを追加します。

        apiVersion: v1
        kind: Secret
        metadata:
          name: hosted-worker0-bmc-secret
          namespace: <namespace_example>
        data:
          password: <password>
          username: <username>
        type: Opaque
        ---
        apiVersion: v1
        kind: Secret
        metadata:
          name: hosted-worker1-bmc-secret
          namespace: <namespace_example>
        data:
          password: <password>
          username: <username>
        type: Opaque
        ---
        apiVersion: v1
        kind: Secret
        metadata:
          name: hosted-worker2-bmc-secret
          namespace: <namespace_example>
        data:
          password: <password>
          username: <username>
        type: Opaque
        ---
        apiVersion: metal3.io/v1alpha1
        kind: BareMetalHost
        metadata:
          name: hosted-worker0
          namespace: <namespace_example>
          labels:
            infraenvs.agent-install.openshift.io: hosted
          annotations:
            inspect.metal3.io: disabled
            bmac.agent-install.openshift.io/hostname: hosted-worker0
        spec:
          automatedCleaningMode: disabled
          bmc:
            disableCertificateVerification: True
            address: <bmc_address>
            credentialsName: hosted-worker0-bmc-secret
          bootMACAddress: aa:aa:aa:aa:02:01
          online: true
        ---
        apiVersion: metal3.io/v1alpha1
        kind: BareMetalHost
        metadata:
          name: hosted-worker1
          namespace: <namespace_example>
          labels:
            infraenvs.agent-install.openshift.io: hosted
          annotations:
            inspect.metal3.io: disabled
            bmac.agent-install.openshift.io/hostname: hosted-worker1
        spec:
          automatedCleaningMode: disabled
          bmc:
            disableCertificateVerification: True
            address: <bmc_address>
            credentialsName: hosted-worker1-bmc-secret
          bootMACAddress: aa:aa:aa:aa:02:02
          online: true
        ---
        apiVersion: metal3.io/v1alpha1
        kind: BareMetalHost
        metadata:
          name: hosted-worker2
          namespace: <namespace_example>
          labels:
            infraenvs.agent-install.openshift.io: hosted
          annotations:
            inspect.metal3.io: disabled
            bmac.agent-install.openshift.io/hostname: hosted-worker2
        spec:
          automatedCleaningMode: disabled
          bmc:
            disableCertificateVerification: True
            address: <bmc_address>
            credentialsName: hosted-worker2-bmc-secret
          bootMACAddress: aa:aa:aa:aa:02:03
          online: true
        ---
        apiVersion: rbac.authorization.k8s.io/v1
        kind: Role
        metadata:
          name: capi-provider-role
          namespace: <namespace_example>
        rules:
        - apiGroups:
          - agent-install.openshift.io
          resources:
          - agents
          verbs:
          - '*'

        各項目の説明:

        <namespace_example>

        namespace です。

        <password>

        シークレットのパスワードです。

        <username>

        シークレットのユーザー名です。

        <bmc_address>

        BareMetalHost オブジェクトの BMC アドレスです。

        注記

        この YAML ファイルを適用すると、次のオブジェクトが作成されます。

        • ベースボード管理コントローラー (BMC) の認証情報が含まれるシークレット
        • BareMetalHost オブジェクト
        • HyperShift Operator によるエージェントの管理が可能になるロール

        BareMetalHost オブジェクトで infraenvs.agent-install.openshift.io: hosted カスタムラベルを使用して InfraEnv リソースが参照されることに注意してください。これにより、生成された ISO を使用してノードがブートされます。

     2. 次のコマンドを入力して、YAML ファイルに変更を適用します。

        $ oc apply -f <bare_metal_host_config>.yaml

        <bare_metal_host_config> は、ファイルの名前に置き換えます。

7. 次のコマンドを入力し、BareMetalHost オブジェクトの状態が Provisioning になるまで数分間待ちます。

   $ oc --kubeconfig ~/<directory_example>/mgmt-kubeconfig -n <namespace_example> get bmh

   出力例

   NAME             STATE          CONSUMER   ONLINE   ERROR   AGE
   hosted-worker0   provisioning              true             106s
   hosted-worker1   provisioning              true             106s
   hosted-worker2   provisioning              true             106s

8. 次のコマンドを入力して、ノードが起動し、エージェントとして表示されていることを確認します。このプロセスには数分かかる場合があり、コマンドを複数回入力する必要があることもあります。

   $ oc --kubeconfig ~/<directory_example>/mgmt-kubeconfig -n <namespace_example> get agent

   出力例

   NAME                                   CLUSTER   APPROVED   ROLE          STAGE
   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0201             true       auto-assign
   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0202             true       auto-assign
   aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0203             true       auto-assign

手順

1. OpenShift Container Platform Web コンソールを開き、管理者の認証情報を入力してログインします。コンソールを開く手順は、「Web コンソールへのアクセス」を参照してください。
2. コンソールヘッダーで、All Clusters が選択されていることを確認します。
3. Infrastructure → Host inventory → Create infrastructure environment をクリックします。
4. InfraEnv リソースを作成した後、InfraEnv ビュー内から Add hosts をクリックし、利用可能なオプションから選択してベアメタルホストを追加します。

手順

1. 次のコマンドを入力して namespace を作成します。

   $ oc create ns <hosted_cluster_namespace>

   <hosted_cluster_namespace> は、ホステッドクラスター namespace の識別子に置き換えます。namespace は HyperShift Operator によって作成されます。ベアメタルインフラストラクチャーにホステッドクラスターを作成するプロセスでは、Cluster API プロバイダー用のロールが生成されます。このロールを生成するには、namespace が事前に存在している必要があります。

2. 次のコマンドを入力して、ホステッドクラスターの設定ファイルを作成します。

   $ hcp create cluster agent \
     --name=<hosted_cluster_name> \
     --pull-secret=<path_to_pull_secret> \
     --agent-namespace=<hosted_control_plane_namespace> \
     --base-domain=<base_domain> \
     --api-server-address=api.<hosted_cluster_name>.<base_domain>
     --etcd-storage-class=<etcd_storage_class> \
     --ssh-key=<path_to_ssh_key> \
     --namespace=<hosted_cluster_namespace> \
     --control-plane-availability-policy=HighlyAvailable \
     --release-image=quay.io/openshift-release-dev/ocp-release:<ocp_release_image>-multi \
     --node-pool-replicas=<node_pool_replica_count> \
     --render \
     --render-sensitive \
     --ssh-key <home_directory>/<path_to_ssh_key>/<ssh_key> > hosted-cluster-config.yaml

   各項目の説明:

   <hosted_cluster_name>

   例: ホステッドクラスターの名前を指定します。

   <path_to_pull_secret>

   プルシークレットへのパスを指定します。例: /user/name/pullsecret。

   < ホスト型コントロールプレーン名空間 >

   clusters-example など、Hosted Control Plane の名前空間を指定します。oc get agent -n <hosted_control_plane_namespace> コマンドを使用して、この namespace でエージェントが使用可能であることを確認します。

   < ベースドメイン >

   ベースドメインを指定します。例: krnl.es。

   --api-server-address

   ホステッドクラスターにおける Kubernetes API 通信に使用される IP アドレスを指定します。--api-server-address フラグを設定しない場合は、管理クラスターに接続するためにログインする必要があります。

   <etcd_storage_class>

   etcd ストレージクラス名を指定します (例: lvm-storageclass)。

   <SSH キーへのパス >

   SSH 公開鍵へのパスを指定します。デフォルトのファイルパスは ~/.ssh/id_rsa.pub です。

   <hosted_cluster_namespace>

   ホステッドクラスターの namespace を指定します。

   制御プレーン可用性ポリシー

   Hosted Control Plane コンポーネントの可用性ポリシーを指定します。サポートされているオプションは SingleReplica と HighlyAvailable です。デフォルト値は HighlyAvailable です。

   <ocp_release_image>

   使用するサポートされている OpenShift Container Platform のバージョンを指定します。たとえば、4.21.0-multi などです。非接続環境を使用している場合は、<ocp_release_image> をダイジェストイメージに置き換えます。OpenShift Container Platform リリースイメージダイジェストを抽出するには、「OpenShift Container Platform リリースイメージダイジェストの抽出」を参照してください。

   <node_pool_replica_count>

   ノードプールのレプリカ数を指定します (例: 3)。レプリカ数は 0 以上で指定する必要があります。指定したとおりの数のノードが作成されます。この値を指定しない場合、ノードプールは作成されません。

   < ホームディレクトリー >/<SSH キーへのパス >/<SSH キー >

   SSH 鍵へのパスを指定します。例: user/.ssh/id_rsa。

3. サービス公開ストラテジーを設定します。デフォルトでは、ホステッドクラスターは NodePort サービス公開ストラテジーを使用します。これは、ノードポートが追加のインフラストラクチャーなしで常に利用可能であるためです。ただし、ロードバランサーを使用するようにサービス公開ストラテジーを設定することもできます。

   • デフォルトの NodePort ストラテジーを使用している場合は、管理クラスターノードではなく、ホステッドクラスターコンピュートノードを指すように DNS を設定します。詳細は、「ベアメタル上の DNS 設定」を参照してください。

   • 実稼働環境では、証明書の処理と自動 DNS 解決を提供する LoadBalancer ストラテジーを使用します。次の例は、ホステッドクラスターの設定ファイルで LoadBalancer サービス公開ストラテジーを変更する方法を示しています。

     apiVersion: hypershift.openshift.io/v1beta1
     kind: HostedCluster
     metadata:
     # ...
     spec:
       services:
       - service: APIServer
         servicePublishingStrategy:
           type: LoadBalancer
       - service: Ignition
         servicePublishingStrategy:
           type: Route
       - service: Konnectivity
         servicePublishingStrategy:
           type: Route
       - service: OAuthServer
         servicePublishingStrategy:
           type: Route
       - service: OIDC
         servicePublishingStrategy:
           type: Route
       sshKey:
         name: <ssh_key>
     # ...

     API サーバータイプとして LoadBalancer を指定します。それ以外のすべてのサービスでは、タイプとして Route を指定します。

4. 外部ロードバランサーを使用する場合は、次の例に示すようにイングレスエンドポイントを設定してください。エンドポイントを設定しない場合、デフォルトの動作では、サービスが Ingress を公開するノードポートがランダム化されます。イングレスコントローラーがデフォルトの Ingress ルートを公開する方法を設定するには、HostedCluster リソースを編集して、endpointPublishingStrategy パラメーターとその基となる関数を設定します。

   apiVersion: hypershift.openshift.io/v1beta1
   kind: HostedCluster
   metadata:
   #...
   spec:
     operatorConfiguration:
       ingressOperator:
         endpointPublishingStrategy:
           hostNetwork:
             httpPort: 80
             httpsPort: 443
             protocol: TCP
             statsPort: 1936
           type: HostNetwork
   #...

   spec.operatorConfiguration.ingressOperator.endPointPublishingStrategy.type パラメーターは、ロードバランサーのエンドポイントを指定します。ベアメタル環境へのインストールには、HostNetwork タイプを使用してください。

5. 次のコマンドを入力して、ホステッドクラスター設定ファイルに変更を適用します。

   $ oc apply -f hosted_cluster_config.yaml

6. 次のコマンドを入力して、ホステッドクラスター、ノードプール、および Pod の作成を確認します。

   $ oc get hostedcluster \
     <hosted_cluster_namespace> -n \
     <hosted_cluster_namespace> -o \
     jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .

   $ oc get nodepool \
     <hosted_cluster_namespace> -n \
     <hosted_cluster_namespace> -o \
     jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .

   $ oc get pods -n <hosted_cluster_namespace>

7. ホステッドクラスターの準備ができていることを確認します。Available: True というステータスはクラスターの準備完了状態であることを示しています。ノードプールのステータスには AllMachinesReady: True と表示されます。これらのステータスは、すべてのクラスター Operator の健全性を示しています。

8. ホステッドクラスターに MetalLB をインストールします。

   1. 次のコマンドを入力して、ホステッドクラスターから kubeconfig ファイルを展開し、ホステッドクラスターアクセス用の環境変数を設定します。

      $ oc get secret \
        <hosted_cluster_namespace>-admin-kubeconfig \
        -n <hosted_cluster_namespace> \
        -o jsonpath='{.data.kubeconfig}' \
        | base64 -d > \
        kubeconfig-<hosted_cluster_namespace>.yaml

      $ export KUBECONFIG="/path/to/kubeconfig-<hosted_cluster_namespace>.yaml"

   2. install-metallb-operator.yaml ファイルを作成して MetalLB Operator をインストールします。

      apiVersion: v1
      kind: Namespace
      metadata:
        name: metallb-system
      ---
      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: metallb-operator
        namespace: metallb-system
      ---
      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: metallb-operator
        namespace: metallb-system
      spec:
        channel: "stable"
        name: metallb-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
        installPlanApproval: Automatic
      # ...

   3. 以下のコマンドを入力してファイルを適用します。

      $ oc apply -f install-metallb-operator.yaml

   4. deploy-metallb-ipaddresspool.yaml ファイルを作成して、MetalLB IP アドレスプールを設定します。

      apiVersion: metallb.io/v1beta1
      kind: IPAddressPool
      metadata:
        name: metallb
        namespace: metallb-system
      spec:
        autoAssign: true
        addresses:
        - 10.11.176.71-10.11.176.75
      ---
      apiVersion: metallb.io/v1beta1
      kind: L2Advertisement
      metadata:
        name: l2advertisement
        namespace: metallb-system
      spec:
        ipAddressPools:
        - metallb
      # ...

   5. 次のコマンドを入力して設定を適用します。

      $ oc apply -f deploy-metallb-ipaddresspool.yaml

   6. 次のコマンドを入力して、Operator ステータス、IP アドレスプール、および L2Advertisement リソースを確認し、MetalLB のインストールを検証します。

      $ oc get pods -n metallb-system

      $ oc get ipaddresspool -n metallb-system

      $ oc get l2advertisement -n metallb-system

9. Ingress 用のロードバランサーを設定します。

   1. ingress-loadbalancer.yaml ファイルを作成します。

      apiVersion: v1
      kind: Service
      metadata:
        annotations:
          metallb.universe.tf/address-pool: metallb
        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
      # ...

   2. 次のコマンドを入力して設定を適用します。

      $ oc apply -f ingress-loadbalancer.yaml

   3. 次のコマンドを入力して、ロードバランサーサービスが期待どおりに動作することを確認します。

      $ oc get svc metallb-ingress -n openshift-ingress

      出力例

      NAME              TYPE           CLUSTER-IP       EXTERNAL-IP    PORT(S)                      AGE
      metallb-ingress   LoadBalancer   172.31.127.129   10.11.176.71   80:30961/TCP,443:32090/TCP   16h

10. ロードバランサーと連携するように DNS を設定します。

    1. *.apps.<hosted_cluster_namespace>.<base_domain> ワイルドカード DNS レコードがロードバランサーの IP アドレスをポイントするように、apps ドメインの DNS を設定します。

    2. 次のコマンドを入力して DNS 解決を確認します。

       $ nslookup console-openshift-console.apps.<hosted_cluster_namespace>.<base_domain> <load_balancer_ip_address>

       出力例

       Server:         10.11.176.1
       Address:        10.11.176.1#53
       
       Name:   console-openshift-console.apps.my-hosted-cluster.sample-base-domain.com
       Address: 10.11.176.71

検証

1. 次のコマンドを入力して、クラスター Operator を確認します。

   $ oc get clusteroperators

   すべての Operator に AVAILABLE: True、PROGRESSING: False、DEGRADED: False が表示されていることを確認します。

2. 次のコマンドを入力してノードを確認します。

   $ oc get nodes

   各ノードのステータスが READY であることを確認します。

3. Web ブラウザーに次の URL を入力して、コンソールへのアクセスをテストします。

   https://console-openshift-console.apps.<hosted_cluster_namespace>.<base_domain>

手順

1. OpenShift Container Platform Web コンソールを開き、管理者の認証情報を入力してログインします。コンソールを開く手順は、「Web コンソールへのアクセス」を参照してください。
2. コンソールヘッダーで、All Clusters が選択されていることを確認します。
3. Infrastructure → Clusters をクリックします。

4. Create cluster → Host inventory → Hosted control plane をクリックします。

   Create cluster ページが表示されます。

5. Create cluster ページでプロンプトに従い、クラスター、ノードプール、ネットワーク、および自動化に関する詳細を入力します。

   注記

   クラスターの詳細を入力する際には、次のヒントが役立つ場合があります。

   • 事前定義された値を使用してコンソールのフィールドに自動的に値を入力する場合は、ホストインベントリーの認証情報を作成できます。詳細は、「オンプレミス環境の認証情報の作成」を参照してください。
   • Cluster details ページのプルシークレットは、OpenShift Container Platform リソースへのアクセスに使用する OpenShift Container Platform プルシークレットです。ホストインベントリー認証情報を選択した場合は、プルシークレットが自動的に入力されます。
   • Node pools ページでは、namespace にノードプールのホストが含まれます。コンソールを使用してホストインベントリーを作成した場合、コンソールは専用の namespace を作成します。
   • Networking ページで、API サーバー公開ストラテジーを選択します。ホステッドクラスターの API サーバーは、既存のロードバランサーを使用するか、NodePort タイプのサービスとして公開できます。API サーバーに到達できる宛先を指す api.<hosted_cluster_name>.<base_domain> 設定の DNS エントリーが存在する必要があります。このエントリーとして、管理クラスター内のノードの 1 つを指すレコード、または受信トラフィックを Ingress Pod にリダイレクトするロードバランサーを指すレコードを指定できます。

6. エントリーを確認し、Create をクリックします。

   Hosted cluster ビューが表示されます。

7. Hosted cluster ビューでホステッドクラスターのデプロイメントを監視します。
8. ホステッドクラスターに関する情報が表示されない場合は、All Clusters が選択されていることを確認し、クラスター名をクリックします。
9. コントロールプレーンコンポーネントの準備が整うまで待ちます。このプロセスには数分かかる場合があります。
10. ノードプールのステータスを表示するには、NodePool セクションまでスクロールします。ノードをインストールするプロセスには約 10 分かかります。Nodes をクリックして、ノードがホステッドクラスターに参加したかどうかを確認することもできます。

手順

1. YAML ファイルを作成して、イメージコンテンツソースポリシー (ICSP) を定義します。以下の例を参照してください。

   - mirrors:
     - brew.registry.redhat.io
     source: registry.redhat.io
   - mirrors:
     - brew.registry.redhat.io
     source: registry.stage.redhat.io
   - mirrors:
     - brew.registry.redhat.io
     source: registry-proxy.engineering.redhat.com

2. ファイルを icsp.yaml として保存します。このファイルにはミラーレジストリーが含まれます。

3. ミラーレジストリーを使用してホステッドクラスターを作成するには、次のコマンドを実行します。

   $ hcp create cluster agent \
       --name=<hosted_cluster_name> \

   1

   
       --pull-secret=<path_to_pull_secret> \

   2

   
       --agent-namespace=<hosted_control_plane_namespace> \

   3

   
       --base-domain=<basedomain> \

   4

   
       --api-server-address=api.<hosted_cluster_name>.<basedomain> \

   5

   
       --image-content-sources icsp.yaml  \

   6

   
       --ssh-key  <path_to_ssh_key> \

   7

   
       --namespace <hosted_cluster_namespace> \

   8

   
       --release-image=quay.io/openshift-release-dev/ocp-release:<ocp_release_image> 

   9

   1

   ホステッドクラスターの名前を指定します (例: example)。

   1 2

   プルシークレットへのパスを指定します (例: /user/name/pullsecret)。

   3

   Hosted Control Plane namespace を指定します (例: clusters-example)。oc get agent -n <hosted-control-plane-namespace> コマンドを使用して、この namespace でエージェントが使用可能であることを確認します。

   4

   ベースドメインを指定します (例: krnl.es)。

   5

   --api-server-address フラグは、ホステッドクラスター内の Kubernetes API 通信に使用される IP アドレスを定義します。--api-server-address フラグを設定しない場合は、管理クラスターに接続するためにログインする必要があります。

   6

   ICSP およびミラーレジストリーを定義する icsp.yaml ファイルを指定します。

   7

   SSH 公開鍵へのパスを指定します。デフォルトのファイルパスは ~/.ssh/id_rsa.pub です。

   8

   ホステッドクラスターの namespace を指定します。

   9

   使用するサポートされている OpenShift Container Platform のバージョンを指定します。たとえば、4.21.0-multi など です。非接続環境を使用している場合は、<ocp_release_image> をダイジェストイメージに置き換えます。OpenShift Container Platform リリースイメージダイジェストを抽出するには、「OpenShift Container Platform リリースイメージダイジェストの抽出」を参照してください。