管理対象ノード・プールの更新

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

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

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

Oracle Cloud Infrastructureドキュメント

管理対象ノード・プールの更新