7.10. Deployment Manager テンプレートの使用による GCP でのユーザーによってプロビジョニングされるインフラストラクチャーへのクラスターのインストール

手順

1. 本トピックの VPC の Deployment Manager テンプレートセクションを確認し、これを 01_vpc.py としてコンピューターに保存します。このテンプレートは、クラスターに必要な VPC について記述しています。

2. 01_xvdb.yaml リソース定義ファイルを作成します。

   $ cat <<EOF >01_vpc.yaml
   imports:
   - path: 01_vpc.py
   
   resources:
   - name: cluster-vpc
     type: 01_vpc.py
     properties:
       infra_id: '${INFRA_ID}' 1
       region: '${REGION}' 2
       master_subnet_cidr: '${MASTER_SUBNET_CIDR}' 3
       worker_subnet_cidr: '${WORKER_SUBNET_CIDR}' 4
   EOF

   1

   infra_id は抽出手順で得られる INFRA_ID インフラストラクチャー名です。

   2

   region はクラスターをデプロイするリージョンです (例: us-central1)。

   3

   master_subnet_cidr はマスターサブネットの CIDR です (例: 10.0.0.0/17)。

   4

   worker_subnet_cidr はワーカーサブネットの CIDR です (例: 10.0.128.0/17)。

3. gcloud CLI を使用してデプロイメントを作成します。

   $ gcloud deployment-manager deployments create ${INFRA_ID}-vpc --config 01_vpc.yaml

手順

1. 本トピックの内部ロードバランサーの Deployment Manager テンプレートセクションからテンプレートをコピーし、これを 02_lb_int.py としてコンピューターに保存します。このテンプレートは、クラスターに必要な内部負荷分散オブジェクトについて記述しています。
2. また、外部クラスターについては、本トピックの外部ロードバランサーの Deployment Manager テンプレートセクションからテンプレートをコピーし、これを 02_lb_ext.py としてコンピューターに保存します。このテンプレートは、クラスターに必要な外部負荷分散オブジェクトについて記述しています。

3. デプロイメントテンプレートが使用する変数をエクスポートします。

   1. クラスターネットワークの場所をエクスポートします。

      $ export CLUSTER_NETWORK=(`gcloud compute networks describe ${INFRA_ID}-network --format json | jq -r .selfLink`)

   2. コントロールプレーンのサブネットの場所をエクスポートします。

      $ export CONTROL_SUBNET=(`gcloud compute networks subnets describe ${INFRA_ID}-master-subnet --region=${REGION} --format json | jq -r .selfLink`)

   3. クラスターが使用する 3 つのゾーンをエクスポートします。

      $ export ZONE_0=(`gcloud compute regions describe ${REGION} --format=json | jq -r .zones[0] | cut -d "/" -f9`)

      $ export ZONE_1=(`gcloud compute regions describe ${REGION} --format=json | jq -r .zones[1] | cut -d "/" -f9`)

      $ export ZONE_2=(`gcloud compute regions describe ${REGION} --format=json | jq -r .zones[2] | cut -d "/" -f9`)

4. 02_infra.yaml リソース定義ファイルを作成します。

   $ cat <<EOF >02_infra.yaml
   imports:
   - path: 02_lb_ext.py
   - path: 02_lb_int.py 1
   resources:
   - name: cluster-lb-ext 2
     type: 02_lb_ext.py
     properties:
       infra_id: '${INFRA_ID}' 3
       region: '${REGION}' 4
   - name: cluster-lb-int
     type: 02_lb_int.py
     properties:
       cluster_network: '${CLUSTER_NETWORK}'
       control_subnet: '${CONTROL_SUBNET}' 5
       infra_id: '${INFRA_ID}'
       region: '${REGION}'
       zones: 6
       - '${ZONE_0}'
       - '${ZONE_1}'
       - '${ZONE_2}'
   EOF

   1 2

   外部クラスターをデプロイする場合にのみ必要です。

   3

   infra_id は抽出手順で得られる INFRA_ID インフラストラクチャー名です。

   4

   region はクラスターをデプロイするリージョンです (例: us-central1)。

   5

   control_subnet は、コントロールサブセットの URL です。

   6

   zones は、コントロールプレーンインスタンスをデプロイするゾーンです (例: us-east1-b、us-east1-c、および us-east1-d)。

5. gcloud CLI を使用してデプロイメントを作成します。

   $ gcloud deployment-manager deployments create ${INFRA_ID}-infra --config 02_infra.yaml

6. クラスター IP アドレスをエクスポートします。

   $ export CLUSTER_IP=(`gcloud compute addresses describe ${INFRA_ID}-cluster-ip --region=${REGION} --format json | jq -r .address`)

7. 外部クラスターの場合、クラスターのパブリック IP アドレスもエクスポートします。

   $ export CLUSTER_PUBLIC_IP=(`gcloud compute addresses describe ${INFRA_ID}-cluster-public-ip --region=${REGION} --format json | jq -r .address`)

手順

1. 本トピックのプライベート DNS の Deployment Manager テンプレートセクションのテンプレートをコピーし、これを 02_dns.py としてコンピューターに保存します。このテンプレートは、クラスターに必要なプライベート DNS オブジェクトについて記述しています。

2. 02_dns.yaml リソース定義ファイルを作成します。

   $ cat <<EOF >02_dns.yaml
   imports:
   - path: 02_dns.py
   
   resources:
   - name: cluster-dns
     type: 02_dns.py
     properties:
       infra_id: '${INFRA_ID}' 1
       cluster_domain: '${CLUSTER_NAME}.${BASE_DOMAIN}' 2
       cluster_network: '${CLUSTER_NETWORK}' 3
   EOF

   1

   infra_id は抽出手順で得られる INFRA_ID インフラストラクチャー名です。

   2

   cluster_domain はクラスターのドメインです (例: openshift.example.com)。

   3

   cluster_network はクラスターネットワークの selfLink URL です。

3. gcloud CLI を使用してデプロイメントを作成します。

   $ gcloud deployment-manager deployments create ${INFRA_ID}-dns --config 02_dns.yaml

4. このテンプレートは Deployment Manager の制限により DNS エントリーを作成しないので、手動で作成する必要があります。

   1. 内部 DNS エントリーを追加します。

      $ if [ -f transaction.yaml ]; then rm transaction.yaml; fi
      $ gcloud dns record-sets transaction start --zone ${INFRA_ID}-private-zone
      $ gcloud dns record-sets transaction add ${CLUSTER_IP} --name api.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 60 --type A --zone ${INFRA_ID}-private-zone
      $ gcloud dns record-sets transaction add ${CLUSTER_IP} --name api-int.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 60 --type A --zone ${INFRA_ID}-private-zone
      $ gcloud dns record-sets transaction execute --zone ${INFRA_ID}-private-zone

   2. 外部クラスターの場合、外部 DNS エントリーも追加します。

      $ if [ -f transaction.yaml ]; then rm transaction.yaml; fi
      $ gcloud dns record-sets transaction start --zone ${BASE_DOMAIN_ZONE_NAME}
      $ gcloud dns record-sets transaction add ${CLUSTER_PUBLIC_IP} --name api.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 60 --type A --zone ${BASE_DOMAIN_ZONE_NAME}
      $ gcloud dns record-sets transaction execute --zone ${BASE_DOMAIN_ZONE_NAME}

手順

1. 本トピックのファイアウォールの Deployment Manager テンプレートセクションのテンプレートをコピーし、これを 03_firewall.py としてコンピューターに保存します。このテンプレートは、クラスターに必要なセキュリティーグループについて記述しています。

2. 03_firewall.yaml リソース定義ファイルを作成します。

   $ cat <<EOF >03_firewall.yaml
   imports:
   - path: 03_firewall.py
   
   resources:
   - name: cluster-firewall
     type: 03_firewall.py
     properties:
       allowed_external_cidr: '0.0.0.0/0' 1
       infra_id: '${INFRA_ID}' 2
       cluster_network: '${CLUSTER_NETWORK}' 3
       network_cidr: '${NETWORK_CIDR}' 4
   EOF

   1

   allowed_external_cidr は、クラスター API にアクセスでき、ブートストラップホストに対して SSH を実行できる CIDR 範囲です。内部クラスターの場合、この値を ${NETWORK_CIDR} に設定します。

   2

   infra_id は抽出手順で得られる INFRA_ID インフラストラクチャー名です。

   3

   cluster_network はクラスターネットワークの selfLink URL です。

   4

   network_cidr は VPC ネットワークの CIDR です (例: 10.0.0.0/16)。

3. gcloud CLI を使用してデプロイメントを作成します。

   $ gcloud deployment-manager deployments create ${INFRA_ID}-firewall --config 03_firewall.yaml

手順

1. 本トピックのIAM ロールの Deployment Manager テンプレートセクションのテンプレートをコピーし、これを 03_iam.py としてコンピューターに保存します。このテンプレートは、クラスターに必要な IAM ロールについて記述しています。

2. 03_iam.yaml リソース定義ファイルを作成します。

   $ cat <<EOF >03_iam.yaml
   imports:
   - path: 03_iam.py
   resources:
   - name: cluster-iam
     type: 03_iam.py
     properties:
       infra_id: '${INFRA_ID}' 1
   EOF

   1

   infra_id は抽出手順で得られる INFRA_ID インフラストラクチャー名です。

3. gcloud CLI を使用してデプロイメントを作成します。

   $ gcloud deployment-manager deployments create ${INFRA_ID}-iam --config 03_iam.yaml

4. マスターサービスアカウントの変数をエクスポートします。

   $ export MASTER_SERVICE_ACCOUNT=(`gcloud iam service-accounts list --filter "email~^${INFRA_ID}-m@${PROJECT_NAME}." --format json | jq -r '.[0].email'`)

5. ワーカーサービスアカウントの変数をエクスポートします。

   $ export WORKER_SERVICE_ACCOUNT=(`gcloud iam service-accounts list --filter "email~^${INFRA_ID}-w@${PROJECT_NAME}." --format json | jq -r '.[0].email'`)

6. コンピュートマシンをホストするサブネットの変数をエクスポートします。

   $ export COMPUTE_SUBNET=(`gcloud compute networks subnets describe ${INFRA_ID}-worker-subnet --region=${REGION} --format json | jq -r .selfLink`)

7. このテンプレートは Deployment Manager の制限によりポリシーバインディングを作成しないため、これらを手動で作成する必要があります。

   $ gcloud projects add-iam-policy-binding ${PROJECT_NAME} --member "serviceAccount:${MASTER_SERVICE_ACCOUNT}" --role "roles/compute.instanceAdmin"
   $ gcloud projects add-iam-policy-binding ${PROJECT_NAME} --member "serviceAccount:${MASTER_SERVICE_ACCOUNT}" --role "roles/compute.networkAdmin"
   $ gcloud projects add-iam-policy-binding ${PROJECT_NAME} --member "serviceAccount:${MASTER_SERVICE_ACCOUNT}" --role "roles/compute.securityAdmin"
   $ gcloud projects add-iam-policy-binding ${PROJECT_NAME} --member "serviceAccount:${MASTER_SERVICE_ACCOUNT}" --role "roles/iam.serviceAccountUser"
   $ gcloud projects add-iam-policy-binding ${PROJECT_NAME} --member "serviceAccount:${MASTER_SERVICE_ACCOUNT}" --role "roles/storage.admin"
   
   $ gcloud projects add-iam-policy-binding ${PROJECT_NAME} --member "serviceAccount:${WORKER_SERVICE_ACCOUNT}" --role "roles/compute.viewer"
   $ gcloud projects add-iam-policy-binding ${PROJECT_NAME} --member "serviceAccount:${WORKER_SERVICE_ACCOUNT}" --role "roles/storage.admin"

8. サービスアカウントキーを作成し、後で使用できるようにこれをローカルに保存します。

   $ gcloud iam service-accounts keys create service-account-key.json --iam-account=${MASTER_SERVICE_ACCOUNT}

手順

1. RHCOS イメージミラー ページから RHCOS イメージを取得します。

   重要

   RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールする OpenShift Container Platform バージョンと等しいか、それ以下のバージョンの内で最も新しいバージョンのイメージをダウンロードする必要があります。利用可能な場合は、OpenShift Container Platform バージョンに一致するイメージのバージョンを使用します。

   ファイル名には、rhcos-<version>-<arch>-gcp.<arch>.tar.gz 形式の OpenShift Container Platform のバージョン番号が含まれます。

2. Google ストレージバケットを作成します。

   $ gsutil mb gs://<bucket_name>

3. RHCOS イメージを Google ストレージバケットにアップロードします。

   $ gsutil cp <downloaded_image_file_path>/rhcos-<version>-x86_64-gcp.x86_64.tar.gz  gs://<bucket_name>

4. アップロードした RHCOS イメージの場所を変数としてエクスポートします。

   $ export IMAGE_SOURCE=gs://<bucket_name>/rhcos-<version>-x86_64-gcp.x86_64.tar.gz

5. クラスターイメージを作成します。

   $ gcloud compute images create "${INFRA_ID}-rhcos-image" \
       --source-uri="${IMAGE_SOURCE}"

手順

1. 本トピックのブートストラップマシンの Deployment Manager テンプレートセクションからテンプレートをコピーし、これを 04_bootstrap.py としてコンピューターに保存します。このテンプレートは、クラスターに必要なブートストラップマシンについて記述しています。

2. インストールプログラムで必要な Red Hat Enterprise Linux CoreOS (RHCOS) イメージの場所をエクスポートします。

   $ export CLUSTER_IMAGE=(`gcloud compute images describe ${INFRA_ID}-rhcos-image --format json | jq -r .selfLink`)

3. バケットを作成し、bootstrap.ign ファイルをアップロードします。

   $ gsutil mb gs://${INFRA_ID}-bootstrap-ignition
   $ gsutil cp <installation_directory>/bootstrap.ign gs://${INFRA_ID}-bootstrap-ignition/

4. Ignition 設定にアクセスするために使用するブートストラップインスタンスの署名付き URL を作成します。出力から URL を変数としてエクスポートします。

   $ export BOOTSTRAP_IGN=`gsutil signurl -d 1h service-account-key.json gs://${INFRA_ID}-bootstrap-ignition/bootstrap.ign | grep "^gs:" | awk '{print $5}'`

5. 04_bootstrap.yaml リソース定義ファイルを作成します。

   $ cat <<EOF >04_bootstrap.yaml
   imports:
   - path: 04_bootstrap.py
   
   resources:
   - name: cluster-bootstrap
     type: 04_bootstrap.py
     properties:
       infra_id: '${INFRA_ID}' 1
       region: '${REGION}' 2
       zone: '${ZONE_0}' 3
   
       cluster_network: '${CLUSTER_NETWORK}' 4
       control_subnet: '${CONTROL_SUBNET}' 5
       image: '${CLUSTER_IMAGE}' 6
       machine_type: 'n1-standard-4' 7
       root_volume_size: '128' 8
   
       bootstrap_ign: '${BOOTSTRAP_IGN}' 9
   EOF

   1

   infra_id は抽出手順で得られる INFRA_ID インフラストラクチャー名です。

   2

   region はクラスターをデプロイするリージョンです (例: us-central1)。

   3

   zone はブートストラップインスタンスをデプロイするゾーンです (例: us-central1-b)。

   4

   cluster_network はクラスターネットワークの selfLink URL です。

   5

   control_subnet は、コントロールサブセットの selfLink URL です。

   6

   image は RHCOS イメージの selfLink URL です。

   7

   machine_type はインスタンスのマシンタイプです (例: n1-standard-4)。

   8

   root_volume_size はブートストラップマシンのブートディスクサイズです。

   9

   bootstrap_ign は署名付き URL の作成時の URL 出力です。

6. gcloud CLI を使用してデプロイメントを作成します。

   $ gcloud deployment-manager deployments create ${INFRA_ID}-bootstrap --config 04_bootstrap.yaml

7. Deployment Manager の制限によりテンプレートではロードバランサーのメンバーシップを管理しないため、ブートストラップマシンは手動で追加する必要があります。

   1. ブートストラップインスタンスを内部ロードバランサーのインスタンスグループに追加します。

      $ gcloud compute instance-groups unmanaged add-instances \
          ${INFRA_ID}-bootstrap-instance-group --zone=${ZONE_0} --instances=${INFRA_ID}-bootstrap

   2. ブートストラップインスタンスグループを内部ロードバランサーのバックエンドサービスに追加します。

      $ gcloud compute backend-services add-backend \
          ${INFRA_ID}-api-internal-backend-service --region=${REGION} --instance-group=${INFRA_ID}-bootstrap-instance-group --instance-group-zone=${ZONE_0}

手順

1. 本トピックのコントロールプレーンマシンの Deployment Manager テンプレートセクションからテンプレートをコピーし、これを 05_control_plane.py としてコンピューターに保存します。このテンプレートは、クラスターに必要なコントロールプレーンのマシンについて記述しています。

2. リソース定義で必要な以下の変数をエクスポートします。

   $ export MASTER_IGNITION=`cat <installation_directory>/master.ign`

3. 05_control_plane.yaml リソース定義ファイルを作成します。

   $ cat <<EOF >05_control_plane.yaml
   imports:
   - path: 05_control_plane.py
   
   resources:
   - name: cluster-control-plane
     type: 05_control_plane.py
     properties:
       infra_id: '${INFRA_ID}' 1
       zones: 2
       - '${ZONE_0}'
       - '${ZONE_1}'
       - '${ZONE_2}'
   
       control_subnet: '${CONTROL_SUBNET}' 3
       image: '${CLUSTER_IMAGE}' 4
       machine_type: 'n1-standard-4' 5
       root_volume_size: '128'
       service_account_email: '${MASTER_SERVICE_ACCOUNT}' 6
   
       ignition: '${MASTER_IGNITION}' 7
   EOF

   1

   infra_id は抽出手順で得られる INFRA_ID インフラストラクチャー名です。

   2

   zones は、コントロールプレーンインスタンスをデプロイするゾーンです (例: us-central1-a、us-central1-b、および us-central1-c)。

   3

   control_subnet は、コントロールサブセットの selfLink URL です。

   4

   image は RHCOS イメージの selfLink URL です。

   5

   machine_type はインスタンスのマシンタイプです (例: n1-standard-4)。

   6

   service_account_email は作成したマスターサービスアカウントのメールアドレスです。

   7

   ignition は master.ign ファイルの内容です。

4. gcloud CLI を使用してデプロイメントを作成します。

   $ gcloud deployment-manager deployments create ${INFRA_ID}-control-plane --config 05_control_plane.yaml

5. Deployment Manager の制限により、テンプレートではロードバランサーのメンバーシップを管理しないため、コントロールプレーンマシンを手動で追加する必要があります。

   • 以下のコマンドを実行してコントロールプレーンマシンを適切なインスタンスグループに追加します。

     $ gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-master-${ZONE_0}-instance-group --zone=${ZONE_0} --instances=${INFRA_ID}-master-0
     $ gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-master-${ZONE_1}-instance-group --zone=${ZONE_1} --instances=${INFRA_ID}-master-1
     $ gcloud compute instance-groups unmanaged add-instances ${INFRA_ID}-master-${ZONE_2}-instance-group --zone=${ZONE_2} --instances=${INFRA_ID}-master-2

   • 外部クラスターの場合、以下のコマンドを実行してコントロールプレーンマシンをターゲットプールに追加する必要もあります。

     $ gcloud compute target-pools add-instances ${INFRA_ID}-api-target-pool --instances-zone="${ZONE_0}" --instances=${INFRA_ID}-master-0
     $ gcloud compute target-pools add-instances ${INFRA_ID}-api-target-pool --instances-zone="${ZONE_1}" --instances=${INFRA_ID}-master-1
     $ gcloud compute target-pools add-instances ${INFRA_ID}-api-target-pool --instances-zone="${ZONE_2}" --instances=${INFRA_ID}-master-2

手順

1. インストールプログラムが含まれるディレクトリーに切り替え、以下のコマンドを実行します。

   $ ./openshift-install wait-for bootstrap-complete --dir <installation_directory> \ 1
       --log-level info 2

   1

   <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

   2

   異なるインストールの詳細情報を表示するには、info ではなく、warn、debug、または error を指定します。

   コマンドが FATAL 警告を出さずに終了する場合、実稼働用のコントロールプレーンは初期化されています。

2. ブートストラップリソースを削除します。

   $ gcloud compute backend-services remove-backend ${INFRA_ID}-api-internal-backend-service --region=${REGION} --instance-group=${INFRA_ID}-bootstrap-instance-group --instance-group-zone=${ZONE_0}
   $ gsutil rm gs://${INFRA_ID}-bootstrap-ignition/bootstrap.ign
   $ gsutil rb gs://${INFRA_ID}-bootstrap-ignition
   $ gcloud deployment-manager deployments delete ${INFRA_ID}-bootstrap

手順

1. 本トピックのワーカーマシンの Deployment Manager テンプレートからテンプレートをコピーし、これを 06_worker.py としてコンピューターに保存します。このテンプレートは、クラスターに必要なワーカーマシンについて記述しています。

2. リソース定義が使用する変数をエクスポートします。

   1. コンピュートマシンをホストするサブネットをエクスポートします。

      $ export COMPUTE_SUBNET=(`gcloud compute networks subnets describe ${INFRA_ID}-worker-subnet --region=${REGION} --format json | jq -r .selfLink`)

   2. サービスアカウントのメールアドレスをエクスポートします。

      $ export WORKER_SERVICE_ACCOUNT=(`gcloud iam service-accounts list --filter "email~^${INFRA_ID}-w@${PROJECT_NAME}." --format json | jq -r '.[0].email'`)

   3. コンピュートマシンの Ignition 設定ファイルの場所をエクスポートします。

      $ export WORKER_IGNITION=`cat <installation_directory>/worker.ign`

3. 06_worker.yaml リソース定義ファイルを作成します。

   $ cat <<EOF >06_worker.yaml
   imports:
   - path: 06_worker.py
   
   resources:
   - name: 'worker-0' 1
     type: 06_worker.py
     properties:
       infra_id: '${INFRA_ID}' 2
       zone: '${ZONE_0}' 3
       compute_subnet: '${COMPUTE_SUBNET}' 4
       image: '${CLUSTER_IMAGE}' 5
       machine_type: 'n1-standard-4' 6
       root_volume_size: '128'
       service_account_email: '${WORKER_SERVICE_ACCOUNT}' 7
       ignition: '${WORKER_IGNITION}' 8
   - name: 'worker-1'
     type: 06_worker.py
     properties:
       infra_id: '${INFRA_ID}' 9
       zone: '${ZONE_1}' 10
       compute_subnet: '${COMPUTE_SUBNET}' 11
       image: '${CLUSTER_IMAGE}' 12
       machine_type: 'n1-standard-4' 13
       root_volume_size: '128'
       service_account_email: '${WORKER_SERVICE_ACCOUNT}' 14
       ignition: '${WORKER_IGNITION}' 15
   EOF

   1

   name はワーカーマシンの名前です (例: worker-0)。

   2 9

   infra_id は抽出手順で得られる INFRA_ID インフラストラクチャー名です。

   3 10

   zone はワーカーマシンをデプロイするゾーンです (例: us-central1-a)。

   4 11

   compute_subnet はコンピュートサブネットの selfLink URL です。

   5 12

   image は RHCOS イメージの selfLink URL です。¹

   6 13

   machine_type はインスタンスのマシンタイプです (例: n1-standard-4)。

   7 14

   service_account_email は作成したワーカーサービスアカウントのメールアドレスです。

   8 15

   Ignition は worker.ign ファイルの内容です。

4. オプション: 追加のインスタンスを起動する必要がある場合には、06_worker.py タイプの追加のリソースを 06_worker.yaml リソース定義ファイルに組み込みます。

5. gcloud CLI を使用してデプロイメントを作成します。

   $ gcloud deployment-manager deployments create ${INFRA_ID}-worker --config 06_worker.yaml

1. GCP Marketplace イメージを使用するには、使用するオファーを指定します。

   • OpenShift Container Platform: https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-ocp-48-x86-64-202210040145
   • OpenShift Platform Plus: https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-opp-48-x86-64-202206140145
   • OpenShift Kubernetes Engine: https://www.googleapis.com/compute/v1/projects/redhat-marketplace-public/global/images/redhat-coreos-oke-48-x86-64-202206140145

手順

1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
2. Version ドロップダウンメニューで適切なバージョンを選択します。
3. OpenShift v4.9 Linux Client エントリーの横にある Download Now をクリックして、ファイルを保存します。

4. アーカイブを展開します。

   $ tar xvf <file>

5. oc バイナリーを、PATH にあるディレクトリーに配置します。

   PATH を確認するには、以下のコマンドを実行します。

   $ echo $PATH

手順

1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
2. Version ドロップダウンメニューで適切なバージョンを選択します。
3. OpenShift v4.9 Windows Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
4. ZIP プログラムでアーカイブを解凍します。

5. oc バイナリーを、PATH にあるディレクトリーに移動します。

   PATH を確認するには、コマンドプロンプトを開いて以下のコマンドを実行します。

   C:\> path

手順

1. Red Hat カスタマーポータルの OpenShift Container Platform ダウンロードページ に移動します。
2. Version ドロップダウンメニューで適切なバージョンを選択します。
3. OpenShift v4.9 MacOSX Client エントリーの横にある Download Now をクリックして、ファイルを保存します。
4. アーカイブを展開し、解凍します。

5. oc バイナリーをパスにあるディレクトリーに移動します。

   PATH を確認するには、ターミナルを開き、以下のコマンドを実行します。

   $ echo $PATH

手順

1. kubeadmin 認証情報をエクスポートします。

   $ export KUBECONFIG=<installation_directory>/auth/kubeconfig 1

   1

   <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

2. エクスポートされた設定を使用して、oc コマンドを正常に実行できることを確認します。

   $ oc whoami

   出力例

   system:admin

手順

1. クラスターがマシンを認識していることを確認します。

   $ oc get nodes

   出力例

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  63m  v1.22.1
   master-1  Ready     master  63m  v1.22.1
   master-2  Ready     master  64m  v1.22.1

   出力には作成したすべてのマシンが一覧表示されます。

   注記

   上記の出力には、一部の CSR が承認されるまで、ワーカーノード (ワーカーノードとも呼ばれる) が含まれない場合があります。

2. 保留中の証明書署名要求 (CSR) を確認し、クラスターに追加したそれぞれのマシンのクライアントおよびサーバー要求に Pending または Approved ステータスが表示されていることを確認します。

   $ oc get csr

   出力例

   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
   ...

   この例では、2 つのマシンがクラスターに参加しています。この一覧にはさらに多くの承認された CSR が表示される可能性があります。

3. 追加したマシンの保留中の CSR すべてが Pending ステータスになった後に CSR が承認されない場合には、クラスターマシンの CSR を承認します。

   注記

   CSR のローテーションは自動的に実行されるため、クラスターにマシンを追加後 1 時間以内に CSR を承認してください。1 時間以内に承認しない場合には、証明書のローテーションが行われ、各ノードに 3 つ以上の証明書が存在するようになります。これらの証明書すべてを承認する必要があります。クライアントの CSR が承認された後に、Kubelet は提供証明書のセカンダリー CSR を作成します。これには、手動の承認が必要になります。次に、後続の提供証明書の更新要求は、Kubelet が同じパラメーターを持つ新規証明書を要求する場合に machine-approver によって自動的に承認されます。

   注記

   ベアメタルおよび他のユーザーによってプロビジョニングされるインフラストラクチャーなどのマシン API ではないプラットフォームで実行されているクラスターの場合、kubelet 提供証明書要求 (CSR) を自動的に承認する方法を実装する必要があります。要求が承認されない場合、API サーバーが kubelet に接続する際に提供証明書が必須であるため、oc exec、 oc rsh、および oc logs コマンドは正常に実行できません。Kubelet エンドポイントにアクセスする操作には、この証明書の承認が必要です。この方法は新規 CSR の有無を監視し、CSR が system:node または system:admin グループの node-bootstrapper サービスアカウントによって提出されていることを確認し、ノードのアイデンティティーを確認します。

   • それらを個別に承認するには、それぞれの有効な CSR について以下のコマンドを実行します。

     $ oc adm certificate approve <csr_name> 1

     1

     <csr_name> は、現行の CSR の一覧からの CSR の名前です。

   • すべての保留中の CSR を承認するには、以下のコマンドを実行します。

     $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve

     注記

     一部の Operator は、一部の CSR が承認されるまで利用できない可能性があります。

4. クライアント要求が承認されたら、クラスターに追加した各マシンのサーバー要求を確認する必要があります。

   $ oc get csr

   出力例

   NAME        AGE     REQUESTOR                                                                   CONDITION
   csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending
   csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
   ...

5. 残りの CSR が承認されず、それらが Pending ステータスにある場合、クラスターマシンの CSR を承認します。

   • それらを個別に承認するには、それぞれの有効な CSR について以下のコマンドを実行します。

     $ oc adm certificate approve <csr_name> 1

     1

     <csr_name> は、現行の CSR の一覧からの CSR の名前です。

   • すべての保留中の CSR を承認するには、以下のコマンドを実行します。

     $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve

6. すべてのクライアントおよびサーバーの CSR が承認された後に、マシンのステータスが Ready になります。以下のコマンドを実行して、これを確認します。

   $ oc get nodes

   出力例

   NAME      STATUS    ROLES   AGE  VERSION
   master-0  Ready     master  73m  v1.22.1
   master-1  Ready     master  73m  v1.22.1
   master-2  Ready     master  74m  v1.22.1
   worker-0  Ready     worker  11m  v1.22.1
   worker-1  Ready     worker  11m  v1.22.1

   注記

   サーバー CSR の承認後にマシンが Ready ステータスに移行するまでに数分の時間がかかる場合があります。

手順

1. Ingress ルーターがロードバランサーを作成し、 EXTERNAL-IP フィールドにデータを設定するのを待機します。

   $ oc -n openshift-ingress get service router-default

   出力例

   NAME             TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)                      AGE
   router-default   LoadBalancer   172.30.18.154   35.233.157.184   80:32288/TCP,443:31215/TCP   98

2. A レコードをゾーンに追加します。

   • A レコードを使用するには、以下を実行します。

     1. ルーター IP アドレスの変数をエクスポートします。

        $ export ROUTER_IP=`oc -n openshift-ingress get service router-default --no-headers | awk '{print $4}'`

     2. A レコードをプライベートゾーンに追加します。

        $ if [ -f transaction.yaml ]; then rm transaction.yaml; fi
        $ gcloud dns record-sets transaction start --zone ${INFRA_ID}-private-zone
        $ gcloud dns record-sets transaction add ${ROUTER_IP} --name \*.apps.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 300 --type A --zone ${INFRA_ID}-private-zone
        $ gcloud dns record-sets transaction execute --zone ${INFRA_ID}-private-zone

     3. また、外部クラスターの場合は、A レコードをパブリックゾーンに追加します。

        $ if [ -f transaction.yaml ]; then rm transaction.yaml; fi
        $ gcloud dns record-sets transaction start --zone ${BASE_DOMAIN_ZONE_NAME}
        $ gcloud dns record-sets transaction add ${ROUTER_IP} --name \*.apps.${CLUSTER_NAME}.${BASE_DOMAIN}. --ttl 300 --type A --zone ${BASE_DOMAIN_ZONE_NAME}
        $ gcloud dns record-sets transaction execute --zone ${BASE_DOMAIN_ZONE_NAME}

   • ワイルドカードを使用する代わりに明示的なドメインを追加するには、クラスターのそれぞれの現行ルートのエントリーを作成します。

     $ oc get --all-namespaces -o jsonpath='{range .items[*]}{range .status.ingress[*]}{.host}{"\n"}{end}{end}' routes

     出力例

     oauth-openshift.apps.your.cluster.domain.example.com
     console-openshift-console.apps.your.cluster.domain.example.com
     downloads-openshift-console.apps.your.cluster.domain.example.com
     alertmanager-main-openshift-monitoring.apps.your.cluster.domain.example.com
     grafana-openshift-monitoring.apps.your.cluster.domain.example.com
     prometheus-k8s-openshift-monitoring.apps.your.cluster.domain.example.com

手順

1. クラスターのインストールを完了します。

   $ ./openshift-install --dir <installation_directory> wait-for install-complete 1

   出力例

   INFO Waiting up to 30m0s for the cluster to initialize...

   1

   <installation_directory> には、インストールファイルを保存したディレクトリーへのパスを指定します。

   重要
   • インストールプログラムが生成する Ignition 設定ファイルには、24 時間が経過すると期限切れになり、その後に更新される証明書が含まれます。証明書を更新する前にクラスターが停止し、24 時間経過した後にクラスターを再起動すると、クラスターは期限切れの証明書を自動的に復元します。例外として、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。詳細は、コントロールプレーン証明書の期限切れの状態からのリカバリー についてのドキュメントを参照してください。
   • 24 時間証明書はクラスターのインストール後 16 時間から 22 時間にローテーションするため、Ignition 設定ファイルは、生成後 12 時間以内に使用することをお勧めします。12 時間以内に Ignition 設定ファイルを使用することにより、インストール中に証明書の更新が実行された場合のインストールの失敗を回避できます。

2. クラスターの稼働状態を確認します。

   1. 以下のコマンドを実行し、現在のクラスターバージョンとステータスを表示します。

      $ oc get clusterversion

      出力例

      NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
      version             False       True          24m     Working towards 4.5.4: 99% complete

   2. 以下のコマンドを実行し、 Cluster Version Operator (CVO) を使用してコントロールプレーンで管理される Operator を表示します。

      $ oc get clusteroperators

      出力例

      NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
      authentication                             4.5.4     True        False         False      7m56s
      cloud-credential                           4.5.4     True        False         False      31m
      cluster-autoscaler                         4.5.4     True        False         False      16m
      console                                    4.5.4     True        False         False      10m
      csi-snapshot-controller                    4.5.4     True        False         False      16m
      dns                                        4.5.4     True        False         False      22m
      etcd                                       4.5.4     False       False         False      25s
      image-registry                             4.5.4     True        False         False      16m
      ingress                                    4.5.4     True        False         False      16m
      insights                                   4.5.4     True        False         False      17m
      kube-apiserver                             4.5.4     True        False         False      19m
      kube-controller-manager                    4.5.4     True        False         False      20m
      kube-scheduler                             4.5.4     True        False         False      20m
      kube-storage-version-migrator              4.5.4     True        False         False      16m
      machine-api                                4.5.4     True        False         False      22m
      machine-config                             4.5.4     True        False         False      22m
      marketplace                                4.5.4     True        False         False      16m
      monitoring                                 4.5.4     True        False         False      10m
      network                                    4.5.4     True        False         False      23m
      node-tuning                                4.5.4     True        False         False      23m
      openshift-apiserver                        4.5.4     True        False         False      17m
      openshift-controller-manager               4.5.4     True        False         False      15m
      openshift-samples                          4.5.4     True        False         False      16m
      operator-lifecycle-manager                 4.5.4     True        False         False      22m
      operator-lifecycle-manager-catalog         4.5.4     True        False         False      22m
      operator-lifecycle-manager-packageserver   4.5.4     True        False         False      18m
      service-ca                                 4.5.4     True        False         False      23m
      service-catalog-apiserver                  4.5.4     True        False         False      23m
      service-catalog-controller-manager         4.5.4     True        False         False      23m
      storage                                    4.5.4     True        False         False      17m

   3. 以下のコマンドを実行して、クラスター Pod を表示します。

      $ oc get pods --all-namespaces

      出力例

      NAMESPACE                                               NAME                                                                READY     STATUS      RESTARTS   AGE
      kube-system                                             etcd-member-ip-10-0-3-111.us-east-2.compute.internal                1/1       Running     0          35m
      kube-system                                             etcd-member-ip-10-0-3-239.us-east-2.compute.internal                1/1       Running     0          37m
      kube-system                                             etcd-member-ip-10-0-3-24.us-east-2.compute.internal                 1/1       Running     0          35m
      openshift-apiserver-operator                            openshift-apiserver-operator-6d6674f4f4-h7t2t                       1/1       Running     1          37m
      openshift-apiserver                                     apiserver-fm48r                                                     1/1       Running     0          30m
      openshift-apiserver                                     apiserver-fxkvv                                                     1/1       Running     0          29m
      openshift-apiserver                                     apiserver-q85nm                                                     1/1       Running     0          29m
      ...
      openshift-service-ca-operator                           openshift-service-ca-operator-66ff6dc6cd-9r257                      1/1       Running     0          37m
      openshift-service-ca                                    apiservice-cabundle-injector-695b6bcbc-cl5hm                        1/1       Running     0          35m
      openshift-service-ca                                    configmap-cabundle-injector-8498544d7-25qn6                         1/1       Running     0          35m
      openshift-service-ca                                    service-serving-cert-signer-6445fc9c6-wqdqn                         1/1       Running     0          35m
      openshift-service-catalog-apiserver-operator            openshift-service-catalog-apiserver-operator-549f44668b-b5q2w       1/1       Running     0          32m
      openshift-service-catalog-controller-manager-operator   openshift-service-catalog-controller-manager-operator-b78cr2lnm     1/1       Running     0          31m

   現在のクラスターバージョンが AVAILABLE の場合、インストールが完了します。