Classicクラスタへのワーカーノードの追加

Classic infrastructure

クラシック・クラスタにワーカーノードを追加する方法については、以下のセクションを参照してください。

ワーカーを VPC クラスターに追加しますか? VPC クラスターへのワーカー・ノードの追加 を参照してください。

アプリの可用性を高めるために、クラスター内の既存の 1 つまたは複数のゾーンにワーカー・ノードを追加できます。 ゾーンの障害からアプリケーションを保護するには、ゾーンをクラスターに追加します。

クラスターを作成すると、ワーカー・ノードがワーカー・プールにプロビジョンされます。 クラスターの作成後に、さらにワーカー・ノードをプールに追加するには、プールをサイズ変更するか、別のワーカー・プールを追加します。 デフォルトでは、ワーカー・プールは 1 つのゾーン内に存在します。 1 つのゾーン内のみにワーカー・プールがあるクラスターを、単一ゾーン・クラスターと呼びます。 クラスターに別のゾーンを追加すると、ワーカー・プールはそれらのゾーンにまたがって存在します。 複数のゾーン間にワーカー・プールが分散しているクラスターを、複数ゾーン・クラスターと呼びます。

複数ゾーン・クラスターの場合は、そのワーカー・ノードのリソースをバランスが取れた状態に維持してください。 すべてのワーカー・プールが同じゾーン間に分散されていることを確認し、ワーカーの追加/削除を行う場合は、個々のノードを追加するのではなく、プールのサイズを変更してください。 ワーカー・プールをセットアップしたら、ワークロード・リソース要求に基づいてワーカー・プールにワーカー・ノードを自動的に追加または削除するようにクラスター自動スケーリング機能をセットアップします。

クラシック・ワーカーノードの予約機能は非推奨となりました。 2026年10月15日以降は、新規の予約契約を作成することはできません。 有効期限が迫っている既存の予約契約がある場合は、契約の有効期限が切れる前に、予約を使用しない新しいワーカープールを作成し、ワークロードを移行する必要があります。

新規ワーカー・プールの作成

新しいワーカー・プールを作成して、クラシック・クラスターにワーカー・ノードを追加できます。 これまで予約機能を使用してワーカーノードをプロビジョニングしていた場合は、予約機能が非推奨となっている点にご注意ください。 その代わりに、標準のワーカープールを作成してください。

作業を始める前に、 オペレーター または、 管理者 IAMプラットフォームのアクセスロール がインストールされていることを確認してください。

  1. クラスターのワーカー・ゾーンを取得し、ワーカー・プール内のワーカー・ノードをデプロイするゾーンを選択します。 単一ゾーン・クラスターの場合は、Worker Zones フィールドに表示されるゾーンを使用する必要があります。 複数ゾーン・クラスターの場合は、クラスターの既存のワーカー・ゾーンを選択することも、クラスターが存在するリージョンの複数ゾーンのロケーションのゾーンを追加することもできます。 ibmcloud oc zone ls を実行して、使用可能なゾーンをリストできます。

    ibmcloud oc cluster get --cluster CLUSTER_NAME_OR_ID
    

    出力例

    ...
    Worker Zones: dal10, dal12, dal13
    
  2. ゾーンごとに、使用可能なプライベート VLAN とパブリック VLAN をリストします。 使用するプライベート VLAN とパブリック VLAN をメモしておきます。 プライベート VLAN もパブリック VLAN もない場合は、ワーカー・プールにゾーンを追加すると、VLAN が自動的に作成されます。

    ibmcloud oc vlan ls --zone ZONE
    
  3. 各ゾーンについて、ワーカーノードで利用可能なフレーバーを確認してください。

    ibmcloud oc flavors --zone ZONE
    
  4. ワーカー・プールを作成します。 その他のオプションについては、CLI の資料を参照してください。

    • --label オプションを指定して、プール内のワーカー・ノードにラベル key=value を自動的に付けます。
    • ベアメタル・ワーカー・プールまたは専用 VM ワーカー・プールをプロビジョンする場合は、--hardware dedicated を指定します。
    • 新しいワーカー・ノードは、クラスター・マスターと同じ major.minor バージョンを実行しますが、その major.minor バージョンの最新のワーカー・ノード・パッチが適用されます。
    ibmcloud oc worker-pool create classic --name POOL_NAME --cluster CLUSTER_NAME_OR_ID --flavor FLAVOR --size-per-zone NUMBER_OF_WORKERS_PER_ZONE [--operating-system (REDHAT_8_64)] [--label key=value]
    
  5. ワーカー・プールが作成されたことを確認します。

    ibmcloud oc worker-pool ls --cluster CLUSTER_NAME_OR_ID
    
  6. デフォルトでは、ワーカー・プールを追加すると、ゾーンのないプールが作成されます。 ワーカー・ノードをゾーン内にデプロイするには、以前に取得したゾーンをワーカー・プールに追加する必要があります。 ワーカー・ノードを複数のゾーン間に分散させる場合は、ゾーンごとにこのコマンドを繰り返します。

    ibmcloud oc zone add classic --zone ZONE --cluster CLUSTER_NAME_OR_ID --worker-pool POOL_NAME --private-vlan PRIVATE_VLAN_ID --public-vlan PUBLIC_VLAN_ID
    
  7. 追加したゾーンにワーカー・ノードがプロビジョンされたことを確認します。 ステータスが「 provision_pending 」から「 normal 」に変われば、ワーカーノードの準備は完了です。

    ibmcloud oc worker ls --cluster CLUSTER_NAME_OR_ID --worker-pool POOL_NAME
    

    出力例

    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          provision_pending   Ready   dal10   1.36
    kube-dal10-crb20b637238ea471f8d4a8b881aae4962-w8   169.xx.xxx.xxx   10.xxx.xx.xxx   b3c.4x16          provision_pending   Ready   dal10   1.36
    

ワーカー・プールのサイズ変更

ワーカー・プールが 1 つのゾーンにあるか複数のゾーン間に分散しているかにかかわらず、既存のワーカー・プールのサイズを変更して、クラスター内のワーカー・ノードの数を追加したり減らしたりできます。

例えば、 1 つのワーカー・プールにゾーンあたり 3 つのワーカー・ノードがあるクラスターについて検討してみましょう。

  • クラスターが単一ゾーンで dal10 にある場合は、ワーカー・プールは dal10 内に 3 つのワーカー・ノードを持っています。 クラスターには合計で 3 つのワーカー・ノードがあります。
  • クラスターが複数ゾーンで dal10dal12 にある場合、ワーカー・プールは dal10 内に 3 つのワーカー・ノードと dal12 内に 3 つのワーカー・ノードを持っています。 クラスターには合計で 6 つのワーカー・ノードがあります。

ベア・メタル・ワーカー・プールの場合は、月単位で課金されることに留意してください。 サイズを変更して増減すると、その月のコストに影響します。 ワーカー・プールのサイズを変更してワーカー・ノードを追加すると、新しいワーカー・ノードでは、クラスター・マスターと同じ major.minor バージョンが実行されますが、その major.minor バージョンの最新のワーカー・ノード・パッチが実行されます。

作業を始める前に、 オペレーター または、 管理者 IAMプラットフォームのアクセスロール がインストールされていることを確認してください。

ワーカー・プールのサイズを変更するには、そのワーカー・プールが各ゾーン内にデプロイするワーカー・ノードの数を変更します。

  1. サイズ変更するワーカー・プールの名前を取得します。
    ibmcloud oc worker-pool ls --cluster CLUSTER_NAME_OR_ID
    
  2. 各ゾーン内にデプロイするワーカー・ノードの数を指定して、ワーカー・プールのサイズを変更します。
    ibmcloud oc worker-pool resize --cluster CLUSTER_NAME_OR_ID --worker-pool POOL_NAME --size-per-zone NUMBER_OF_WORKERS_PER_ZONE
    
  3. ワーカー・プールがサイズ変更されたことを確認します。
    ibmcloud oc worker ls --cluster CLUSTER_NAME_OR_ID --worker-pool POOL_NAME
    
    dal10dal12 の 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   dal10   1.36
    kube-dal10-crb20b637238ea471f8d4a8b881aae4962-w8   169.xx.xxx.xxx   10.xxx.xx.xxx   b3c.4x16          normal   Ready   dal10   1.36
    kube-dal12-crb20b637238ea471f8d4a8b881aae4962-w9   169.xx.xxx.xxx   10.xxx.xx.xxx   b3c.4x16          normal   Ready   dal12   1.36
    kube-dal12-crb20b637238ea471f8d4a8b881aae4962-w10  169.xx.xxx.xxx   10.xxx.xx.xxx   b3c.4x16          normal   Ready   dal12   1.36
    

ワーカー・プールへのゾーンの追加

ゾーンを既存のワーカー・プールに追加して、1 つのリージョン内の複数のゾーンにクラシック・クラスターを広げることができます。

ワーカー・プールにゾーンを追加すると、ワーカー・プールに定義されているワーカー・ノードが新しいゾーンにプロビジョンされ、将来のワークロード・スケジューリングの対象となります。 Red Hat OpenShift on IBM Cloud は、リージョンの failure-domain.beta.kubernetes.io/region ラベルとゾーンの failure-domain.beta.kubernetes.io/zone ラベルを各ワーカー・ノードに自動的に追加します。 Kubernetes スケジューラーは、これらのラベルを使用して、同じリージョン内のゾーン間にポッドを分散させます。

クラスター内に複数のワーカー・プールがある場合は、ワーカー・ノードがクラスター全体に均等に分散されるように、すべてのワーカー・プールにゾーンを追加します。 クラスターにワーカー・ノードを追加すると、新しいワーカー・ノードは、クラスター・マスターと同じ major.minor バージョンを実行しますが、その major.minor バージョンの最新のワーカー・ノード・パッチが適用されます。

始める前に

  • ワーカー・プールにゾーンを追加するには、そのワーカー・プールが複数ゾーン対応ゾーン内になければなりません。 ワーカー・プールが複数ゾーン対応ゾーン内にない場合は、新しいワーカー・プールを作成することを検討してください。
  • 「 [Operator or Administrator IAM platform access role] 」(/docs/openshift?topic=openshift-iam-platform-access-roles)が設定されていることを確認してください。
  • クラシック・クラスターで、1 つのクラスターに複数の VLAN がある場合、同じ VLAN 上に複数のサブネットがある場合、または複数ゾーン・クラシック・クラスターである場合は、IBM Cloud インフラストラクチャー・アカウントの仮想ルーター機能 (VRF) を有効にして、ワーカー・ノードがプライベート・ネットワーク上で相互に通信できるようにする必要があります。 VRF を有効にするには、VRF の有効化を参照してください。 VRF が既に有効になっているかどうかを確認するには、ibmcloud account show コマンドを使用します。 VRF を有効にできない、または有効にしない場合は、VLAN スパンニングを有効にします。 この操作を実行するには、「 ネットワーク > ネットワークのVLANスパンニングの管理 」のインフラストラクチャ権限が必要です。または、 アカウント所有者にこの権限を有効にするよう依頼することもできます。 VLANスパンニングがすでに有効になっているかどうかを確認するには、 ibmcloud oc vlan spanning get --region <region> コマンド を使用します。

ゾーンをワーカー・ノードと一緒にワーカー・プールに追加するには、次のようにします。

  1. 使用可能なゾーンをリストし、ワーカー・プールに追加するゾーンを選びます。 複数ゾーン対応ゾーンを選ばなければなりません。

    ibmcloud oc zone ls
    
  2. そのゾーン内の使用可能な VLAN をリストします。 プライベート VLAN もパブリック VLAN もない場合は、ワーカー・プールにゾーンを追加すると、VLAN が自動的に作成されます。

    ibmcloud oc vlan ls --zone ZONE
    
  3. クラスター内のワーカー・プールをリストし、それらの名前をメモします。

    ibmcloud oc worker-pool ls --cluster CLUSTER_NAME_OR_ID
    
  4. ゾーンをワーカー・プールに追加します。 ワーカー・プールが複数ある場合は、すべてのゾーンでクラスターのバランスが取れるように、すべてのワーカー・プールにゾーンを追加してください。

    複数のワーカー・プールにゾーンを追加するには、その前にプライベート VLAN とパブリック VLAN がなければなりません。 そのゾーンにプライベート VLAN とパブリック VLAN がない場合は、最初にゾーンを 1 つのワーカー・プールに追加して、プライベート VLAN とパブリック VLAN が作成されるようにします。 その後、作成されたプライベート VLAN とパブリック VLAN を指定して、他のワーカー・プールにゾーンを追加できます。

    ワーカー・プールごとに別の VLAN を使用する場合は、このコマンドを VLAN とその対応するワーカー・プールごとに繰り返します。 指定した VLAN に新しいワーカー・ノードが追加されますが、既存のワーカー・ノードの VLAN は変更されません。

    ibmcloud oc zone add classic --zone ZONE --cluster CLUSTER_NAME_OR_ID -p POOL_NAME [-p POOL2_NAME] --private-vlan PRIVATE_VLAN_ID --public-vlan PUBLIC_VLAN_ID
    
  5. ゾーンがクラスターに追加されたことを確認します。 出力の Worker Zones フィールドに、追加したゾーンが表示されるか確認します。 追加したゾーンに新しいワーカー・ノードがプロビジョンされたため、Workers フィールド内のワーカーの合計数が増えていることに注意してください。

    ibmcloud oc cluster get --cluster CLUSTER_NAME_OR_ID
    

    出力例

    NAME:                           mycluster
    ID:                             df253b6025d64944ab99ed63bb4567b6
    State:                          normal
    Status:                         healthy cluster
    Created:                        2018-09-28T15:43:15+0000
    Location:                       dal10
    Pod Subnet:                     172.30.0.0/16
    Service Subnet:                 172.21.0.0/16
    Master URL:                     https://c3.<region>.containers.cloud.ibm.com:30426
    Public Service Endpoint URL:    https://c3.<region>.containers.cloud.ibm.com:30426
    Private Service Endpoint URL:   https://c3-private.<region>.containers.cloud.ibm.com:31140
    Master Location:                Dallas
    Master Status:                  Ready (21 hours ago)
    Ingress Subdomain:              mycluster-<hash>-0000.us-south.containers.appdomain.cloud
    Ingress Secret:                 mycluster-<hash>-0000
    Workers:                        6
    Worker Zones:                   dal10, dal12
    Version:                        1.36_1524
    Owner:                          owner@email.com
    Resource Group ID:              a8a12accd63b437bbd6d58fb6a462ca7
    Resource Group Name:            Default