コンソールを使用した、カスタム作成ワークフローでの明示的に定義された設定によるクラスタの作成

Container Engine for Kubernetes (OKE)を使用して、カスタム作成ワークフローを使用して、明示的に定義した設定および既存のネットワーク・リソースでKubernetesクラスタを作成する方法を確認します。

Container Engine for Kubernetesを使用して、カスタム作成ワークフローで明示的に定義された設定および既存のネットワーク・リソースでクラスタを作成するには:

1. ナビゲーション・メニューを開き、「開発者サービス」をクリックします「コンテナとアーティファクト」で、「Kubernetesクラスタ(OKE)」をクリックします。
2. 作業する権限があるコンパートメントを選択します。
3. 「クラスタ・リスト」ページで、「クラスタの作成」をクリックします。
4. 「クラスタの作成」ダイアログで、「カスタム作成」を選択して「送信」をクリックします。

5. 「クラスタの作成」ページで、新しいクラスタのデフォルトの構成の詳細をそのまま使用するか、次のように他の方法を指定します:

   • 名前: 新しいクラスタの名前。デフォルトの名前をそのまま使用するか、名前を入力します。機密情報を入力しないでください。
   • コンパートメント: 新規クラスタを作成するコンパートメント。
   • Kubernetesバージョン: クラスタのコントロール・プレーン・ノードで実行するKubernetesのバージョン。デフォルトのバージョンをそのまま使用するか、バージョンを選択します。特に、選択したKubernetesバージョンによって、作成されたクラスタで有効になるアドミッション・コントローラのデフォルト・セットが決まります(サポートされているアドミッション・コントローラを参照)。

6. 拡張クラスタ・オプションのデフォルトを受け入れるか、「拡張オプションの表示」をクリックして、次のようにオプションを設定します:

   1. 特定のマスター暗号化キーによって署名されたOracle Cloud Infrastructure Registryからのイメージのデプロイメントのみを許可するかどうかを指定します。署名付きイメージの使用を強制するには、「このクラスタでのイメージ検証ポリシーの有効化」を選択し、暗号化キーおよびそれを含むボールトを指定します。レジストリからの署名付きイメージ使用の強制を参照してください。

   2. クラスタのetcdキー-値ストアに格納されているKubernetesシークレットの暗号化方法を指定します:

      • Oracle管理キーを使用した暗号化: Oracleによって管理されるマスター暗号化キーを使用して、etcdキー-値ストア内のKubernetesシークレットを暗号化します。

      • 管理するキーを使用して暗号化:管理するマスター暗号化キー(ボールト・サービスに格納されている)を使用して、etcdキー-値ストア内のKubernetesシークレットを暗号化します。このオプションを選択すると、次を指定します。

        • <compartment-name>のボールトの選択: 指定したコンパートメント内のボールトのリストから、マスター暗号化キーを含むボールト。デフォルトでは、<compartment-name>はクラスタの作成先のコンパートメントですが、「コンパートメントの変更」をクリックして別のコンパートメントを選択することもできます。
        • <compartment-name>の鍵を選択: 指定したコンパートメント内の鍵のリストから、マスター暗号化鍵の名前。デフォルトでは、<compartment-name>はクラスタの作成先のコンパートメントですが、「コンパートメントの変更」をクリックして別のコンパートメントを選択することもできます。クラスタの作成後は、マスター暗号化キーを変更できないことに注意してください。

      マスター暗号化キーを管理する場合は、クラスタを作成する前に、適切なキー、動的グループおよびポリシーがすでに存在している必要があります。詳細は、EtcdにあるKubernetesシークレットの暗号化を参照してください。

   3. (1.25より前のKubernetesバージョン)ポッド・セキュリティ・ポリシーを適用して、クラスタで実行できるポッド操作を制御するかどうかを指定します:

      • 未実施: ポッド・セキュリティ・ポリシーを実施しません。
      • 実施済: PodSecurityPolicyアドミッション・コントローラを有効にして、ポッド・セキュリティ・ポリシーを実施します。ポッド・セキュリティ・ポリシーの条件を満たすポッドのみがクラスタによって受け入れられます。詳細は、Container Engine for Kubernetesでのポッド・セキュリティ・ポリシーの使用を参照してください。
      注意
      
      

      クラスタのPodSecurityPolicyアドミッション・コントローラを有効にする場合、ポリシーにポッドを関連付けるために適切なポッド・セキュリティ・ポリシーがロール(またはclusterrole)およびロール・バインディング(またはclusterrolebinding)とともに存在する場合を除いて、クラスタ上でアプリケーション・ポッドが開始できないことに注意することが非常に重要です。これらの前提条件が満たされないかぎり、PodSecurityPolicyアドミッション・コントローラが有効なクラスタでアプリケーション・ポッドを実行することはできません。

      次のようにPodSecurityPolicyアドミッション・コントローラを使用することを強くお薦めします:

      • 新しいクラスタを作成するたびに、ポッド・セキュリティ・アドミッション・コントローラを有効にします。
      • 新しいクラスタを作成したら、ただちにロール(またはclusterrole)およびロール・バインディング(またはclusterrolebinding)とともにポッド・セキュリティ・ポリシーを作成します。
   4. (拡張クラスタのみ)クラスタ・アドオンの管理方法を指定します。特定のアドオンを有効または無効にしたり、アドオンのバージョンを選択したり、Oracleによる自動更新をオプトインおよびオプトアウトしたり、アドオン固有のカスタマイズを管理したりするには、「クラスタアドオンの構成」を選択します。適切なクラスタ・アドオンを選択し、必要に応じてオプションを設定します。クラスタ・アドオンの構成を参照してください。
   5. クラスタ・タグをクラスタに追加するかどうか、初期ロード・バランサ・タグをタイプLoadBalancerのKubernetesサービスによって作成されたロード・バランサに追加するか、初期ブロック・ボリューム・タグをKubernetes永続ボリューム要求によって作成されたブロック・ボリュームに追加するかを指定します。Taggingを使用すると、コンパートメント間で様々なリソースをグループ化し、独自のメタデータでリソースに注釈を付けることができます。Kubernetesクラスタ関連リソースのタグ付けを参照してください。

7. 「次」をクリックし、「ネットワーク設定」ページで新しいクラスタに使用する既存のネットワーク・リソースを指定します:

   • ネットワーク・タイプ:クラスタ内のノードで実行されているポッドが、クラスタのコントロール・プレーン・ノード、他のクラスタ上のポッド、他のサービス(ストレージ・サービスなど)およびインターネット(ポッド・ネットワーキングを参照)と通信する方法を指定します。次のいずれかのオプションを選択します:
     • VCNネイティブ・ポッド・ネットワーキング: KubernetesクラスタのノードをOracle Cloud Infrastructure VCNのサブネットにポッド接続するには、このオプションを選択します。その結果、VCN内のポッドIPアドレスは、VCN、オンプレミス・ネットワークおよびインターネットに接続されている他のVCNから直接ルーティング可能になります(ピアリングされている)。このオプションを選択した場合、仮想ノードと管理対象ノードの両方を作成できます。ポッド・ネットワーク用のOCI VCNネイティブ・ポッド・ネットワークCNIプラグインの使用を参照してください。
     • Flannel Overay: IPアドレスをコンテナにアタッチすることでKubernetesネットワーキング・モデルの要件を満たす単純なプライベート・オーバーレイ仮想ネットワークであるflannel Overayネットワーク内のポッド間の通信をカプセル化するには、このオプションを選択します。プライベート・オーバーレイ・ネットワークのポッドには、同じクラスタ内の他のポッドからのみアクセスできます。このオプションを選択した場合、(仮想ノードではなく)管理対象ノードを作成できます。ポッド・ネットワーク用のフラッシュチャネルCNIプラグインの使用を参照してください。
   • <compartment-name>内のVCN: クラスタの作成およびデプロイメント用に構成された既存の仮想クラウド・ネットワーク。デフォルトでは、<compartment-name>はクラスタを作成しているコンパートメントですが、「コンパートメントの変更」をクリックして別のコンパートメントを選択することもできます。VCNの構成を参照してください。

   • <compartment-name>のKubernetesサービスLBサブネット: オプションで、ロード・バランサをホストするように構成された既存のサブネット。ロード・バランサ・サブネットは、ワーカー・ノード・サブネットとは異なる必要があり、パブリックまたはプライベートにすることも、リージョナル(推奨)またはAD固有にすることもできます。ロード・バランサ・サブネットを指定する必要はありません。ただし、ロード・バランサ・サブネットを指定する場合、指定するロード・バランサ・サブネットの数は、クラスタを作成するリージョン、およびサブネットがリージョナルかAD固有のものかどうかによって異なります。

     3つの可用性ドメインを持つリージョンにクラスタを作成する場合は、次を指定できます:

     • 0または1つのロード・バランサのリージョナル・サブネット(推奨)。
     • 0または2つのロード・バランサのAD固有のサブネット。2つのAD固有のサブネットを指定する場合、2つのサブネットは異なる可用性ドメインに存在する必要があります。

     1つの可用性ドメインを持つリージョンにクラスタを作成する場合は、次を指定できます:

     • 0または1つのロード・バランサのリージョナル・サブネット(推奨)。
     • 0または1つのロード・バランサのAD固有のサブネット。

     サブネットの構成を参照してください。

   • <compartment-name>内のKubernetes APIエンドポイント・サブネット: クラスタのKubernetes APIエンドポイントをホストするリージョン別サブネット。指定するサブネットは、パブリックでもプライベートでもかまいません。Kubernetes APIエンドポイントには常にプライベートIPアドレスが割り当てられます。パブリック・サブネットを指定する場合、パブリックIPアドレス(およびプライベートIPアドレス)をエンドポイントに割り当てることで、Kubernetes APIエンドポイントをインターネットにオプションで公開できます。アクセス管理を簡素化するために、Kubernetes APIエンドポイントをワーカー・ノードおよびロード・バランサとは異なるサブネットに配置することをお薦めします。詳細は、Kubernetesクラスタ・コントロール・プレーンおよびKubernetes APIを参照してください。
   • ネットワーク・セキュリティ・グループ(NSG)内のセキュリティ・ルールを使用: 指定した1つ以上のネットワーク・セキュリティ・グループ(NSG)に対して定義されたセキュリティ・ルールを使用して、クラスタのKubernetes APIエンドポイントへのアクセスを制御します。NSGに対して定義されたセキュリティ・ルールは、セキュリティ・リストに対して定義されたセキュリティ・ルールではなく、またはNSGに対して定義されたセキュリティ・ルールを使用することもできます(NSGをお薦めします)。NSGに指定するセキュリティ・ルールの詳細は、Kubernetes APIエンドポイントのセキュリティ・ルールを参照してください。
   • APIエンドポイントへのパブリックIPアドレスの割当て: Kubernetes APIエンドポイントにパブリック・サブネットを選択した場合、エンドポイントにパブリックIPアドレスを割り当てることで、オプションでエンドポイントをインターネットに公開できます。パブリックIPアドレスを割り当てない場合は、サービス・ゲートウェイおよびNATゲートウェイを使用してエンドポイントへのアクセスを有効にするルート・ルールおよびセキュリティ・ルールを更新します(Kubernetes APIエンドポイント・サブネット構成を参照)。

8. 拡張クラスタ・オプションのデフォルトを受け入れるか、「拡張オプションの表示」をクリックして、次のようにかわりのオプションを指定します:

   • KubernetesサービスCIDRブロック: Kubernetesサービス(ClusterIPs)として公開できるネットワーク・アドレスの使用可能なグループであり、単一の連続したIPv4 CIDRブロックとして表されます。例: 10.96.0.0/16指定するCIDRブロックは、VCNのCIDRブロックと重複することはできません。CIDRブロックおよびContainer Engine for Kubernetesを参照してください。
   • ポッドCIDRブロック: クラスタで実行されているポッドに割り当てることができるネットワーク・アドレスの使用可能なグループであり、単一の連続IPv4 CIDRブロックとして表されます。例: 10.244.0.0/16指定するCIDRブロックは、VCN内のサブネットのCIDRブロックと重複してはならず、VCN CIDRブロックの外にあってもかまいません。クラスタのネットワーク・タイプとしてVCNネイティブ・ポッド・ネットワーキングを選択した場合は、CIDRブロックを指定しないでください。CIDRブロックおよびContainer Engine for Kubernetesを参照してください。

9. 「次」をクリックし、「ノード・プール」ページでクラスタ内の最初のノード・プールの構成詳細を指定します:

   • 名前: 新しいノード・プールに選択した名前。機密情報を入力しないでください。
   • コンパートメント:新しいノード・プールを作成するコンパートメント。
   • ノード・タイプ: 「VCNネイティブ・ポッド・ネットワーキング」を「ネットワーク・タイプ」として選択した場合は、このノード・プールのワーカー・ノードのタイプを指定します(仮想ノードと管理対象ノードを参照)。次のいずれかのオプションを選択します:
     • 管理対象: ノード・プール内のワーカー・ノードの管理を担当する場合は、このオプションを選択します。管理対象ノードは、テナンシのコンピュート・インスタンス(ベア・メタルまたは仮想マシン)で実行されます。管理対象ノードの管理を担当しているため、特定の要件を満たすように柔軟に構成できます。管理対象ノードのKubernetesのアップグレードおよびクラスタ容量の管理は、ユーザーの責任となります。
     • 仮想: サーバーレスKubernetesエクスペリエンスの利点を享受する場合は、このオプションを選択します。仮想ノードを使用すると、データ・プレーン・インフラストラクチャのアップグレードおよびクラスタの容量の管理の運用オーバーヘッドなしで、Kubernetesポッドを大規模に実行できます。

     詳細は、管理対象ノードとの仮想ノードの比較を参照してください。

   • バージョン: (管理対象ノード・プールのみ)管理対象ノード・プール内の各管理対象ノードで実行されるKubernetesのバージョン。デフォルトでは、コントロール・プレーン・ノードに指定されたKubernetesのバージョンが選択されます。ワーカー・ノードのKubernetesバージョンは、コントロール・プレーン・ノードのバージョンと同じであるか、まだ互換性のある以前のバージョンである必要があります。KubernetesのバージョンとContainer Engine for Kubernetesを参照してください。

     ワーカー・ノードにOKEイメージを指定する場合、ここで選択するKubernetesバージョンは、OKEイメージのKubernetesのバージョンと同じである必要があります。

10. 「ネットワーク・タイプ」として「VCNネイティブ・ポッド・ネットワーキング」を選択し、「ノード・タイプ」として「管理対象」を選択した場合、または「ネットワーク・タイプ」として「フラッシュ・オーバーレイ: 」を選択した場合は、次のようになります:

    1. 管理対象ノード・プールの構成の詳細を指定します。
       • ノード配置構成:
         • 可用性ドメイン:ワーカー・ノードを配置する可用性ドメイン。
         • ワーカー・ノード・サブネット:ワーカー・ノードをホストするように構成されたリージョン・サブネット(推奨)またはAD固有のサブネット。ロード・バランサ・サブネットを指定した場合、ワーカー・ノード・サブネットは異なる必要があります。指定するサブネットは、プライベート(推奨)またはパブリックです。サブネットの構成を参照してください。
         • フォルト・ドメイン: (オプション)ワーカー・ノードを配置する可用性ドメイン内の1つ以上のフォルト・ドメイン。

         オプションで、「拡張オプションの表示」をクリックして、使用する容量タイプを指定します(ワーカー・ノードの容量タイプの管理を参照)。容量予約を指定する場合、管理対象ノード・プールの配置構成のノード・シェイプ、可用性ドメインおよびフォルト・ドメインは、それぞれ容量予約のインスタンス・タイプ、可用性ドメインおよびフォルト・ドメインと一致している必要があります。容量予約を使用した管理対象ノードのプロビジョニングを参照してください。

         オプションで「別の行」をクリックして、ワーカー・ノードを配置する追加のドメインおよびサブネットを選択します。

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

       • ノード・シェイプ: 管理対象ノード・プールのワーカー・ノードに使用するシェイプ。シェイプによって、各管理対象ノードに割り当てるCPU数とメモリー容量が決まります。

         Container Engine for Kubernetesでサポートされているテナンシで使用可能なシェイプのみが表示されます。

         フレキシブル・シェイプを選択した場合は、CPUの数とメモリー量を明示的に指定できます。

         「ワーカー・ノードにサポートされているイメージ(カスタム・イメージを含む)およびシェイプ」を参照してください。

       • イメージ: 管理対象ノード・プールのワーカー・ノードで使用するイメージ。イメージは、オペレーティング・システムとその他の管理対象ノード・プール用ソフトウェアを決定する仮想ハード・ドライブのテンプレートです。

         デフォルトのイメージを変更するには、「イメージの変更」をクリックします。「すべてのイメージの参照」ウィンドウで、イメージ・ソースを選択し、次のようにイメージを選択します:

         • OKEワーカー・ノードのイメージ: 推奨。Oracleによって提供され、プラットフォーム・イメージの上に構築されます。OKEイメージは、必要なすべての構成および必要なソフトウェアとともに、ワーカー・ノードのベース・イメージとして機能するように最適化されています。プラットフォーム・イメージおよびカスタム・イメージと比較して、実行時にワーカー・ノードのプロビジョニングにかかる時間を最小限に抑える場合は、OKEイメージを選択します。

           OKEイメージ名には、含まれているKubernetesバージョンのバージョン番号が含まれます。ノード・プールのKubernetesバージョンを指定する場合、ここで選択するOKEイメージのバージョン番号はノード・プールのKubernetesバージョンと同じである必要があります。

         • プラットフォーム・イメージ: Oracleで提供され、Oracle Linuxオペレーティング・システムのみが含まれます。ワーカー・ノードをホストしているコンピュート・インスタンスが初めてブートするときに、Container Engine for Kubernetesで必要なソフトウェアをダウンロード、インストールおよび構成する場合は、プラットフォーム・イメージを選択します。

         「ワーカー・ノードにサポートされているイメージ(カスタム・イメージを含む)およびシェイプ」を参照してください。

       • ノード数:選択した可用性ドメイン、および各可用性ドメインに指定したリージョナル・サブネット(推奨)またはAD固有のサブネットに配置された、管理対象ノード・プールに作成するワーカー・ノードの数。
       • ネットワーク・セキュリティ・グループ(NSG)内のセキュリティ・ルールの使用:指定した1つ以上のネットワーク・セキュリティ・グループ(NSG)に定義されたセキュリティ・ルールを使用して、ノード・プールへのアクセスを制御します(最大5つ)。NSGに対して定義されたセキュリティ・ルールは、セキュリティ・リストに対して定義されたセキュリティ・ルールではなく、または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では、セキュリティ・リストではなくネットワーク・セキュリティ・グループにセキュリティ・ルールを定義することをお薦めします)。サブネットの構成を参照してください。
         • ネットワーク・セキュリティ・グループ(NSG)内のセキュリティ・ルールの使用:指定した1つ以上のネットワーク・セキュリティ・グループ(NSG)に定義されたセキュリティ・ルールを使用してポッド・サブネットへのアクセスを制御します(最大5つ)。NSGに対して定義されたセキュリティ・ルールは、セキュリティ・リストに対して定義されたセキュリティ・ルールではなく、またはNSGに対して定義されたセキュリティ・ルールを使用することもできます(NSGをお薦めします)。NSGに指定するセキュリティ・ルールの詳細は、ワーカー・ノードおよびポッドのセキュリティ・ルールを参照してください。

         オプションで、「拡張オプションの表示」をクリックして、管理対象ノード・プール内の1つのワーカー・ノードで実行するポッドの最大数を110まで指定します。Kubernetesには110の制限が課されています。単一のワーカー・ノードに31個を超えるポッドが必要な場合は、ノード・プールに指定するシェイプで、3つ以上のVNIC (ワーカー・ノード・サブネットに接続する1つのVNIC、ポッド・サブネットに接続する2つ以上のVNIC)をサポートする必要があります。異なるシェイプでサポートされているVNICおよびポッドの最大数を参照してください。

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

    2. 拡張管理対象ノード・プール・オプションのデフォルトを受け入れるか、「拡張オプションの表示」をクリックして、次のようにかわりのオプションを指定します:

       • Cordonおよびdrain:管理対象ノードを終了する前に、ノードをコード化およびドレインするタイミングと方法を指定します。

         • 削除猶予期間(分):ワーカー・ノードを終了する前にワーカー・ノードをコード化およびドレインできる時間の長さ。デフォルト(60分)を受け入れるか、代替を指定します。たとえば、ノード・プールをスケール・ダウンしたり、配置構成を変更する場合、ワーカー・ノードをコード化し、ワークロードを排出するのに30分かかることがあります。ワーカー・ノードをコード化およびドレインせずにただちに終了するには、0分を指定します。
         • 猶予期間後に強制終了:ワーカー・ノードが正常にコード化およびドレインされていない場合でも、削除猶予期間の終了時にワーカー・ノードを終了するかどうか。デフォルトでは、このオプションは選択されていません。

           ワーカー・ノードが正常にコード化およびドレインされていない場合でも、削除猶予期間の終了時にワーカー・ノードを常に終了させる場合は、このオプションを選択します。

           正常にコード化およびドレインされていないワーカー・ノードを削除猶予期間の終了時に終了させない場合は、このオプションの選択を解除します。削除猶予期間内に終了できないワーカー・ノードを含むノード・プールは、「注意が必要」ステータスになります。終了操作を開始した作業リクエストのステータスは「失敗」に設定され、終了操作は取り消されます。詳細は、クラスタの監視を参照してください。

         詳細は、「終了前の管理対象ノードのコード化と排出に関するノート」を参照してください。

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

         Container Engine for Kubernetesによって作成されたクラスタでワーカー・ノードを初期化するための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を参照)。
       • ノード・プール・タグおよびノード・タグ: (オプション)ノード・プールに追加する1つ以上のタグと、ノード・プール内のワーカー・ノードをホストするコンピュート・インスタンス。Taggingを使用すると、コンパートメント間で様々なリソースをグループ化し、独自のメタデータでリソースに注釈を付けることができます。Kubernetesクラスタ関連リソースのタグ付けを参照してください。
       • 公開SSHキー: (オプション)ノード・プールの各ノードへのSSHアクセスに使用するキー・ペアの公開キー部分。公開キーは、クラスタ内のすべてのワーカー・ノードにインストールされます。公開SSHキーを指定しない場合、Container Engine for Kubernetesによって提供されることに注意してください。ただし、対応する秘密キーがないため、ワーカー・ノードへのSSHアクセスはできません。SSHを使用してプライベート・サブネットのワーカー・ノードに直接アクセスすることはできません(SSHを使用したプライベート・サブネットの管理対象ノードへの接続を参照)。

11. 「ノード・タイプ」として「仮想」を選択した場合は、次のようになります。

    1. 仮想ノード・プールの構成詳細を指定します。
       • ノード数:選択した可用性ドメイン、および各可用性ドメインに指定したリージョン・サブネット(推奨)またはAD固有のサブネットに配置される、仮想ノード・プールに作成する仮想ノードの数。

       • ポッド・シェイプ: 仮想ノード・プールの仮想ノードで実行されているポッドに使用するシェイプ。シェイプによって、ポッドを実行するプロセッサ・タイプが決まります。

         Container Engine for Kubernetesでサポートされているテナンシで使用可能なシェイプのみが表示されます。「ワーカー・ノードにサポートされているイメージ(カスタム・イメージを含む)およびシェイプ」を参照してください。

         ポッド仕様で仮想ノードのCPUおよびメモリー・リソース要件を明示的に指定します(Kubernetesドキュメントのコンテナおよびポッドへのメモリー・リソースの割当ておよびコンテナおよびポッドへのCPUリソースの割当てを参照)。

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

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

       • 仮想ノード通信:
         • サブネット:仮想ノードをホストするように構成されたリージョン別サブネット(推奨)またはAD固有のサブネット。ロード・バランサ・サブネットを指定した場合、仮想ノード・サブネットは異なる必要があります。指定できるサブネットは、プライベート(推奨)またはパブリックで、リージョン(推奨)またはAD固有です。ポッド・サブネットと仮想ノード・サブネットは同じサブネットにすることをお薦めします(この場合、仮想ノード・サブネットはプライベートである必要があります)。サブネットの構成を参照してください。
       • ノード配置構成:
         • 可用性ドメイン:仮想ノードを配置する可用性ドメイン。
         • フォルト・ドメイン: (オプション)仮想ノードを配置する可用性ドメイン内の1つ以上のフォルト・ドメイン。

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

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

    2. 拡張仮想ノード・プール・オプションのデフォルトを受け入れるか、「拡張オプションの表示」をクリックして、次のようにかわりのオプションを指定します:

       • ノード・プール・タグ: (オプション)仮想ノード・プールに追加する1つ以上のタグ。Taggingを使用すると、コンパートメント間で様々なリソースをグループ化し、独自のメタデータでリソースに注釈を付けることができます。Kubernetesクラスタ関連リソースのタグ付けを参照してください。
       • Kubernetesのラベルおよびヒント: (オプション)仮想ノードにラベルおよびヒントを追加して、特定のノード・プールでワークロードのターゲット設定を有効にします:
         • ラベル: 仮想ノード・プールの仮想ノードに追加する(デフォルト・ラベルに加えて)1つ以上のラベルで、特定のノード・プールでのワークロードのターゲット設定を有効にします。
         • 表: 仮想ノード・プールの仮想ノードに追加する1つ以上の表。Taintsを使用すると、仮想ノードはポッドをリペルできるため、ポッドは特定の仮想ノード・プールの仮想ノードで実行されません。taintは仮想ノードにのみ適用できます。

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

12. (オプション) 「別のノード・プール」をクリックし、クラスタ内の2番目以降のノード・プールの構成の詳細を指定します。

    クラスタに複数のノード・プールを定義すると、それらすべてを単一のAD固有のサブネット上でホストできます。ただし、リージョナル・サブネット(推奨)または異なるAD固有のサブネット(リージョンの各可用性ドメインに1つ)でクラスタの異なるノード・プールをホストすることがベスト・プラクティスです。

13. 「次」をクリックして、新しいクラスタ用に入力した詳細を確認します。
14. 拡張クラスタ機能を選択していない場合に、拡張クラスタではなく基本クラスタとして新規クラスタを作成する場合は、「確認」ページで「基本クラスタの作成」オプションを選択します。拡張クラスタおよび基本クラスタの操作を参照してください。

15. 「クラスタの作成」をクリックして、すぐに新しいクラスタを作成します。

    Container Engine for Kubernetesは、指定した名前でクラスタの作成を開始します。

    1つ以上のノード・プールの詳細を指定した場合、Container Engine for Kubernetesは次を作成します:

    • 指定した名前のノード・プール
    • 自動生成された名前を持つワーカー・ノード(管理対象ノード名の形式はoke-c<part-of-cluster-OCID>-n<part-of-node-pool-OCID>-s<part-of-subnet-OCID>-<slot>、仮想ノード名はノードのプライベートIPアドレスと同じ)

    ワーカー・ノードの自動生成された名前は変更しないでください。

    新しいクラスタをすぐに作成するのではなく、「スタックとして保存」をクリックしてリソース定義をTerraform構成として保存することで、リソース・マネージャおよびTerraformを使用して後で作成できます。リソース定義からのスタックの保存の詳細は、「リソース作成ページからのスタックの作成」を参照してください。

16. 「閉じる」をクリックしてコンソールに戻ります。

最初に、新しいクラスタが、「作成中」ステータスでコンソールに表示されます。クラスタが作成されると、そのステータスは「アクティブ」になります。

Container Engine for Kubernetesでは、kubectlを使用してクラスタにアクセスするために使用するKubernetes kubeconfig構成ファイルも作成されます。