ノード・プールの追加によるクラスタのスケール・アップ

Container Engine for Kubernetes (OKE)を使用してノード・プールを追加してクラスタをスケール・アップする方法を確認します。

コンソール、CLIおよびAPIを使用してノード・プールを追加することで、クラスタをスケール・アップできます。

コンソールを使用してクラスタ内のノード・プールの数を増やして既存のクラスタをスケール・アップするには:
1. ナビゲーション・メニューを開き、「開発者サービス」をクリックします。「コンテナとアーティファクト」で、「Kubernetesクラスタ(OKE)」をクリックします。
2. 作業する権限があるコンパートメントを選択します。
3. 「クラスタ・リスト」ページで、変更するクラスタの名前をクリックします。
4. 「リソース」で、「ノード・プール」をクリックします。
5. 「ノード・プールの追加」ボタンをクリックし、ノード・プールを追加してクラスタをスケール・アップします。
6. 新しいノード・プールの詳細を入力します。
  
  名前: 新しいノード・プールに選択した名前。機密情報の入力は避けてください。
  
  コンパートメント:新しいノード・プールを作成するコンパートメント。
  
  ノード・タイプ:クラスタのネットワーク・タイプがVCNネイティブ・ポッド・ネットワーキングの場合は、このノード・プールのワーカー・ノードのタイプを指定します(仮想ノードおよび管理対象ノードを参照)。次のいずれかのオプションを選択します:
  
  管理: ノード・プールのワーカー・ノードを管理する場合は、このオプションを選択します。テナンシ内のコンピュート・インスタンス(ベア・メタルまたは仮想マシン)で実行される管理対象ノード。管理対象ノードの管理はユーザーが担当しているため、特定の要件を満たすように柔軟に構成できます。管理対象ノードでKubernetesをアップグレードし、クラスタ容量を管理する責任があります。
  
  仮想: サーバーレスなKubernetesエクスペリエンスのメリットを得るには、このオプションを選択します。仮想ノードを使用すると、データ・プレーン・インフラストラクチャのアップグレードおよびクラスタの容量の管理の運用オーバーヘッドなしで、Kubernetesポッドを大規模に実行できます。
  
  詳細は、「仮想ノードと管理対象サーバーとの比較」を参照してください。
  
  バージョン: (管理対象ノード・プールのみ)管理対象ノード・プール内の各管理対象ノードで実行されるKubernetesのバージョン。デフォルトでは、コントロール・プレーン・ノードに指定されたKubernetesのバージョンが選択されます。ワーカー・ノードのKubernetesバージョンは、コントロール・プレーン・ノードのバージョンと同じであるか、まだ互換性のある以前のバージョンである必要があります。KubernetesのバージョンとContainer Engine for Kubernetesを参照してください。
  
  ワーカー・ノードにOKEイメージを指定する場合、ここで選択するKubernetesバージョンはOKEイメージのKubernetesのバージョンと同じである必要があります。
7. クラスタのネットワーク・タイプがVCNネイティブ・ポッド・ネットワーキングで、「ノード・タイプ」として「管理対象」を選択した場合、またはクラスタのネットワーク・タイプが「チャネル・オーバーレイ」の場合:
  
  管理対象ノード・プールの構成の詳細を指定します:
  
  ノード配置構成:
  
  可用性ドメイン:ワーカー・ノードを配置する可用性ドメイン。
  
  ワーカー・ノード・サブネット:ワーカー・ノードをホストするように構成されたリージョン・サブネット(推奨)またはAD固有のサブネット。ロード・バランサ・サブネットを指定した場合、ワーカー・ノード・サブネットは異なる必要があります。指定するサブネットは、プライベート(推奨)またはパブリックです。サブネットの構成を参照してください。
  
  フォルト・ドメイン: (オプション)ワーカー・ノードを配置する可用性ドメイン内の1つ以上のフォルト・ドメイン。
  
  オプションで、「拡張オプションの表示」をクリックして、使用する容量タイプを指定します(「ワーカー・ノードの容量タイプの管理」を参照)。容量予約を指定する場合は、ノード・プールの配置構成のノード・シェイプ、可用性ドメインおよびフォルト・ドメインが、それぞれ容量予約のインスタンス・タイプ、可用性ドメインおよびフォルト・ドメインと一致していることを確認してください。容量予約を使用した管理対象ノードのプロビジョニングを参照してください。
  オプションで「別の行」をクリックして、ワーカー・ノードを配置する追加のドメインおよびサブネットを選択します。
  ワーカー・ノードは、作成されると、選択した可用性ドメインおよびフォルト・ドメインで可能なかぎり均等に分散されます。特定のアベイラビリティ・ドメインにフォルト・ドメインを選択しない場合、ワーカー・ノードは、そのアベイラビリティ・ドメイン内のすべてのフォルト・ドメインで可能なかぎり均等に分散されます。
  
  ノード・シェイプ: ノード・プールのワーカー・ノードに使用するシェイプ。シェイプによって、各ノードに割り当てるCPU数とメモリー量が決まります。
  
  Container Engine for Kubernetesでサポートされているテナンシで使用可能なシェイプのみが表示されます。
  
  フレキシブル・シェイプを選択した場合は、CPUの数とメモリー量を明示的に指定できます。
  
  「ワーカー・ノードにサポートされているイメージ(カスタム・イメージを含む)およびシェイプ」を参照してください。
  
  イメージ: ノード・プールのワーカー・ノードで使用するイメージ。イメージは、オペレーティング・システムとその他のノード用ソフトウェアを決定する仮想ハード・ドライブのテンプレートです。
  
  デフォルト・イメージを変更するには、「イメージの変更」をクリックします。「すべてのイメージの参照」ウィンドウで、「イメージ・ソース」を選択し、次のようにイメージを選択します。
  
  OKEワーカー・ノードのイメージ: 推奨。Oracleによって提供され、プラットフォーム・イメージの上に構築されます。OKEイメージは、必要なすべての構成および必要なソフトウェアを使用して、ワーカー・ノードのベース・イメージとして機能するように最適化されています。プラットフォーム・イメージおよびカスタム・イメージと比較して、実行時にワーカー・ノードのプロビジョニングにかかる時間を最小限に抑える場合は、OKEイメージを選択します。
  
  OKEイメージ名には、含まれているKubernetesバージョンのバージョン番号が含まれます。ノード・プールのKubernetesバージョンを指定する場合、ここで選択するOKEイメージのバージョン番号は、ノード・プールのKubernetesバージョンと同じである必要があります。
  
  プラットフォーム・イメージ: Oracleによって提供され、Oracle Linuxオペレーティング・システムのみが含まれます。Container Engine for Kubernetesで、ワーカー・ノードをホストするコンピュート・インスタンスが初めて起動したときに必要なソフトウェアをダウンロード、インストールおよび構成する場合は、プラットフォーム・イメージを選択します。
  
  「ワーカー・ノードにサポートされているイメージ(カスタム・イメージを含む)およびシェイプ」を参照してください。
  
  ノード数:選択したアベイラビリティ・ドメイン、および各アベイラビリティ・ドメインに指定したリージョン・サブネット(推奨)またはAD固有のサブネットに配置される、ノード・プールに作成するワーカー・ノードの数。
  
  ネットワーク・セキュリティ・グループ(NSG)内のセキュリティ・ルールの使用:指定した1つ以上のネットワーク・セキュリティ・グループ(NSG)に対して定義されたセキュリティ・ルール(最大5つ)を使用して、ノード・プールへのアクセスを制御します。NSGに対して定義されたセキュリティ・ルールは、セキュリティ・リストに対して定義されたセキュリティ・ルールではなく、またはセキュリティ・リストに対して定義されたセキュリティ・ルールも使用できます(NSGを推奨)。NSGに指定するセキュリティ・ルールの詳細は、ワーカー・ノードのセキュリティ・ルールを参照してください。
  
  ブート・ボリューム: ワーカー・ノードのブート・ボリュームのサイズと暗号化オプションを構成します:
  
  ブート・ボリュームのカスタム・サイズを指定するには、「カスタム・ブート・ボリューム・サイズを指定します」チェック・ボックスを選択します。次に、カスタム・サイズを50GBから32TBの範囲で入力します。指定するサイズは、選択したイメージのデフォルトのブート・ボリューム・サイズより大きくする必要があります。詳細は、カスタム・ブート・ボリュームのサイズを参照してください。
  ブート・ボリューム・サイズを増やす場合は、より大きなサイズを利用するために、ブート・ボリューム(ルート・パーティション)のパーティションも拡張する必要があることに注意してください。ブート・ボリュームのパーティションの拡張を参照してください。Oracle Linuxプラットフォーム・イメージには、oci-utilsパッケージが含まれています。カスタムcloud-initスクリプトでそのパッケージからoci-growfsコマンドを使用して、ルート・パーティションを拡張し、ファイル・システムを拡張できます。詳細は、ワーカー・ノードのルート・パーティションの拡張を参照してください。
  
  VMインスタンスの場合は、必要に応じて「転送中暗号化の使用」チェック・ボックスを選択できます。移動中暗号化をサポートするベア・メタル・インスタンスの場合、これはデフォルトで有効であり、構成できません。転送中暗号化の詳細は、転送中暗号化を参照してください。ブート・ボリュームで独自のボールト・サービス暗号化キーを使用している場合、このキーが転送中暗号化にも使用されます。それ以外の場合は、Oracle提供の暗号化キーが使用されます。
  
  ブート・ボリュームはデフォルトで暗号化されますが、オプションで独自のボールト・サービス暗号化キーを使用してこのボリュームのデータを暗号化できます。暗号化のニーズにVaultサービスを使用するには、「管理するキーでこのボリュームを暗号化します」チェック・ボックスを選択します。使用するマスター暗号化キーを含むボールト・コンパートメントおよびボールトを選択し、マスター暗号化キー・コンパートメントおよびマスター暗号化キーを選択します。このオプションを有効にすると、このキーが保存データの暗号化と転送中データの暗号化の両方に使用されます。
  重要
  
  ブロック・ボリューム・サービスでは、Rivest-Shamir-Adleman (RSA)アルゴリズムを使用して暗号化されたキーを使用したボリュームの暗号化はサポートされていません。独自のキーを使用する場合は、Advanced Encryption Standard (AES)アルゴリズムを使用して暗号化されたキーを使用する必要があります。これは、ブロック・ボリュームおよびブート・ボリュームに適用されます。
  
  独自のVaultサービス暗号化キーを使用してデータを暗号化するには、IAMポリシーによってサービス暗号化キーへのアクセス権が付与される必要があることに注意してください。ブート・ボリューム、ブロック・ボリュームまたはファイル・システム(あるいはその両方)を暗号化するためのユーザー管理暗号化キーにアクセスするポリシーの作成を参照してください。
  
  ポッド通信:クラスタのネットワーク・タイプがVCNネイティブ・ポッド・ネットワーキングの場合、ノード・プール内のポッドがポッド・サブネットを使用して相互に通信する方法を指定します:
  
  サブネット:ポッドをホストするように構成されたリージョナル・サブネット。指定するサブネットは、パブリックでもプライベートでもかまいません。場合によっては、ワーカー・ノード・サブネットとポッド・サブネットが同じサブネットになることがあります(その場合、Oracleではセキュリティ・リストではなくネットワーク・セキュリティ・グループにセキュリティ・ルールを定義することをお薦めします)。サブネットの構成を参照してください。
  
  ネットワーク・セキュリティ・グループ(NSG)のセキュリティ・ルールの使用:指定した1つ以上のネットワーク・セキュリティ・グループ(NSG)に定義されたセキュリティ・ルール(最大5つ)を使用して、ポッド・サブネットへのアクセスを制御します。NSGに対して定義されたセキュリティ・ルールは、セキュリティ・リストに対して定義されたセキュリティ・ルールではなく、またはセキュリティ・リストに対して定義されたセキュリティ・ルールも使用できます(NSGを推奨)。NSGに指定するセキュリティ・ルールの詳細は、ワーカー・ノードおよびポッドのセキュリティ・ルールを参照してください。
  
  オプションで、「拡張オプションの表示」をクリックして、ノード・プール内の1つのワーカー・ノードで実行するポッドの最大数(最大110)を指定します。Kubernetesによって110の制限が課されます。1つのワーカー・ノードに31個を超えるポッドが必要な場合は、ノード・プールに指定するシェイプで3つ以上のVNIC (ワーカー・ノード・サブネットに接続するための1つのVNICと、ポッド・サブネットに接続するための2つ以上のVNIC)をサポートする必要があります。「異なるシェイプでサポートされるVNICおよびポッドの最大数」を参照してください。
  ポッド通信の詳細は、ポッド・ネットワーキングを参照してください。
  
  拡張ノード・プール・オプションのデフォルトを受け入れるか、「拡張オプションの表示」を選択して、次のように代替を指定します:
  
  コードンおよびドレイン:ワーカー・ノードを終了する前に、いつ、どのようにコードンおよびドレインするかを指定します。
  
  削除猶予期間(分):ワーカー・ノードを終了する前に、ノードをコードンおよびドレインできる時間の長さ。デフォルト(60分)を受け入れるか、代替を指定します。たとえば、ノード・プールのスケール・ダウンや配置構成の変更時に、ワーカー・ノードを30分間コード化してワークロードを排出できます。ワーカー・ノードをコード化およびドレインせずにただちに終了するには、0分を指定します。
  
  猶予期間後に強制終了:正常にコード化およびドレインされていない場合でも、削除猶予期間の終了時にワーカー・ノードを終了するかどうか。デフォルトでは、このオプションは選択されていません。
  ワーカー・ノードが正常にコード化およびドレインされていない場合でも、削除猶予期間の終了時に常にワーカー・ノードを終了させる場合は、このオプションを選択します。
  正常にコード化されて排出されていないワーカー・ノードを削除猶予期間の終了時に終了させない場合は、このオプションの選択を解除します。削除猶予期間内に終了できないワーカー・ノードを含むノード・プールは、「注意が必要」ステータスになります。終了操作を開始した作業リクエストのステータスが「失敗」に設定され、終了操作が取り消されます。詳細は、クラスタのモニタリングを参照してください。
  
  詳細は、終了前の管理対象ノードのコード化およびドレインに関するノートを参照してください。
  
  初期化スクリプト: (オプション)インスタンスが初めて起動したときにワーカー・ノードをホストする各インスタンスでcloud-initを実行するスクリプト。指定するスクリプトは、cloud-initでサポートされている形式(cloud-configなど)のいずれかで記述する必要があり、サポートされているファイル・タイプ(.yamlなど)である必要があります。スクリプトを次のように指定します。
  
  Cloud-Initスクリプトの選択: cloud-initスクリプトを含むファイルを選択するか、ファイルをボックスにドラッグ・アンド・ドロップします。
  
  Cloud-Initスクリプトの貼付け: cloud-initスクリプトの内容をコピーして、ボックスに貼り付けます。
  
  Container Engine for Kubernetesによって作成されたクラスタでワーカー・ノードを初期化するためのcloud-initスクリプトを以前に記述していない場合は、「カスタムCloud-Initスクリプト・テンプレートのダウンロード」をクリックすることが役立つ場合があります。ダウンロードしたファイルには、Container Engine for Kubernetesによって提供されるデフォルトのロジックが含まれています。独自のカスタム・ロジックは、デフォルト・ロジックの前または後に追加できますが、デフォルト・ロジックは変更しないでください。例については、カスタムCloud-initスクリプトのユースケースの例を参照してください。
  
  Kubernetesラベル: (オプション) (デフォルト・ラベルに加えて)ノード・プールのワーカー・ノードに追加するための1つ以上のラベル。特定のノード・プールでワークロードをターゲットに設定できるようになります。たとえば、ノード・プール内のすべてのノードをロード・バランサ・バックエンド・セット内のバックエンド・サーバーのリストから除外するには、node.kubernetes.io/exclude-from-external-load-balancers=trueを指定します(node.kubernetes.io/exclude-from-external-load-balancersを参照)。
  
  ノード・プール・タグおよびノード・タグ: (オプション)ノード・プールに追加する1つ以上のタグ、およびノード・プール内のワーカー・ノードをホストするコンピュート・インスタンス。タグ付けを使用すると、コンパートメント間で異なるリソースをグループ化でき、独自のメタデータでリソースに注釈を付けることもできます。Kubernetesクラスタ関連リソースのタグ付けを参照してください。
  
  公開SSHキー: (オプション)ノード・プールの各ノードへのSSHアクセスに使用するキー・ペアの公開キー部分。公開キーは、クラスタ内のすべてのワーカー・ノードにインストールされます。公開SSHキーを指定しない場合、Container Engine for Kubernetesによって提供されることに注意してください。ただし、対応する秘密キーがないため、ワーカー・ノードへのSSHアクセスはできません。SSHを使用して、プライベート・サブネットのワーカー・ノードに直接アクセスすることはできません(SSHを使用したプライベート・サブネットの管理対象ノードへの接続を参照)。
8. 「ノード・タイプ」として「仮想」を選択した場合:
  
  仮想ノード・プールの構成詳細を指定します:
  
  ノード数:選択した可用性ドメイン、および各可用性ドメインに指定したリージョン・サブネット(推奨)またはAD固有のサブネットに配置される、仮想ノード・プールに作成する仮想ノードの数。
  
  ポッド・シェイプ: 仮想ノード・プール内の仮想ノードで実行されているポッドに使用するシェイプ。シェイプによって、ポッドを実行するプロセッサ・タイプが決まります。
  
  Container Engine for Kubernetesでサポートされているテナンシで使用可能なシェイプのみが表示されます。「ワーカー・ノードにサポートされているイメージ(カスタム・イメージを含む)およびシェイプ」を参照してください。
  
  ポッド仕様では、仮想ノードのCPUおよびメモリー・リソース要件を明示的に指定します(Kubernetesドキュメントのコンテナおよびポッドへのメモリー・リソースの割当ておよびコンテナおよびポッドへのCPUリソースの割当てを参照)。
  
  ポッド通信:仮想ノードで実行されているポッドは、VCNネイティブ・ポッド・ネットワーキングを使用します。ノード・プール内のポッドがポッド・サブネットを使用して相互に通信する方法を指定します:
  
  サブネット:ポッドをホストするように構成されたリージョナル・サブネット。仮想ノードに指定するポッド・サブネットはプライベートである必要があります。ポッド・サブネットと仮想ノード・サブネットは同じサブネットであることをお薦めします(その場合、Oracleではセキュリティ・リストではなくネットワーク・セキュリティ・グループにセキュリティ・ルールを定義することをお薦めします)。サブネットの構成を参照してください。
  
  ネットワーク・セキュリティ・グループ(NSG)のセキュリティ・ルールの使用:指定した1つ以上のネットワーク・セキュリティ・グループ(NSG)に定義されたセキュリティ・ルール(最大5つ)を使用して、ポッド・サブネットへのアクセスを制御します。NSGに対して定義されたセキュリティ・ルールは、セキュリティ・リストに対して定義されたセキュリティ・ルールではなく、またはセキュリティ・リストに対して定義されたセキュリティ・ルールも使用できます(NSGを推奨)。NSGに指定するセキュリティ・ルールの詳細は、ワーカー・ノードおよびポッドのセキュリティ・ルールを参照してください。
  
  ポッド通信の詳細は、ポッド・ネットワーキングを参照してください。
  
  仮想ノード通信:
  
  サブネット:仮想ノードをホストするように構成されたリージョン別サブネット(推奨)またはAD固有のサブネット。ロード・バランサ・サブネットを指定した場合、仮想ノード・サブネットは異なる必要があります。指定するサブネットは、プライベート(推奨)またはパブリックにすることも、リージョン(推奨)またはAD固有にすることもできます。ポッド・サブネットと仮想ノード・サブネットは同じサブネット(その場合、仮想ノード・サブネットはプライベートである必要があります)であることをお薦めします。サブネットの構成を参照してください。
  
  ノード配置構成:
  
  可用性ドメイン:仮想ノードを配置する可用性ドメイン。
  
  フォルト・ドメイン: (オプション)仮想ノードを配置する可用性ドメイン内の1つ以上のフォルト・ドメイン。
  
  オプションで、「別の行」をクリックして、仮想ノードを配置する追加のドメインおよびサブネットを選択します。
  仮想ノードは、作成されると、選択した可用性ドメインおよびフォルト・ドメイン全体で可能なかぎり均等に分散されます。特定のアベイラビリティ・ドメインにフォルト・ドメインを選択しない場合、仮想ノードは、そのアベイラビリティ・ドメイン内のすべてのフォルト・ドメインで可能なかぎり均等に分散されます。
  
  拡張仮想ノード・プール・オプションのデフォルトを受け入れるか、「拡張オプションの表示」をクリックして、次のように代替を指定します:
  
  ノード・プール・タグ: (オプション)仮想ノード・プールに追加する1つ以上のタグ。タグ付けを使用すると、コンパートメント間で異なるリソースをグループ化でき、独自のメタデータでリソースに注釈を付けることもできます。Kubernetesクラスタ関連リソースのタグ付けを参照してください。
  
  Kubernetesラベルおよび色合い: (オプション)仮想ノードにラベルおよび色合いを追加して、特定のノード・プールでのワークロードのターゲット設定を有効にします:
  
  ラベル: (デフォルト・ラベルに加えて)仮想ノード・プールの仮想ノードに追加するための1つ以上のラベル。特定のノード・プールでワークロードをターゲットに設定できるようになります。
  
  Taints: 仮想ノード・プール内の仮想ノードに追加する1つ以上の色合い。Taintsを使用すると、仮想ノードがポッドを再ペルできるため、特定の仮想ノード・プール内の仮想ノードでポッドが実行されません。タイントは仮想ノードにのみ適用できます。
  
  詳細は、Kubernetesのドキュメントのノードへのポッドの割当てを参照してください。
9. 「追加」をクリックし、新しいノード・プールを作成します。
管理対象ノード・プールを追加してクラスタをスケール・アップするには、oci ce node-pool createコマンドと必要なパラメータを使用します:
oci ce node-pool create --cluster-id <cluster-ocid> --compartment-id <compartment-ocid> --name <node-pool-name> --node-shape <shape>
仮想ノード・プールを追加してクラスタをスケール・アップするには、oci ce virtual-node-pool createコマンドおよび必須パラメータを使用します:
oci ce virtual-node-pool create \ --cluster-id <cluster-ocid> \ --compartment-id <compartment-ocid> \ --display-name <node-pool-name> \ --kubernetes-version <kubernetes-version> \ --placement-configurations "[{\"availabilityDomain\":\"<ad-name>\",\"faultDomain\":[\"FAULT-DOMAIN-<n>\"],\"subnetId\":\"<virtualnode-subnet-ocid>\"}]" \ --nsg-ids "[\"<virtual-node-nsg-ocid>\"]" \ --pod-configuration "{\"subnetId\":\"<pod-subnet-ocid>\",\"nsgIds\":[\"<pod-nsg-ocid>\"],\"shape\":\"<shape-name>\"}" \ --size <number-of-nodes>
ここでは:

<ad-name>は、仮想ノードを配置する可用性ドメインの名前です。使用する可用性ドメイン名を確認するには、次を実行します:
oci iam availability-domain list

<shape-name>は、Pod.Standard.E3.Flex、Pod.Standard.E4.Flexのいずれかです。
CLIコマンドのパラメータおよび値の完全なリストは、CLIコマンド・リファレンスを参照してください。
CreateNodePool操作を実行して、管理対象ノード・プールを追加してクラスタをスケール・アップします。

CreateVirtualNodePool操作を実行して、仮想ノード・プールを追加してクラスタをスケール・アップします。

Oracle Cloud Infrastructureドキュメント

ノード・プールの追加によるクラスタのスケール・アップ