ノード・プールの更新

Container Engine for Kubernetes (OKE)を使用して管理対象ノード・プールを更新する方法を確認します。

ノード・プールの更新に関する一般情報は、ノード・プールおよびワーカー・ノード・プロパティの変更を参照してください。

既存のKubernetesクラスタのノード・プールおよびワーカー・ノードのプロパティを変更するには:
1. ナビゲーション・メニューを開き、「開発者サービス」をクリックします。「コンテナとアーティファクト」で、「Kubernetesクラスタ(OKE)」をクリックします。
2. クラスタを含むコンパートメントを選択します。
3. 「クラスタ・リスト」ページで、変更するクラスタの名前をクリックします。
4. 「クラスタ詳細」ページの「リソース」で、「ノード・プール」をクリックします。
5. 変更するノード・プールの名前をクリックします。
6. 「ノード・プールの詳細」タブを使用して、次のようなノード・プールに関する情報を表示します:
  
  ノード・プールのステータス。
  
  ノード・プールのOCID。
  
  ノード・プール内のワーカー・ノードのタイプ(管理対象または仮想)。
  
  ノード・プール内の新規ワーカー・ノードの起動時に現在使用されている構成。次のものが含まれます:
  
  ワーカー・ノードで実行するKubernetesのバージョン
  
  ワーカー・ノードに使用するシェイプ
  
  ワーカー・ノードで使用するイメージ
  
  可用性ドメイン、フォルト・ドメイン、およびワーカー・ノードをホストする様々なリージョン・サブネット(推奨)またはAD固有のサブネット。
  
  ノード・プール内のワーカー・ノードのタイプ(管理対象または仮想)によって、変更できるノード・プールおよびワーカー・ノード・プロパティが決まります。
7. (オプション)管理対象ノード・プールおよび管理対象ノードの場合は、次のようにプロパティを変更します。
  
  「編集」をクリックし、次を指定します:
  
  名前: ノード・プールの別の名前。機密情報の入力は避けてください。
  
  バージョン: インプレース・アップグレードの実行時にノード・プール内の新しいワーカー・ノードで実行する別のバージョンのKubernetes。ワーカー・ノード上のKubernetesバージョンは、コントロール・プレーン・ノード上のバージョンと同じであるか、まだ互換性のある以前のバージョンである必要があります(KubernetesのバージョンとContainer Engine for Kubernetesを参照)。
  
  ワーカー・ノードにOKEイメージを指定する場合、ここで選択するKubernetesバージョンはOKEイメージのKubernetesのバージョンと同じである必要があります。
  
  指定したKubernetesバージョンを実行している新しいワーカー・ノードを起動するには、ノード・プール内の既存のワーカー・ノードをドレインし(新しいポッドが開始されないようにし、既存のポッドを削除するため)、既存の各ワーカー・ノードを順番に終了します。
  
  アウトオブプレース・アップグレードを実行して、新しいワーカー・ノードで実行する別のバージョンのKubernetesを指定することもできます。ワーカー・ノードのアップグレードの詳細は、新しいKubernetesバージョンへの管理対象ノードのアップグレードを参照してください。
  
  ノード数:ノード・プール内の異なるノード数。「ノード・プールのスケーリング」を参照してください。
  
  ノード配置構成:
  
  可用性ドメイン:ワーカー・ノードを配置する可用性ドメイン。
  
  ワーカー・ノード・サブネット:ワーカー・ノードをホストするように構成されたリージョン・サブネット(推奨)またはAD固有のサブネット。ロード・バランサ・サブネットを指定した場合、ワーカー・ノード・サブネットは異なる必要があります。指定するサブネットは、プライベート(推奨)またはパブリックです。サブネットの構成を参照してください。
  
  フォルト・ドメイン: (オプション)ワーカー・ノードを配置する可用性ドメイン内の1つ以上のフォルト・ドメイン。
  
  オプションで、「拡張オプションの表示」をクリックして、使用する容量タイプを指定します(「ワーカー・ノードの容量タイプの管理」を参照)。容量予約を指定する場合、管理対象ノード・プールの配置構成のノード・シェイプ、可用性ドメインおよびフォルト・ドメインは、それぞれ容量予約のインスタンス・タイプ、可用性ドメインおよびフォルト・ドメインと一致する必要があります。容量予約を使用した管理対象ノードのプロビジョニングを参照してください。
  オプションで「別の行」をクリックして、ワーカー・ノードを配置する追加のドメインおよびサブネットを選択します。
  ワーカー・ノードは、作成されると、選択した可用性ドメインおよびフォルト・ドメインで可能なかぎり均等に分散されます。特定のアベイラビリティ・ドメインにフォルト・ドメインを選択しない場合、ワーカー・ノードは、そのアベイラビリティ・ドメイン内のすべてのフォルト・ドメインで可能なかぎり均等に分散されます。
  
  ノード・シェイプ: ノード・プール内のワーカー・ノードに使用する別のシェイプ。シェイプによって、各ノードに割り当てるCPU数とメモリー量が決まります。
  
  Container Engine for Kubernetesでサポートされているテナンシで使用可能なシェイプのみが表示されます。
  
  フレキシブル・シェイプを選択した場合は、CPUの数とメモリー量を明示的に指定できます。
  
  「ワーカー・ノードにサポートされているイメージ(カスタム・イメージを含む)およびシェイプ」を参照してください。
  
  イメージ: ノード・プールのワーカー・ノードで使用する別のイメージ。イメージは、オペレーティング・システムとその他のノード用ソフトウェアを決定する仮想ハード・ドライブのテンプレートです。
  
  イメージを変更するには、「イメージの変更」をクリックします。「すべてのイメージの参照」ウィンドウで、「イメージ・ソース」を選択し、次のようにイメージを選択します。
  
  OKEワーカー・ノードのイメージ: 推奨。Oracleによって提供され、プラットフォーム・イメージの上に構築されます。OKEイメージは、必要なすべての構成および必要なソフトウェアを使用して、ワーカー・ノードのベース・イメージとして機能するように最適化されています。プラットフォーム・イメージおよびカスタム・イメージと比較して、実行時にワーカー・ノードのプロビジョニングにかかる時間を最小限に抑える場合は、OKEイメージを選択します。
  
  OKEイメージ名には、含まれているKubernetesバージョンのバージョン番号が含まれます。ノード・プールのKubernetesバージョンを指定する場合、ここで選択するOKEイメージのバージョン番号は、ノード・プールのKubernetesバージョンと同じである必要があります。
  
  プラットフォーム・イメージ: Oracleによって提供され、Oracle Linuxオペレーティング・システムのみが含まれます。Container Engine for Kubernetesで、ワーカー・ノードをホストするコンピュート・インスタンスが初めて起動したときに必要なソフトウェアをダウンロード、インストールおよび構成する場合は、プラットフォーム・イメージを選択します。
  
  「ワーカー・ノードにサポートされているイメージ(カスタム・イメージを含む)およびシェイプ」を参照してください。
  
  ネットワーク・セキュリティ・グループ(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ではセキュリティ・リストではなくネットワーク・セキュリティ・グループにセキュリティ・ルールを定義することをお薦めします)。サブネットの構成を参照してください。
  
  ネットワーク・セキュリティ・グループ:指定した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を参照)。
  
  公開SSHキー: (オプション)ノード・プール内のノードへのSSHアクセスに使用するキー・ペアの別の公開キー部分。公開キーは、クラスタ内のすべてのワーカー・ノードにインストールされます。公開SSHキーを指定しない場合、Container Engine for Kubernetesによって提供されることに注意してください。ただし、対応する秘密キーがないため、ワーカー・ノードへのSSHアクセスはできません。SSHを使用して、プライベート・サブネットのワーカー・ノードに直接アクセスすることはできません(SSHを使用したプライベート・サブネットの管理対象ノードへの接続を参照)。
  
  「Save Changes」をクリックして、更新されたプロパティを保存します。
8. (オプション)仮想ノード・プールおよび仮想ノードの場合は、次のようにプロパティを変更します:
  
  「編集」をクリックし、次を指定します:
  
  名前: ノード・プールの別の名前。機密情報の入力は避けてください。
  
  ノード数:選択した可用性ドメイン、および各可用性ドメインに指定したリージョナル・サブネット(推奨)またはAD固有のサブネットに配置される、仮想ノード・プールに作成する異なる数の仮想ノード。「ノード・プールのスケーリング」を参照してください。
  
  ノード配置構成:
  
  可用性ドメイン:仮想ノードを配置する可用性ドメイン。
  
  フォルト・ドメイン: (オプション)仮想ノードを配置する可用性ドメイン内の1つ以上のフォルト・ドメイン。
  
  オプションで、「別の行」をクリックして、仮想ノードを配置するドメインおよびサブネットをさらに選択します。
  仮想ノードは、作成されると、選択した可用性ドメインおよびフォルト・ドメイン全体で可能なかぎり均等に分散されます。特定のアベイラビリティ・ドメインにフォルト・ドメインを選択しない場合、仮想ノードは、そのアベイラビリティ・ドメイン内のすべてのフォルト・ドメインで可能なかぎり均等に分散されます。
  
  仮想ノード通信:
  
  サブネット:仮想ノードをホストするように構成された異なるリージョン別サブネット(推奨)またはAD固有のサブネット。ロード・バランサ・サブネットを指定した場合、仮想ノード・サブネットは異なる必要があります。指定するサブネットは、プライベート(推奨)またはパブリックにすることも、リージョン(推奨)またはAD固有にすることもできます。ポッド・サブネットと仮想ノード・サブネットは同じサブネット(その場合、仮想ノード・サブネットはプライベートである必要があります)であることをお薦めします。詳細については、Subnet Configurationを参照してください。
  
  ネットワーク・セキュリティ・グループ(NSG)内のセキュリティ・ルールの使用:指定した1つ以上のネットワーク・セキュリティ・グループ(NSG)に対して定義されたセキュリティ・ルール(最大5つ)を使用して、仮想ノード・サブネットへのアクセスを制御します。NSGに対して定義されたセキュリティ・ルールは、セキュリティ・リストに対して定義されたセキュリティ・ルールではなく、またはセキュリティ・リストに対して定義されたセキュリティ・ルールも使用できます(NSGを推奨)。NSGに指定するセキュリティ・ルールの詳細は、ワーカー・ノードおよびポッドのセキュリティ・ルールを参照してください。
  
  ポッド通信:
  
  サブネット:ポッドをホストするように構成された別のリージョナル・サブネット。仮想ノードに指定するポッド・サブネットはプライベートである必要があります。ポッド・サブネットと仮想ノード・サブネットは同じサブネットであることをお薦めします(その場合、Oracleではセキュリティ・リストではなくネットワーク・セキュリティ・グループにセキュリティ・ルールを定義することをお薦めします)。詳細については、Subnet Configurationを参照してください。
  
  ネットワーク・セキュリティ・グループ(NSG)のセキュリティ・ルールの使用:指定した1つ以上のネットワーク・セキュリティ・グループ(NSG)に定義されたセキュリティ・ルール(最大5つ)を使用して、ポッド・サブネットへのアクセスを制御します。NSGに対して定義されたセキュリティ・ルールは、セキュリティ・リストに対して定義されたセキュリティ・ルールではなく、またはセキュリティ・リストに対して定義されたセキュリティ・ルールも使用できます(NSGを推奨)。NSGに指定するセキュリティ・ルールの詳細は、ワーカー・ノードおよびポッドのセキュリティ・ルールを参照してください。
  
  ポッド通信の詳細は、ポッド・ネットワーキングを参照してください。
  
  Kubernetesラベルおよび色合い: (オプション)仮想ノードにラベルおよび色合いを追加して、特定のノード・プールでのワークロードのターゲット設定を有効にします:
  
  ラベル: (デフォルト・ラベルに加えて)仮想ノード・プールの仮想ノードに追加するための1つ以上のラベル。特定のノード・プールでワークロードをターゲットに設定できるようになります。
  
  Taints: 仮想ノード・プール内の仮想ノードに追加する1つ以上の色合い。Taintsを使用すると、仮想ノードはポッドを再ペルできるため、特定の仮想ノード・プールの仮想ノード上でポッドが実行されないようにできます。taintは仮想ノードにのみ適用できます。
  
  詳細は、Kubernetesのドキュメントのノードへのポッドの割当てを参照してください。
  
  「Save Changes」をクリックして、更新されたプロパティを保存します。
9. 「ノード・プール・タグ」タブおよび「ノード・タグ」タブを使用して、ノード・プールに適用されるタグ、およびノード・プール内のワーカー・ノードをホストするコンピュート・インスタンスに適用されるタグを追加または変更します。タグ付けを使用すると、コンパートメント間で異なるリソースをグループ化でき、独自のメタデータでリソースに注釈を付けることもできます。Kubernetesクラスタ関連リソースのタグ付けを参照してください。
10. 「リソース」で:
  
  「ノード」をクリックして、管理対象ノード・プール内の特定のワーカー・ノードに関する情報を表示します。オプションで、ワーカー・ノードの名前をクリックして、特定のワーカー・ノードの構成詳細を編集します。
  
  「仮想ノード」をクリックして、仮想ノード・プール内の特定のワーカー・ノードに関する情報を表示します。
  
  「メトリック」をクリックして、管理対象ノード・プールのヘルス、容量およびパフォーマンスをモニターします。詳細は、Container Engine for Kubernetesメトリックを参照してください。
  
  「作業リクエスト」をクリックして、次のことを行います:
  
  ノード・プール・リソースの特定の作業リクエストの詳細を取得します。
  
  ノード・プール・リソースの作業リクエストをリストします。
  
  詳細は、作業リクエストの表示を参照してください。
管理対象ノード・プールを更新するには、oci ce node-pool updateコマンドと必要なパラメータを使用します:
oci ce node-pool update --node-pool-id <node-pool-ocid> [OPTIONS]
CLIコマンドのパラメータおよび値の完全なリストは、CLIコマンド・リファレンスを参照してください。
UpdateNodePool操作を実行して、管理対象ノード・プールを更新します。

Oracle Cloud Infrastructureドキュメント

ノード・プールの更新