VPCクラスターへのワーカーノードの追加
仮想プライベートクラウド
VPCクラスターにワーカーノードを追加する方法については、以下のセクションを参照してください。
ワーカーノードを追加する前に、VPC アカウント vCPU, メモリ、GPU、インスタンスストレージ、および最適化されたインスタンスストレージリソースの十分なクォータがあることを確認してください。 VPCは、仮想サーバーインスタンス(VSI)ワーカーノードのアカウント単位でこれらのクォータを管理します。 クォータの上限に達すると、ワーカーノードのプロビジョニングは失敗します。 現在のクォータ使用量を確認するには、 VPCリソース・メトリクスの表示を参照してください。 詳細については、 VPCクォータおよび クォータ制限のためにVPCワーカーノードがプロビジョニングに失敗する理由を 参照してください。
アプリの可用性を高めるために、クラスター内の既存の 1 つまたは複数のゾーンにワーカー・ノードを追加できます。 ゾーンの障害からアプリケーションを保護するには、ゾーンをクラスターに追加します。
クラスターを作成すると、ワーカー・ノードがワーカー・プールにプロビジョンされます。 クラスターの作成後に、さらにワーカー・ノードをプールに追加するには、プールをサイズ変更するか、別のワーカー・プールを追加します。 デフォルトでは、ワーカー・プールは 1 つのゾーン内に存在します。 1 つのゾーン内のみにワーカー・プールがあるクラスターを、単一ゾーン・クラスターと呼びます。 クラスターに別のゾーンを追加すると、ワーカー・プールはそれらのゾーンにまたがって存在します。 複数のゾーン間にワーカー・プールが分散しているクラスターを、複数ゾーン・クラスターと呼びます。
複数ゾーン・クラスターの場合は、そのワーカー・ノードのリソースをバランスが取れた状態に維持してください。 すべてのワーカー・プールが同じゾーン間に分散されていることを確認し、ワーカーの追加/削除を行う場合は、個々のノードを追加するのではなく、プールのサイズを変更してください。 ワーカー・プールをセットアップしたら、ワークロード・リソース要求に基づいてワーカー・プールにワーカー・ノードを自動的に追加または削除するようにクラスター自動スケーリング機能をセットアップします。
セカンダリローカルストレージは、ワーカープール作成時に追加する必要があります。 ワーカープールを作成した後に VPC インフラストラクチャレベルからストレージを手動で追加することはサポートされておらず、クラスタにエフェメラルストレージが追加されることはありません。
クラシック・クラスターにワーカーを追加しますか? クラシック・クラスターへのワーカー・ノードの追加 を参照してください。
ワーカー・プールのサイズ変更
ワーカー・プールが 1 つのゾーンにあるか複数のゾーン間に分散しているかにかかわらず、既存のワーカー・プールのサイズを変更して、クラスター内のワーカー・ノードの数を追加したり減らしたりできます。
作業を始める前に、 オペレーター または、 管理者 IAMプラットフォームのアクセスロール がインストールされていることを確認してください。
ワーカー・プールのサイズを変更するには、そのワーカー・プールが各ゾーン内にデプロイするワーカー・ノードの数を変更します。
- サイズ変更するワーカー・プールの名前を取得します。
ibmcloud oc worker-pool ls --cluster CLUSTER-NAME - 各ゾーン内にデプロイするワーカー・ノードの数を指定して、ワーカー・プールのサイズを変更します。
ibmcloud oc worker-pool resize --cluster CLUSTER-NAME --worker-pool POOL_NAME --size-per-zone NUMBER_OF_WORKERS_PER_ZONE - ワーカー・プールがサイズ変更されたことを確認します。
ibmcloud oc worker ls --cluster CLUSTER-NAME --worker-pool POOL_NAMEus-south-1とus-south-2の 2 つのゾーンにまたがり、ゾーンごとに 2 つのワーカーノードにサイズ変更されたワーカープールの出力例:ID Public IP Private IP Machine Type State Status Zone Version kube-dal10-crb20b637238ea471f8d4a8b881aae4962-w7 169.xx.xxx.xxx 10.xxx.xx.xxx b3c.4x16 normal Ready us-south-1 1.35 kube-dal10-crb20b637238ea471f8d4a8b881aae4962-w8 169.xx.xxx.xxx 10.xxx.xx.xxx b3c.4x16 normal Ready us-south-1 1.35 kube-dal12-crb20b637238ea471f8d4a8b881aae4962-w9 169.xx.xxx.xxx 10.xxx.xx.xxx b3c.4x16 normal Ready us-south-2 1.35 kube-dal12-crb20b637238ea471f8d4a8b881aae4962-w10 169.xx.xxx.xxx 10.xxx.xx.xxx b3c.4x16 normal Ready us-south-2 1.35
新規ワーカー・プールの作成
専用ホスト上に新規ワーカー・プールを作成しますか? CLI での専用ホストのセットアップを参照してください。
作業を始める前に、 オペレーター または、 管理者 IAMプラットフォームのアクセスロール がインストールされていることを確認してください。
-
クラスターのVPC ID およびワーカー・ゾーンを取得し、ワーカー・プール内のワーカー・ノードをデプロイするゾーンを選択します。 クラスターの既存のワーカー・ゾーンを選択することも、クラスターが存在するリージョンの複数ゾーンのロケーションのゾーンを追加することもできます。
ibmcloud oc zone ls --provider vpc-gen2を実行して、使用可能なゾーンをリストできます。ibmcloud oc cluster get --cluster CLUSTER-NAME出力例
... VPC ID: <VPC_ID> ... Worker Zones: us-south-1, us-south-2, us-south-3 -
ゾーンごとに、ワーカー・プールに使用する VPC サブネットの ID をメモします。 ゾーン内に VPC サブネットがない場合は、VPC サブネットの作成 を実行します。 クラスターのワーカー・ノードおよびロード・バランサー・サービスの IP アドレスは VPC サブネットから取得されるので、256 個などの十分な数の IP アドレスが含まれる VPC サブネットを作成してください。
ibmcloud oc subnets --zone <ZONE> --provider vpc-gen2 --vpc-id <VPC_ID> -
各ゾーンについて、ワーカーノードで利用可能なフレーバーを確認してください。
ibmcloud oc flavors --zone <ZONE> --provider vpc-gen2 -
オプション: ワーカー・プール内の各ワーカー・ノードのローカル・ディスクを暗号化するには、鍵管理サービス (KMS) プロバイダーの詳細を取得します。 別のアカウントの KMS インスタンスを使用する場合は、KMS インスタンスが存在するアカウントで以下の手順を実行する必要があります。
-
VPC ワーカー・ノード のステップを実行して、KMS インスタンスを作成し、IAM でサービスを許可します。
-
使用可能な KMS インスタンスをリストし、ID をメモします。
ibmcloud oc kms instance ls ``` 1. 使用する KMS インスタンスの使用可能なルート鍵をリストし、**ID** をメモします。 ```sh {: pre} ibmcloud oc kms crk ls --instance-id <KMS_instance_ID> ``` -
-
ワーカー・プールを作成します。 その他のオプションについては、CLI の資料を参照してください。
ibmcloud oc worker-pool create vpc-gen2 --name NAME --cluster CLUSTER-NAME --flavor FLAVOR --size-per-zone NUMBER_OF_WORKER_NODES [--label KEY=VALUE] [--vpc-id] [[--kms-account-id <KMS_account_ID>] --kms-instance <KMS_instance_ID> --crk <root_key_ID>] [--dedicated-host-pool <dedicated-host-pool>] [--security-group <group-id>] [--operating-system SYSTEM]--label KEY=VALUE- オプション:
key=valueペアのラベルを使用して、プール内のワーカー・ノードに自動的にラベルを付けます。 --vpc-id VPC- ワーカープールがクラスター内で最初のものとなる場合は、このオプションを指定してください。
--operating-system RHEL_9_64|REDHAT_8_64|RHCOS: オプション。 クラスター内のワーカー・ノードのオペレーティング・システム。 クラスタのバージョン別に利用可能なオペレーティングシステムの一覧については 、 Red Hat OpenShift on IBM Cloud のバージョン情報 をご覧ください。 オプションが指定されていない場合、クラスター・バージョンに対応するデフォルトのオペレーティング・システムが使用されます。--kms-account-id ACCOUNT- オプション: KMS インスタンスが存在するアカウントを指定します。
--kms-instance-idオプションと--crkオプションも含めてください。 --kms-instance INSTANCE- オプション: KMS インスタンス ID を指定します。
--kms-account-idオプションと--crkオプションも含めてください。 --crk KEY- オプション: KMS ルート鍵を指定します。
--kms-account-idオプションと--kms-instanceオプションも含めてください。 --security-group GROUP- ワーカー・プール内のワーカーに追加のセキュリティー・グループを接続するには、このオプションを指定します。 接続するセキュリティー・グループ ID を含めます。
--dedicated-host-pool POOL- 専用ホスト上にワーカー・プールを作成する場合は、このオプションを指定します。
-
ワーカー・プールが作成されたことを確認します。
ibmcloud oc worker-pool ls --cluster CLUSTER-NAME -
デフォルトでは、ワーカー・プールを追加すると、ゾーンのないプールが作成されます。 ワーカー・ノードをゾーン内にデプロイするには、以前に取得したゾーンをワーカー・プールに追加する必要があります。 ワーカー・ノードを複数のゾーン間に分散させる場合は、ゾーンごとにこのコマンドを繰り返します。
ibmcloud oc zone add vpc-gen2 --zone ZONE --subnet-id SUBNET_ID --cluster CLUSTER-NAME --worker-pool WORKER_POOL_NAME -
追加したゾーンにワーカー・ノードがプロビジョンされたことを確認します。 State が
provisioningからnormalに変わったら、ワーカー・ノードの準備は完了です。ibmcloud oc worker ls --cluster CLUSTER-NAME --worker-pool POOL_NAME出力例
ID Primary IP Flavor State Status Zone Version kube-<ID_string>-<cluster_name>-<pool_name>-00000002 10.xxx.xx.xxx c2.2x4 provisioning Infrastructure instance status is 'pending' us-south-1 - kube-<ID_string>-<cluster_name>-<pool_name>-00000003 10.xxx.xx.xxx c2.2x4 normal Ready us-south-1 1.35_1511
ワーカー・プールへのゾーンの追加
ゾーンを既存のワーカー・プールに追加して、1 つのリージョン内の複数のゾーンに VPC クラスターを広げることができます。
ワーカー・プールにゾーンを追加すると、ワーカー・プールに定義されているワーカー・ノードが新しいゾーンにプロビジョンされ、将来のワークロード・スケジューリングの対象となります。 Red Hat OpenShift on IBM Cloud は、リージョンの failure-domain.beta.kubernetes.io/region ラベルとゾーンの failure-domain.beta.kubernetes.io/zone ラベルを各ワーカー・ノードに自動的に追加します。 Kubernetes スケジューラーは、これらのラベルを使用して、同じリージョン内のゾーン間にポッドを分散させます。
クラスター内に複数のワーカー・プールがある場合は、ワーカー・ノードがクラスター全体に均等に分散されるように、すべてのワーカー・プールにゾーンを追加します。 クラスターにワーカー・ノードを追加すると、新しいワーカー・ノードは、クラスター・マスターと同じ major.minor バージョンを実行しますが、その major.minor バージョンの最新のワーカー・ノード・パッチが適用されます。
始める前に: 「 [オペレーター または、 管理者 IAMプラットフォームのアクセスロール] 」(/docs/openshift?topic=openshift-iam-platform-access-roles)が設定されていることを確認してください。
-
クラスターのロケーションを確認し、既存のワーカー・ゾーンと VPC ID をメモします。
ibmcloud oc cluster get --cluster CLUSTER-NAME出力例
... VPC ID: <VPC_ID> Workers: 3 Worker Zones: us-south-1 ... Location: Dallas -
クラスターのロケーションとして使用可能なゾーンをリストして、追加できる他のゾーンを確認します。
ibmcloud oc zone ls --provider vpc-gen2 | grep LOCATION -
追加するゾーンごとに、使用可能な VPC サブネットをリストします。 ゾーン内に VPC サブネットがない場合は、VPC サブネットの作成 を実行します。 クラスターのワーカー・ノードおよびロード・バランサー・サービスの IP アドレスは VPC サブネットから取得されるので、256 個などの十分な数の IP アドレスが含まれる VPC サブネットを作成してください。 後で VPC サブネットの IP アドレスの数を変更することはできません。
ibmcloud oc subnets --zone ZONE --provider vpc-gen2 --vpc-id VPC_ID -
クラスター内のワーカー・プールをリストし、それらの名前をメモします。
ibmcloud oc worker-pool ls --cluster CLUSTER-NAME -
ゾーンをワーカー・プールに追加します。 ワーカー・プールに追加するゾーンごとに、この手順を繰り返します。 ワーカー・プールが複数ある場合は、すべてのゾーンでクラスターのバランスが取れるように、すべてのワーカー・プールにゾーンを追加してください。 各ワーカープールに対して、
--worker-poolオプションを指定してください。ワーカー・プールごとに別の VPC サブネットを使用する場合は、このコマンドをサブネットとその対応するワーカー・プールごとに繰り返します。 指定した VPC サブネットに新しいワーカー・ノードが追加されますが、既存のワーカー・ノードの VPC サブネットは変更されません。
ibmcloud oc zone add vpc-gen2 --zone ZONE --subnet-id SUBNET_ID --cluster CLUSTER-NAME --worker-pool WORKER_POOL_NAME -
ゾーンがクラスターに追加されたことを確認します。 出力の Worker Zones フィールドに、追加したゾーンが表示されるか確認します。 追加したゾーンに新しいワーカー・ノードがプロビジョンされたため、Workers フィールド内のワーカーの合計数が増えていることに注意してください。
ibmcloud oc cluster get --cluster CLUSTER-NAME出力例
Workers: 9 Worker Zones: us-south-1, us-south-2, us-south-3 -
Ingress を使用してアプリを公開するには、 ルーターを公開している VPC ロードバランサーを更新し、クラスター内の新しいゾーンのサブネットを含めるようにしてください。