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

既存のKubernetesクラスタのノード・プールおよびワーカー・ノードのプロパティを変更するには:

1. 「クラスタ」リスト・ページで、変更するクラスタの名前を選択します。リスト・ページまたはクラスタの検索に関するヘルプが必要な場合は、クラスタのリストを参照してください。
2. 「リソース」で、「ノード・プール」を選択します。
3. 変更するノード・プールの名前を選択します。

4. 「ノード・プールの詳細」タブで、ノード・プールに関する情報(次を含む)を表示します:

   • ノード・プールのステータス。
   • ノード・プールのOCID。
   • ノード・プール内のワーカー・ノードのタイプ(管理対象または仮想)。
   • ノード・プール内の新規ワーカー・ノードの起動時に現在使用されている構成。次のものが含まれます:
     • ワーカー・ノードで実行するKubernetesのバージョン
     • ワーカー・ノードに使用するシェイプ
     • ワーカー・ノードで使用するイメージ
   • 可用性ドメイン、フォルト・ドメイン、およびワーカー・ノードをホストする様々なリージョン・サブネット(推奨)またはAD固有のサブネット。

   ノード・プール内のワーカー・ノードのタイプ(管理対象または仮想)によって、変更できるノード・プールおよびワーカー・ノード・プロパティが決まります。

5. (オプション)管理対象ノード・プールおよび管理対象ノードの場合は、次のようにプロパティを変更します。

   1. 「編集」を選択し、次を指定します:
      • 名前: ノード・プールの別の名前。機密情報の入力は避けてください。

      • バージョン: インプレース・アップグレードの実行時にノード・プール内の新しいワーカー・ノードで実行する別のバージョンのKubernetes。ワーカー・ノード上のKubernetesバージョンは、コントロール・プレーン・ノード上のバージョンと同じであるか、まだ互換性のある以前のバージョンである必要があります(KubernetesのバージョンとKubernetes Engine (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をお薦めします)。NSGに指定するのセキュリティ・ルールの詳細は、ワーカー・ノードのセキュリティ・ルールを参照してください

      • ブート・ボリューム: ワーカー・ノードのブート・ボリュームのサイズと暗号化オプションを変更します。

        • ブート・ボリュームのカスタム・サイズを指定するには、「カスタム・ブート・ボリューム・サイズを指定します」チェック・ボックスを選択します。次に、50 GBから32 TBまでのカスタム・サイズを入力します。指定するサイズは、選択したイメージのデフォルトのブート・ボリューム・サイズより大きくする必要があります。詳細は、カスタム・ブート・ボリュームのサイズを参照してください。

          ブート・ボリューム・サイズを増やす場合は、より大きなサイズを利用するために、ブート・ボリューム(ルート・パーティション)のパーティションも拡張する必要があることに注意してください。ブート・ボリュームのパーティションの拡張を参照してください。Oracle Linuxプラットフォーム・イメージには、oci-utilsパッケージが含まれています。カスタムcloud-initスクリプトでそのパッケージからoci-growfsコマンドを使用して、ルート・パーティションを拡張し、ファイル・システムを拡張できます。詳細は、ワーカー・ノードのルート・パーティションの拡張を参照してください。

        • VMインスタンスの場合は、必要に応じて「転送中暗号化の使用」チェック・ボックスを選択できます。移動中暗号化をサポートするベア・メタル・インスタンスの場合、これはデフォルトで有効であり、構成できません。転送中暗号化の詳細は、ブロック・ボリュームの暗号化を参照してください。ブート・ボリュームに独自のVaultサービス暗号化キーを使用している場合、このキーは転送中暗号化にも使用されます。それ以外の場合は、Oracle提供の暗号化キーが使用されます。
        • ブート・ボリュームはデフォルトで暗号化されますが、オプションで独自のVaultサービス暗号化キーを使用して、このボリューム内のデータを暗号化できます。暗号化のニーズにVaultサービスを使用するには、「管理するキーを使用してこのボリュームを暗号化」チェック・ボックスを選択します。使用するマスター暗号化キーを含むボールト・コンパートメントおよびボールトを選択し、マスター暗号化キー・コンパートメントおよびマスター暗号化キーを選択します。このオプションを有効にすると、このキーが保存データの暗号化と転送中データの暗号化の両方に使用されます。
          重要
          
          ブロック・ボリューム・サービスでは、Rivest-Shamir-Adleman (RSA)アルゴリズムを使用して暗号化されたキーを使用したボリュームの暗号化はサポートされていません。独自のキーを使用する場合は、Advanced Encryption Standard (AES)アルゴリズムを使用して暗号化されたキーを使用する必要があります。これは、ブロック・ボリュームおよびブート・ボリュームに適用されます。

        独自のVaultサービス暗号化キーを使用してデータを暗号化するには、IAMポリシーによってサービス暗号化キーへのアクセス権が付与される必要があることに注意してください。ブート・ボリューム、ブロック・ボリュームまたはファイル・システム(あるいはその両方)を暗号化するためのユーザー管理暗号化キーにアクセスするポリシーの作成を参照してください。

      • ポッド通信:クラスタのネットワーク・タイプがVCNネイティブ・ポッド・ネットワーキングの場合、ポッド・サブネットを使用してノード・プール内のポッドが相互に通信する方法を変更します:
        • サブネット:ポッドをホストするように構成されたリージョナル・サブネット。指定するポッド・サブネットはプライベートである必要があります。状況によっては、ワーカー・ノード・サブネットとポッド・サブネットが同じサブネットになる場合があります(その場合、Oracleではセキュリティ・リストではなくネットワーク・セキュリティ・グループでセキュリティ・ルールを定義することをお薦めします)。サブネットの構成を参照してください。
        • ネットワーク・セキュリティ・グループ:指定した1つ以上のネットワーク・セキュリティ・グループ(NSG)に対して定義されたセキュリティ・ルール(最大5つ)を使用して、ポッド・サブネットへのアクセスを制御します。NSGに対して定義されたセキュリティ・ルールは、セキュリティ・リストに対して定義されたセキュリティ・ルールのかわりに、またはNSGに対して定義されたセキュリティ・ルールを使用できます(NSGをお薦めします)。NSGに指定するセキュリティ・ルールの詳細は、ワーカー・ノードおよびポッドのセキュリティ・ルールを参照してください。

        オプションで、「拡張オプションの表示」を選択して、ノード・プールの単一ワーカー・ノードで実行するポッドの最大数(最大110)を指定します。110の制限はKubernetesによって課されます。1つのワーカー・ノードで31を超えるポッドが必要な場合、ノード・プールに指定するシェイプは、3つ以上のVNIC (ワーカー・ノード・サブネットに接続する1つのVNICと、ポッド・サブネットに接続する少なくとも2つのVNIC)をサポートしている必要があります。Maximum Number of VNICs and Pods Supported by Different Shapesを参照してください。

        ポッド通信の詳細は、ポッド・ネットワーキングを参照してください。

   2. 拡張ノード・プール・オプションの既存の値を受け入れるか、「拡張オプションの表示」を選択して、次のように代替を指定します。

      • コードとドレイン:ワーカー・ノードを終了する前に、ワーカー・ノードをコード化およびドレインするタイミングと方法を変更します。

        • 削除猶予期間(分):ワーカー・ノードを終了する前に、ワーカー・ノードをコード化およびドレインできる時間の長さ。デフォルト値(60分)を受け入れるか、または別の値を指定します。たとえば、ノード・プールをスケール・ダウンしたり、その配置構成を変更する場合、ワーカー・ノードをコード化し、それらのワークロードを排出するために30分を許可できます。ワーカー・ノードをコード化およびドレインせずにただちに終了するには、0分を指定します。
        • 猶予期間後に強制終了:ノードを置換する場合、またはノード・プール内のノードを削除する場合、正常にコード化および排出されていなくても、削除猶予期間の終了時にワーカー・ノードを終了するかどうか。デフォルトでは、このオプションは選択されていません。
        • 猶予期間後にアクションを強制:ワーカー・ノードでメンテナンス・タスク(ノードの再起動やノードのブート・ボリュームの置換など)を実行する場合、ワーカー・ノードが正常にコード化および排出されていなくても、削除猶予期間の終了時にアクションを実行するかどうか。デフォルトでは、このオプションは選択されていません。

        削除猶予期間内に停止または終了できないワーカー・ノードを含むノード・プールは、「注意が必要」ステータスになります。終了操作を開始した作業リクエストのステータスが「失敗」に設定され、終了操作が取り消されます。詳細は、クラスタの監視を参照してください

        詳細は、「停止または終了前の管理対象ノードのコード化とドレイン」を参照してください。

      • 初期化スクリプト: (オプション)インスタンスが初めて起動したときにワーカー・ノードをホストするインスタンスでcloud-initを実行するための別のスクリプト。指定するスクリプトは、cloud-initでサポートされている形式(cloud-configなど)のいずれかで記述する必要があり、サポートされているファイル・タイプ(.yamlなど)である必要があります。スクリプトを次のように指定します。
        • Cloud-Initスクリプトの選択: cloud-initスクリプトを含むファイルを選択するか、ファイルをボックスにドラッグ・アンド・ドロップします。
        • Cloud-Initスクリプトの貼付け: cloud-initスクリプトの内容をコピーし、ボックスに貼り付けます。

        Kubernetesエンジンによって作成されたクラスタでワーカー・ノードを初期化するための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 Engineによって公開SSHキーが提供されます。ただし、対応する秘密キーがないため、ワーカー・ノードへのSSHアクセスはできません。SSHを使用して、プライベート・サブネット内のワーカー・ノードに直接アクセスすることはできません(SSHを使用したプライベート・サブネットの管理対象ノードへの接続を参照)。
   3. 更新されたプロパティを保存するには、「変更の保存」を選択します。

6. (オプション)仮想ノード・プールおよび仮想ノードの場合は、次のようにプロパティを変更します:

   1. 「編集」を選択し、次を指定します:
      • 名前: ノード・プールの別の名前。機密情報の入力は避けてください。
      • ノード数:仮想ノード・プールに作成する様々な数の仮想ノード。選択した可用性ドメイン、および各可用性ドメインに指定したリージョナルのサブネット(推奨)またはAD固有のサブネットに配置されます。「ノード・プールのスケーリング」を参照してください。
      • ノード配置構成:
        • 可用性ドメイン:仮想ノードを配置する可用性のドメイン。
        • フォルト・ドメイン: (オプション)仮想ノードを配置する可用性ドメイン内の1つ以上のフォルト・ドメイン。

        オプションで、「別の行」を選択して、仮想ノードを配置するドメインおよびサブネットをさらに選択します。

        仮想ノードは、作成されると、選択した可用性ドメインおよびフォルト・ドメイン全体で可能なかぎり均等に分散されます。特定のアベイラビリティ・ドメインにフォルト・ドメインを選択しない場合、仮想ノードは、そのアベイラビリティ・ドメイン内のすべてのフォルト・ドメインで可能なかぎり均等に分散されます。

      • 仮想ノード通信:
        • サブネット:別のリージョナル・サブネット(推奨)または仮想ノードをホストするように構成されたAD固有のサブネット。ロード・バランサ・サブネットを指定した場合、仮想ノード・サブネットは異なる必要があります。指定するサブネットは、プライベート(推奨)またはパブリックにでき、リージョナル(推奨)またはAD固有にできます。ポッド・サブネットと仮想ノード・サブネットは同じサブネットであることが推奨されます(この場合、仮想ノード・サブネットはプライベートである必要があります)。詳細は、サブネット構成を参照してください。
        • ネットワーク・セキュリティ・グループ(NSG)でのセキュリティ・ルールの使用:指定した1つ以上のネットワーク・セキュリティ・グループ(NSG)に対して定義されたセキュリティ・ルールを使用して、仮想ノード・サブネットへのアクセスを制御します(最大5つ)。NSGに対して定義されたセキュリティ・ルールは、セキュリティ・リストに対して定義されたセキュリティ・ルールのかわりに、またはNSGに対して定義されたセキュリティ・ルールを使用できます(NSGをお薦めします)。NSGに指定するセキュリティ・ルールの詳細は、ワーカー・ノードおよびポッドのセキュリティ・ルールを参照してください。
      • ポッド通信:
        • サブネット:ポッドをホストするように構成された別のリージョナル・サブネット。仮想ノードに指定するポッド・サブネットはプライベートである必要があります。ポッド・サブネットと仮想ノード・サブネットは同じサブネットであることをお薦めします(その場合、Oracleではセキュリティ・リストではなくネットワーク・セキュリティ・グループでセキュリティ・ルールを定義することをお薦めします)。詳細は、サブネット構成を参照してください。
        • ネットワーク・セキュリティ・グループ(NSG)でのセキュリティ・ルールの使用:指定した1つ以上のネットワーク・セキュリティ・グループ(NSG)に対して定義されたセキュリティ・ルールを使用して、ポッド・サブネットへのアクセスを制御します(最大5つ)。NSGに対して定義されたセキュリティ・ルールは、セキュリティ・リストに対して定義されたセキュリティ・ルールのかわりに、またはNSGに対して定義されたセキュリティ・ルールを使用できます(NSGをお薦めします)。NSGに指定するセキュリティ・ルールの詳細は、ワーカー・ノードおよびポッドのセキュリティ・ルールを参照してください。

        ポッド通信の詳細は、ポッド・ネットワーキングを参照してください。

      • Kubernetesラベルおよびテイント: (オプション)仮想ノードにラベルおよびテイントを追加して、特定のノード・プールでのワークロードのターゲティングを有効にします:
        • ラベル: 仮想ノード・プールの仮想ノードに追加するための1つ以上のラベル(デフォルト・ラベルに加えて)。特定のノード・プールでワークロードのターゲットに設定できるようになります。
        • 塗料: 仮想ノード・プール内の仮想ノードに追加する1つ以上の塗料。Taintsを使用すると、仮想ノードはポッドを再ペルできるため、ポッドが特定の仮想ノード・プールの仮想ノードで実行されないようにできます。taintは仮想ノードにのみ適用できます。

        詳細は、Kubernetesのドキュメントのノードへのポッドの割当てを参照してください。

   2. 更新されたプロパティを保存するには、「変更の保存」を選択します。
7. 「ノード・プール・タグ」タブおよび「ノード・タグ」タブを使用して、ノード・プールに適用されたタグを追加または変更し、ノード・プール内のワーカー・ノードをホストしているコンピュート・インスタンスに適用されるタグを追加します。タグ付けにより、コンパートメント間で異なるリソースをグループ化でき、独自のメタデータを使用してリソースに注釈を付けることもできます。Kubernetesクラスタ関連リソースのタグ付けを参照してください。
8. 「リソース」で、次の手順を実行します。
   • 「ノード」を選択して、管理対象ノード・プール内の特定のワーカー・ノードに関する情報を表示します。必要に応じて、ワーカー・ノードの名前を選択して、特定のワーカー・ノードの構成詳細を編集します。
   • 仮想ノード・プール内の特定のワーカー・ノードに関する情報を表示するには、「仮想ノード」を選択します。
   • 「メトリック」を選択して、管理対象ノード・プールのヘルス、容量およびパフォーマンスをモニターします。詳細は、Kubernetesエンジン(OKE)のメトリックを参照してください。
   • 「作業リクエスト」を選択して、次の操作を行います。
     • ノード・プール・リソースの特定の作業リクエストの詳細を取得します。
     • ノード・プール・リソースの作業リクエストをリストします。

     詳細は、作業リクエストの表示を参照してください。