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

ワークロード・クラスタのプライベート・クラウド・アプライアンスでOKEワーカー・ノード・プールを作成する方法について学習します。

ノードはプライベート・クラウド・アプライアンスのコンピュート・インスタンスです。ワーカー・ノード・プールを作成する場合は、作成するノードの数と、インスタンスを定義するその他のパラメータを指定します。

ノート

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

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

カスタムCAサポートは、CLI (oci ce node-pool createおよびoci ce node-pool update)を使用してのみ使用できます。

    1. 「Web UIの計算」ナビゲーション・メニューで、「コンテナ」「Kubernetesクラスタ(OKE)」の順に選択します。

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

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

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

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

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

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

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

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

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

      • 配置構成

        • ワーカー・ノード・サブネット: 「ワーカー・サブネットの作成(Flannel Overlay)」または「ワーカー・サブネットの作成(VCNネイティブ・ポッド)」で説明されている、ワーカー・サブネットなどの構成を持つサブネットを選択します。パブリック・クラスタの場合は、ワーカー・サブネットのNATプライベート・バージョンを作成します。プライベート・クラスタの場合は、VCNのみのプライベート・バージョンのワーカー・サブネットを作成します。サブネットを1つのみ選択してください。サブネットには、コントロール・プレーン・エンドポイントと通信するためのルールが設定されている必要があります。サブネットはプライベート・ルート表を使用し、「ワーカー・サブネットの作成(Flannelオーバーレイ)」または「ワーカー・サブネットの作成(VCNネイティブ・ポッド)」で説明されているワーカー-seclistセキュリティ・リストのようなセキュリティ・リストを持っている必要があります。

        • フォルト・ドメイン: フォルト・ドメインを選択するか、「最適なフォルト・ドメインを自動的に選択」(デフォルト・オプション)を選択します。Roving Edge Deviceにはフォルト・ドメインが1つのみあります。

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

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

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

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

          使用するイメージがリストに表示されない場合は、CLIプロシージャを使用してイメージのOCIDを指定します。必要なイメージのOCIDを取得するには、このイメージを使用していたノード・プールに対してce node-pool getコマンドを使用します。

          ノート

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

      • シェイプ: ワーカー・ノードのシェイプを選択します。使用可能なシェイプの説明は、コンピュート・シェイプを参照してください。GPUオペレータ・クラスタ・アドオンを使用している場合は、サポートされているGPUシェイプを使用できます。

        フレキシブル・シェイプではないシェイプを選択すると、メモリーの量とOCPUの数が表示されます。これらの数字は、コンピュート・シェイプの表のこのシェイプに表示される数字と一致します。

        フレキシブル・シェイプを選択した場合は、必要な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の整数を指定してください。

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

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

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

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

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

        ノート

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

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

        重要

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

    6. ダイアログ・ボックスで「ノード・プールの追加」ボタンを選択します。

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

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

    次の手順:

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

    2. プライベート・クラウド・アプライアンスの外部でコンテナ化されたアプリケーションを公開するサービスを作成します。コンテナ化されたアプリケーションの公開を参照してください。

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

  • 新しいノード・プールを作成するには、oci ce node-pool createコマンドと必要なパラメータを使用します。

    oci ce node-pool create --cluster-id cluster_OCID --compartment-id compartment_OCID --name pool_name --node-shape node_shape_name [OPTIONS]
    1. コマンドの実行に必要な情報を取得します。

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

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

      • ノード・プールの名前です。機密情報を入力しないでください。

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

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

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

      • (VCNネイティブ・ポッド・ネットワーキング・クラスタのみ)ポッド・サブネットのOCID。ポッド・サブネット(VCNネイティブ・ポッド)の作成を参照してください。詳細は、このページの「コンソール」タブを選択し、「ポッド通信」を参照してください。--pod-subnet-idsオプションを使用します。--pod-subnet-idsオプション値は配列ですが、指定できるポッド・サブネットOCIDは1つのみです。

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

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

      • このノード・プールのノードで使用するイメージの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を参照してください。

      • このノード・プール内のワーカー・ノードのシェイプの名前。GPUオペレータ・クラスタ・アドオンを使用している場合は、サポートされているGPUシェイプを使用できます。他のすべての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の数とメモリー量は、コンピュート・シェイプの「標準シェイプ」でこのシェイプに表示される値に設定されます。

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

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

        --initial-node-labelsオプションを使用して、ノードにラベルを追加します。ラベルは、Kubernetesクラスタに参加した後にノードに追加するキー/値ペアのリストです。メタデータ制限の詳細は、メタデータ・キー制限を参照してください。

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

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

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

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

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

        メタデータの制限の詳細は、メタデータ・キーの制限事項を参照してください。ノード・メタデータの最大サイズは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フリーフォーム・タグの値を指定しないでください。これらのタグ値はシステムによって生成されます。

      • (オプション)カスタムCA証明書バンドル。プライベート・コンテナ・レジストリへのTLS接続の検証に使用するカスタムCA証明書バンドルを指定できます。custom-ca-bundle-certregistry-hostおよびregistry-portメタデータ・パラメータは、--node-metadataオプションとともに使用します。

        --node-metadataオプション引数で、custom-ca-bundle-certの値を指定する必要があります。

        --node-metadata '{"custom-ca-bundle-cert":"<base64-encoded-cert-content>"}'

        カスタムCAバンドルを使用してプライベート・レジストリを構成した場合は、ノードが新しくプロビジョニングまたは循環(スケール・ダウンおよびバックアップまたはローリング再起動)され、更新された証明書がすべてのワーカー・ノードに適用されることを確認します。

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

      例:

      この例に示すオプション、および--node-boot-volume-size-in-gbsnsg-idsなどの他のオプションの詳細は、コンソールの手順を参照してください。--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の名前の後の最初の32文字です。このノード・プールOCIDのID文字列が名前に含まれているインスタンスをリストで検索します。

    CLIコマンド、フラグおよびオプションの完全なリストは、コマンドライン・リファレンスを参照してください。

    次の手順:

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

    2. プライベート・クラウド・アプライアンスの外部でコンテナ化されたアプリケーションを公開するサービスを作成します。コンテナ化されたアプリケーションの公開を参照してください。

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

  • CreateNodePool操作を使用して、新しいノード・プールを作成します。

    APIの使用およびリクエストの署名の詳細は、REST APIおよびセキュリティ資格証明を参照してください。SDKについては、ソフトウェア開発キットとコマンドライン・インタフェースを参照してください。

    次のステップ:

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

    2. プライベート・クラウド・アプライアンスの外部でコンテナ化されたアプリケーションを公開するサービスを作成します。コンテナ化されたアプリケーションの公開を参照してください。

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