OKEワーカー・ノード・プールの作成

次の手順では、OKEワークロード・クラスタのワーカー・ノードのプールを作成する方法について説明します。 ノードはPrivate Cloud Applianceコンピュート・インスタンスです。

OKE cloud-initスクリプトはカスタマイズできません。

プロキシ設定を構成するには、OCI CLIまたはOCI APIを使用して、ノード・メタデータにプロキシを設定します。 クラスタが「VCNネイティブ・ポッド・ネットワーキング」を使用している場合は、169.254.169.254をnoproxy設定に追加します。

「コンピュートWeb UI」の使用

  1. ダッシュボードで、「コンテナ / ビュー」Kubernetesクラスタ (OKE)を選択します。

    ノード・プールをアタッチするクラスタがリストされていない場合は、リストの上にあるコンパートメント・メニューから別のコンパートメントを選択します。

  2. ノード・プールを追加するクラスタの名前を選択します。

  3. クラスタの詳細ページで、「リソース」セクションまでスクロールし、「ノード・プール」を選択します。

  4. 「ノード・プール」リストで、「ノード・プールの追加」ボタンを選択します。

  5. 「ノード・プールの追加」ダイアログで、次の情報を指定します:

    • 名前: 新しいノード・プールの名前。 機密情報は使用しないでください。

    • コンパートメント: 新しいノード・プールを作成するコンパートメント。

    • ノード・プールのオプション: 「ノード数」フィールドに、このノード・プールに必要なノード数を入力します。 デフォルトは0です。 最大数はクラスタ当たり128で、複数のノード・プールに分散できます。

    • ネットワーク・セキュリティ・グループ: ネットワーク・セキュリティ・グループを有効にするボックスにチェックマークを入れる場合は、「ネットワーク・セキュリティ・グループの追加」ボタンを選択し、ドロップダウン・リストからNSGを選択します。 必要なNSGを見つけるためにコンパートメントを変更する必要がある場合があります。 ワーカー・サブネットからのプライマリVNICは、このNSGにアタッチされます。

    • 配置構成

    • ソース・イメージ: イメージを選択します。

      1. プラットフォーム・イメージ・ソース・タイプを選択します。

      2. リストからイメージを選択してください。

        イメージ・リストには、「オペレーティング・システム」、「OSバージョン」および「Kubernetesバージョン」の列があります。 OSバージョンの右側にあるドロップダウン・メニュー矢印またはKubernetesバージョンを使用して、別のバージョンを選択できます。 複数のイメージのKubernetesバージョンがまったく同じ場合は、イメージ名の日付に従って最新のイメージを選択します。

        使用するイメージがリストされていない場合は、OCI CLIまたはOCI APIを使用して、イメージのOCIDを指定します。 目的のイメージのOCIDを取得するには、このイメージを以前に使用したノード・プールに対してce node-pool getコマンドを使用します。

        ノート:

        指定するイメージには、クラスタの作成時に指定したKubernetesバージョンより新しいKubernetesバージョンを含めないでください。 クラスタのKubernetesバージョンは、クラスタ・リスト表の列にあります。

    • シェイプ: ワーカー・ノードのシェイプを選択します。 各シェイプの説明は、「Oracle Private Cloud Appliance概要ガイド」「コンピュート・シェイプ」を参照してください。 Private Cloud Appliance X10システムの場合、シェイプはVM.PCAStandard.E5.Flexであり、変更できません。

      フレキシブル・シェイプではないシェイプを選択すると、メモリーの量とOCPUの数が表示されます。 これらの番号は、「Oracle Private Cloud Appliance概要ガイド」の表にあるこのシェイプに示されている番号と一致します。

      フレキシブル・シェイプを選択した場合は、必要なOCPUの数を指定する必要があります。 オプションで、必要なメモリーの合計量を指定できます。 メモリーのギガバイトのデフォルト値は、OCPUに指定した数の16倍です。 各値フィールドの内側をクリックして、許容される最小値と最大値を表示します。

      ノート:

      10の実行中のポッドごとに、少なくとも2つのOCPUと32 GBのメモリーを割り当てます。 予定されているワークロードに応じて、より多くのリソースを割り当てる必要がある場合があります。 「ポッドおよびコンテナのResource Management」を参照してください。

    • ブート・ボリューム: (オプション)ボックスにチェックマークを入れて、カスタム・ブート・ボリューム・サイズを指定します。

      ブート・ボリューム・サイズ(GB): 選択したイメージのデフォルトのブート・ボリューム・サイズが表示されます。 大きいサイズを指定するには、50から16384までの値をギガバイト(50 GBから16 TB)で入力するか、増分矢印と減分矢印を使用します。

      カスタム・ブート・ボリューム・サイズを指定する場合、より大きなサイズを使用できるようにパーティションを拡張する必要があります。 Oracle Linuxプラットフォーム・イメージには、oci-utilsパッケージが含まれます。 そのパッケージのoci-growfsコマンドを使用して、ルート・パーティションを拡張し、ファイル・システムを拡張します。 oci-growfs」を参照してください。

    • 「ポッド通信」 (「VCNネイティブ・ポッド・ネットワーキング」クラスタのみ)

      ポッド通信サブネット: VCNネイティブ・ポッド・ネットワーキング・ポッド・サブネットの作成で説明されているポッド・サブネットのような構成を持つサブネットを選択します。

      ノード当たりのポッド数: ノード・プール内の単一のワーカー・ノードで実行するポッドの最大数。 デフォルト値は31です。 1から110までの数値を入力できます。 指定したシェイプで許可されるVNICの数(上の「シェイプ」を参照)は、この最大ポッド数を制限します。 「ノード・シェイプとポッド数」を参照してください。 ポッド・サブネットのアドレス領域を節約するには、単一のワーカー・ノードで実行するポッドの最大数を減らします。 これにより、ポッド・サブネットに事前に割り当てられるIPアドレスの数が削減されます。

      「ネットワーク・セキュリティ・グループ(NSG)でセキュリティ・ルールを使用」チェック・ボックスを選択した場合は、「ネットワーク・セキュリティ・グループの追加」ボタンを選択し、ドロップダウン・リストからNSGを選択します。 必要なNSGを見つけるためにコンパートメントを変更する必要がある場合があります。 ポッド・サブネットからのセカンダリVNICは、このNSGにアタッチされます。

    • コードンとドレイン: (オプション)削除猶予期間の分数を入力するか、矢印を使用して削除猶予期間の分数を減らすか増やします。 最大値とデフォルト値は60分です。

      • Private Cloud Applianceリリース3.0.2-b1261765 0から60までの整数を指定します。 0を入力すると、20秒が最小削除猶予期間であるため、値は0.333に変換されます。 上矢印を選択すると、値が1に変わります。

      • Private Cloud Applianceリリース3.0.2-b1185392 1から60までの整数を指定します。

      「猶予期間後に強制終了」の選択を解除することはできません。 ノードは、ポッドが削除された後、またはすべてのポッドが削除されていない場合でも、削除猶予期間の終了時に削除されます。

      コードン、ドレインおよびエビクションの猶予期間については、OCI CLIの使用の「ノードおよびノード・プールの削除設定」を参照してください。

    • SSHキー: ワーカー・ノードの公開SSHキー。 公開キー・ファイルをアップロードするか、ファイルの内容をコピーして貼り付けます。

    • Kubernetesラベル: 「Add Kubernetes Label」ボタンを選択し、キーの名前と値を入力します。 これらのラベルを使用して、特定のノードまたはノード・グループでスケジュールするためのポッドをターゲットにできます。 OCI CLIプロシージャの説明および例を参照してください。

    • ノード・プール・タグ: ノード・プール・リソースの定義済タグまたはフリーフォーム・タグ。

      ノート:

      OraclePCA-OKE.cluster_id定義タグまたはClusterResourceIdentifierフリーフォーム・タグの値を指定しないでください。 これらのタグ値はシステム生成で、ノード・プール・リソースではなくノード(インスタンス)にのみ適用されます。

    • ノード・タグ: ノード・プール内のすべてのノードに適用される定義済タグまたはフリーフォーム・タグ。

      重要:

      OraclePCA-OKE.cluster_id定義タグまたはClusterResourceIdentifierフリーフォーム・タグの値を指定しないでください。 これらのタグ値は、システムによって生成されます。

  6. 「ノード・プールの追加」ボタンを選択します。

    ノード・プールの詳細ページが表示されます。 「リソース」セクションまでスクロールし、「作業リクエスト」を選択して、ノード・プールの作成の進行状況を確認し、「ノード」リストに追加されているノードを表示します。 作業リクエストのステータスは、クラスタがアクティブ状態または失敗状態になるまで「Accepted」になります。

    インスタンスのリストでこれらのノードを識別するには、これらのノードの名前の形式がoke-IDであることに注意してください。ここで、IDは、ノード・プールOCIDのpca_nameの後の最初の32文字です。 このノード・プールOCIDから、名前にID文字列が含まれるリスト内のインスタンスを検索します。

OCI CLIの使用

  1. コマンドの実行に必要な情報を取得します。

    • ノード・プールを作成するコンパートメントのOCID: oci iam compartment list

    • このノード・プールのクラスタのOCID: oci ce cluster list

    • ノード・プールの名前。 機密情報は使用しないでください。

    • ワーカー・サブネットOCIDおよびフォルト・ドメインを含む、ノードの配置構成。 「コンピュートWeb UI」プロシージャの配置構成の説明を参照してください。 このオプションの内容と形式を表示するには、次のコマンドを使用します:

      $ oci ce node-pool create --generate-param-json-input placement-configs

      次のコマンドを使用して、フォルト・ドメインをリスト: oci iam fault-domain list 配置構成では、複数のフォルト・ドメインまたは複数のサブネットを指定しないでください。 システムが最適なフォルト・ドメインを選択できるようにするには、フォルト・ドメインを指定しないでください。

    • (「VCNネイティブ・ポッド・ネットワーキング」クラスタのみ)ポッド・サブネットのOCID。 「VCNネイティブ・ポッド・ネットワーキング・ポッド・サブネットの作成」を参照してください。 前述の「コンピュートWeb UI」プロシージャのポッド通信の説明も参照してください。 --pod-subnet-idsオプションを使用します。 --pod-subnet-idsオプション値は配列ですが、指定できるポッド・サブネットOCIDは1つのみです。

      ノード・プール内の単一のワーカー・ノードで実行するポッドの最大数。 --max-pods-per-nodeオプションを使用します。 デフォルト値は31です。 1から110までの数値を入力できます。 指定したシェイプで許可されるVNICの数(下の「シェイプの名前」を参照)は、この最大ポッド数を制限します。 「ノード・シェイプとポッド数」を参照してください。 ポッド・サブネットのアドレス領域を節約するには、単一のワーカー・ノードで実行するポッドの最大数を減らします。 これにより、ポッド・サブネットに事前に割り当てられるIPアドレスの数が削減されます。

      (オプション)このノード・プールのポッドに使用するネットワーク・セキュリティ・グループのOCID。 --pod-nsg-idsオプションを使用します。 最大5つのNSGを指定できます。

    • このノード・プールのノードに使用するイメージのOCID。

      次のコマンドを使用して、使用するイメージのOCIDを取得します:

      $ oci compute image list --compartment-id compartment_OCID

      使用するイメージがリストされていない場合は、このイメージを以前に使用したノード・プールのce node-pool getコマンドの出力からイメージのOCIDを取得できます。

      ノート:

      指定するイメージは、そのdisplay-nameに"-OKE-"があり、クラスタの作成時に指定したKubernetesバージョンより新しいKubernetesバージョンを持つことはできません。

      クラスタのKubernetesバージョンがcluster list出力に表示されます。 イメージのKubernetesバージョンは、image list出力のdisplay-nameプロパティに表示されます。 次のイメージのKubernetesバージョンは1.29.9です。

      "display-name": "uln-pca-Oracle-Linux8-OKE-1.29.9-20250325.oci"

      複数のイメージのKubernetesバージョンがまったく同じ場合は、イメージ名の日付に従って最新のイメージを選択します。

      node-pool createコマンドで--kubernetes-versionオプションを指定しないでください。

      カスタム・ブート・ボリューム・サイズはギガバイト単位で指定できます。 デフォルトのブート・ボリューム・サイズは50 GBです。 カスタム・ブート・ボリューム・サイズを指定するには、--node-source-detailsオプションを使用してブート・ボリューム・サイズとイメージの両方を指定します。 --node-image-id--node-source-detailsの両方を指定することはできません。 次のコマンドを使用して、ノード・ソースの詳細オプションの内容と形式を表示します。

      $ oci ce node-pool create --generate-param-json-input node-source-details

      カスタム・ブート・ボリューム・サイズを指定する場合、より大きなサイズを使用できるようにパーティションを拡張する必要があります。 Oracle Linuxプラットフォーム・イメージには、oci-utilsパッケージが含まれます。 そのパッケージのoci-growfsコマンドを使用して、ルート・パーティションを拡張し、ファイル・システムを拡張します。 oci-growfs」を参照してください。

    • このノード・プール内のワーカー・ノードのシェイプの名前。 Private Cloud Appliance X10システムの場合、コントロール・プレーン・ノードのシェイプはVM.PCAStandard.E5.Flexであり、変更できません。 他のすべてのPrivate Cloud Applianceシステムでは、デフォルトのシェイプはVM.PCAStandard1.1で、別のシェイプを指定できます。

      フレキシブル・シェイプを指定する場合は、次の例に示すように、シェイプ構成も指定する必要があります。 ocpusの値を指定する必要があります。 memoryInGBsプロパティはオプションです。デフォルト値のギガバイトは、ocpusの16倍です。

      --node-shape-config '{"ocpus": 32, "memoryInGBs": 512}'

      ノート:

      10の実行中のポッドごとに、少なくとも2つのOCPUと32 GBのメモリーを割り当てます。 予定されているワークロードに応じて、より多くのリソースを割り当てる必要がある場合があります。 「ポッドおよびコンテナのResource Management」を参照してください。

      フレキシブル・シェイプではないシェイプを指定する場合は、--node-shape-configを指定しないでください。 OCPUの数とメモリー容量は、「Oracle Private Cloud Appliance概要ガイド」「コンピュート・シェイプ」の「標準シェイプ」でこのシェイプに表示される値に設定されます。

    • (オプション)このノード・プール内のノードに使用するネットワーク・セキュリティ・グループのOCID。 --nsg-ids オプションを使用します。 複数のNSGを指定しないでください。

    • (オプション) ラベル。 ノードにラベルを設定すると、特定のノードまたはノード・グループでスケジューリングするためにポッドをターゲットにできます。 この機能を使用して、特定のポッドが特定の分離、セキュリティまたは規制プロパティを持つノードでのみ実行されるようにします。

      --initial-node-labelsオプションを使用して、ノードにラベルを追加します。 ラベルは、Kubernetesクラスタに参加した後にノードに追加するキー/バリュー・ペアのリストです。 メタデータ制限の詳細は、「Oracle Private Cloud Appliance概要ガイド」「コンピュート・インスタンスの概念」の章のメタデータ・キー制限を参照してください。

      次に、ノード・プール内のノードに適用するラベルの例を示します:

      --initial-node-labels '[{"key":"disktype","value":"ssd"}]

      ノードをラベルに基づいて選択する簡単な方法は、ポッド構成でnodeSelectorを使用することです。 Kubernetesは、nodeSelectorセクションで指定されている各ラベルのノードにのみポッドをスケジュールします。

      次のポッド構成からの抜粋の例では、この構成を使用するポッドを、ssdディスク・タイプ・ラベルを持つノードで実行する必要があることを指定します:

      nodeSelector:
        disktype: ssd
    • (オプション)ノード・メタデータ。 --node-metadata オプションを使用して、カスタム・ユーザー・データをノードにアタッチします。 特定の例については、次のプロキシ設定項目を参照してください。

      メタデータ制限の詳細は、「Oracle Private Cloud Appliance概要ガイド」「コンピュート・インスタンスの概念」の章のメタデータ・キー制限を参照してください。 ノード・メタデータの最大サイズは32,000バイトです。

    • (オプション)プロキシ設定。 ネットワークで、ワーカー・ノードが外部レジストリまたはリポジトリに到達できるようにするためのプロキシ設定が必要な場合は、たとえば、--node-metadata オプションの引数を作成します。

      --node-metadata オプション引数で、次のサンプル・ファイル引数に示すように、crio-proxyおよびcrio-noproxyの値を指定します:

      {
        "crio-proxy": "http://your_proxy.your_domain_name:your_port",
        "crio-noproxy": "localhost,127.0.0.1,your_domain_name,ocir.io,Kubernetes_cidr,pods_cidr"
      }

      クラスタで「VCNネイティブ・ポッド・ネットワーキング」を使用している場合は、次の例のように、noproxy設定に169.254.169.254を追加します:

      "crio-noproxy": "localhost,127.0.0.1,your_domain_name,ocir.io,Kubernetes_cidr,pods_cidr,169.254.169.254"
    • (オプション)ノードおよびノード・プールの削除設定。 ノード・プールの削除、指定したノードの削除、ノード・プールのサイズの縮小、またはノード・プール・ノードの配置構成の変更時に、ノードの削除を処理する方法を指定できます。 これらのノード削除パラメータは、ノード・プールの更新時、指定したノードの削除時、またはノード・プールの削除時に設定または変更することもできます。

      ノード・プールの削除設定を指定するには、--node-eviction-node-pool-settingsオプションの引数を作成します。 ノードの削除猶予期間(evictionGraceDuration)を指定できます。 ノードは、ポッドが削除された後、または削除猶予期間の終了時に常に削除されます。

      • 削除猶予期間。 この値は、ワーカー・ノードをコードンおよびドレインできる時間を指定します。

        コードンされたノードに新しいポッドを配置することはできません。 そのノード上の既存のポッドは影響を受けません。

        ノードが排出されると、各ポッドのコンテナは正常に終了し、必要なクリーンアップを実行します。

        削除猶予期間の値は、ISO 8601形式で表されます: たとえば、PT45S、PT20MまたはPT39M21Sです。 デフォルト値と最大値は60分(PT60M)です。 最小値は20秒(PT20S)です。 OKEは、常に少なくとも20秒間ノードをドレインしようとします。

      • 強制削除。 ノードは、ポッドが削除された後、または削除猶予期間の終了時に常に削除されます。 デフォルトまたは指定された削除猶予期間の後、1つ以上のポッド・コンテナが完全に排出されていない場合でも、ノードは削除されます。

      次に、--node-eviction-node-pool-settingsオプションの引数の例を示します。 isForceDeleteAfterGraceDurationプロパティを含める場合、その値はtrueである必要があります。 ノードは、ポッドが削除された後、または削除猶予期間の終了時に常に削除されます。

      --node-eviction-node-pool-settings '{"evictionGraceDuration": "PT30M", "isForceDeleteAfterGraceDuration": true}'

      ノート:

      Terraformを使用してnode_eviction_node_pool_settingsを指定した場合、trueがデフォルト値であっても、is_force_delete_after_grace_durationを明示的にtrueに設定する必要があります。 Terraformを使用している場合、is_force_delete_after_grace_durationプロパティ設定はオプションではありません。

    • (オプション) タグ。 --defined-tagsまたは--freeform-tagsオプションを使用して、ノード・プール・リソースの定義済タグまたはフリーフォーム・タグを追加します。 OraclePCA-OKE.cluster_id定義タグまたはClusterResourceIdentifierフリーフォーム・タグの値を指定しないでください。 これらのタグ値はシステム生成で、ノード・プール・リソースではなくノード(インスタンス)にのみ適用されます。

      定義済タグまたはフリーフォーム・タグをノード・プール内のすべてのノードに追加するには、--node-defined-tagsおよび--node-freeform-tagsオプションを使用します。

      重要:

      OraclePCA-OKE.cluster_id定義タグまたはClusterResourceIdentifierフリーフォーム・タグの値を指定しないでください。 これらのタグ値は、システムによって生成されます。

  2. ノード・プールの作成コマンドを実行します。

    例:

    この例に示されているオプションと、--node-boot-volume-size-in-gbs--nsg-idsなどの他のオプションの詳細は、前述の「コンピュートWeb UI」プロシージャを参照してください。 --pod-subnet-idsオプションは、クラスタが「VCNネイティブ・ポッド・ネットワーキング」を使用する場合にのみ適用できます。

    $ oci ce node-pool create \
    --cluster-id ocid1.cluster.unique_ID --compartment-id ocid1.compartment.unique_ID \
    --name node_pool_name --node-shape shape_name --node-image-id ocid1.image.unique_ID \
    --placement-configs '[{"availabilityDomain":"AD-1","subnetId":"ocid1.subnet.unique_ID"}]' \
    --pod-subnet-ids '["ocid1.subnet.unique_ID"]' --size 10 --ssh-public-key "public_key_text"

    このnode-pool createコマンドの出力は、node-pool getコマンドの出力と同じです。 クラスタOCIDが表示され、各ノードの簡単なサマリーが表示されます。 ノードの詳細は、ノードのOCIDを指定してcompute instance getコマンドを使用します。

    work-request getコマンドを使用して、ノード・プール作成操作のステータスを確認します。 作業リクエストOCIDは、cluster get出力のmetadataセクションのcreated-by-work-request-idにあります。

    $ oci ce work-request get --work-request-id workrequest_OCID

    作業リクエストのステータスは、クラスタがアクティブ状態または失敗状態になるまでACCEPTEDになります。

    インスタンスのリストでこれらのノードを識別するには、これらのノードの名前の形式がoke-IDであることに注意してください。ここで、IDは、ノード・プールOCIDのpca_nameの後の最初の32文字です。 このノード・プールOCIDから、名前にID文字列が含まれるリスト内のインスタンスを検索します。

ノード・プールの次のステップ

  1. ワーカー・ノードに必要なレジストリまたはリポジトリを構成します。 「OKEサービス」およびアプリケーション・イメージで使用する自己管理パブリックまたはイントラネット・コンテナ・レジストリにアクセスできることを確認します。

  2. Private Cloud Applianceの外部でコンテナ化されたアプリケーションを公開するサービスを作成します。 「コンテナ化されたアプリケーションの公開」を参照してください。

  3. アプリケーションで使用する永続ストレージを作成します。 「コンテナ化されたアプリケーションのストレージの追加」を参照してください。