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

「カスタム作成」ワークフローを使用して、Kubernetesエンジン(OKE)を使用して明示的に定義した設定および既存のネットワーク・リソースでKubernetesクラスタを作成する方法を確認してください。

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

1. 「クラスタ」リスト・ページで、「クラスタの作成」を選択します。リスト・ページの検索に関するヘルプが必要な場合は、クラスタのリストを参照してください。
2. 「クラスタの作成」ダイアログで、カスタム作成を選択し、「続行」を選択します。

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

   • 名前: 新しいクラスタの名前。デフォルトの名前をそのまま使用するか、名前を入力します。機密情報の入力は避けてください。
   • コンパートメント: 新規クラスタを作成するコンパートメント。

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

     使用可能なKubernetesバージョン番号は、x.y形式で表示されます。ここで、xはメジャー・バージョン、yはマイナー・バージョンです。x.y形式でKubernetesバージョンを選択した後、オプションで「パッチ・バージョンの表示」を選択し、選択したmajor.minorバージョンに対してサポートされているパッチ・バージョンを指定できます。ただし、Kubernetesエンジンがマイナー・バージョンに対してサポートされている最新のパッチ・バージョンを自動的に選択できるようにするには、x.y形式のKubernetesバージョンを選択するのみをお薦めします。詳細は、KubernetesバージョンおよびKubernetes Engine (OKE)を参照してください。

     Kubernetesバージョンのリストには、早期アクセス・テストおよび検証の目的でのみ提供されるプレビュー・バージョンが含まれています。これらのプレビュー・バージョンには、パッチ・バージョン番号として.0があります(たとえば、1.34.0)。プレビュー・バージョンは本番ワークロード向けではなく、既知の問題を含む場合があります。本番ワークロードにプレビュー・バージョンを使用することはお薦めしません。

4. 拡張クラスタ・オプションのデフォルトを受け入れるか、「拡張オプション」を選択して、次のようにオプションを設定します。

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

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

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

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

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

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

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

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

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

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

      • 新しいクラスタを作成するたびに、ポッド・セキュリティ・アドミッション・コントローラを有効にします。
      • 新しいクラスタを作成したら、ただちにロール(またはclusterrole)およびロール・バインディング(またはclusterrolebinding)とともにポッド・セキュリティ・ポリシーを作成します。
   4. クラスタ・アドオンの構成: (拡張クラスタのみ)特定のアドオンを有効化または無効化し、アドオンのバージョンを選択し、Oracleによる自動更新のオプト・インおよびオプト・アウトを行い、アドオン固有のカスタマイズを管理します。クラスタ・アドオンの横にある「アクション」メニュー(3つのドット)から「編集」を選択し、必要に応じて構成オプションを設定します。クラスタ・アドオンの構成を参照してください。
   5. OpenID Connect (OIDC)検出: (拡張クラスタのみ) OIDC検出に対してクラスタを有効にするかどうかを指定します。「OIDC検出の有効化」を選択して、外部クラウド・プロバイダでホストされているAPIにアクセスするときに、クラスタで実行されているアプリケーション・ポッドがOIDC検出を使用して認証されるようにします。OpenID Connect (OIDC)検出を使用したOCI以外のリソースにアクセスするためのポッドの認可を参照してください。
   6. タグ付け: クラスタ・タグをクラスタに追加するかどうか、初期ロード・バランサ・タグをタイプLoadBalancerのKubernetesサービスによって作成されたロード・バランサに追加するか、初期ブロック・ボリューム・タグをKubernetes永続ボリューム要求によって作成されたブロック・ボリュームに追加します。タグ付けにより、コンパートメント間で異なるリソースをグループ化でき、独自のメタデータを使用してリソースに注釈を付けることもできます。Kubernetesクラスタ関連リソースのタグ付けを参照してください。

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

   • ネットワーク・タイプ:クラスタ内のノードで実行されているポッドが、クラスタのコントロール・プレーン・ノード、他のクラスタ上のポッド、他のサービス(ストレージ・サービスなど)、およびインターネットとの通信方法を指定します(ポッド・ネットワーキングを参照)。次のいずれかのオプションを選択します:
     • VCNネイティブ・ポッド・ネットワーキング: Kubernetesクラスタ内のノードをOracle Cloud Infrastructure VCN内のポッド・サブネットに接続するには、このオプションを選択します。As a result, pod IP addresses within a VCN are directly routable from other VCNs connected (peered) to that VCN, and from on-premise networks. このオプションを選択した場合、仮想ノードと管理対象ノードの両方を作成できます。「ポッド・ネットワーク用のOCI VCNネイティブ・ポッド・ネットワークCNIプラグインの使用」を参照してください。
     • Flannelオーバーレイ:このオプションを選択すると、flannelオーバーレイ・ネットワーク内のポッド間の通信がカプセル化されます。これは、IPアドレスとコンテナをアタッチすることでKubernetesネットワーキング・モデルの要件を満たす単純なプライベート・オーバーレイ仮想ネットワークです。プライベート・オーバーレイ・ネットワークのポッドには、同じクラスタ内の他のポッドからのみアクセスできます。このオプションを選択すると、(仮想ノードではなく)管理対象ノードを作成できます。「ポッド・ネットワーク用のflannel CNIプラグインの使用」を参照してください。
   • VCN:指定したコンパートメント内のVCNsのリストから、クラスタの作成およびデプロイメント用に構成された既存の仮想クラウド・ネットワークを選択します。デフォルトでは、コンパートメントはクラスタを作成しているものですが、異なるコンパートメントを選択することもできます。VCNの構成を参照してください。
   • 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エンドポイントのセキュリティ・ルールを参照してください
   • パブリックIPv4アドレスの自動割当て: Kubernetes APIエンドポイントのパブリック・サブネットを選択した場合は、エンドポイントにパブリックIPアドレスを割り当てることで、オプションでエンドポイントをインターネットに公開できます。パブリックIPアドレスを割り当てない場合は、ルート・ルールおよびセキュリティ・ルールを更新して、サービス・ゲートウェイおよびNATゲートウェイを使用したエンドポイントへのアクセスを有効にします(Kubernetes APIエンドポイント・サブネットの構成を参照)。
   • サブネット接頭辞からIPv6アドレスを自動的に割り当てます: Kubernetes APIエンドポイントにIPv4/IPv6デュアル・スタック・サブネットを選択した場合は、オプションでIPv6アドレスをエンドポイントに割り当てて、クラスタをデュアル・スタック・クラスタにできます。このオプションを選択すると、サブネットに割り当てられた最初のIPv6接頭辞から、エンドポイントのIPv6アドレスが自動的に選択されます。詳細は、「IPv4およびIPv6に対するクラスタの有効化」を参照してください。

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

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

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

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

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

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

6. 拡張ネットワーク・オプションのデフォルトを受け入れるか、「拡張オプション」を選択して、次のようにかわらのオプションを指定します:

   • エンドポイント・セキュリティ属性:クラスタのKubernetes APIエンドポイントに追加する1つ以上の(最大5つ) ZPRセキュリティ属性。

     リソースを作成する権限がある場合、そのリソースにセキュリティ属性を追加する権限もあります。セキュリティ属性を追加するには、セキュリティ属性ネームスペースを使用する権限が必要です。セキュリティ属性およびセキュリティ属性ネームスペースの詳細は、Zero Trust Packet Routingを参照してください。セキュリティ属性を追加するかどうかわからない場合は、このオプションをスキップするか、管理者に問い合せてください。セキュリティ属性は後で追加できます。

     クラスタ関連リソースへのセキュリティ属性の追加およびZPRポリシーの適用も参照してください

   • KubernetesサービスCIDRブロック: Kubernetesサービス(ClusterIPs)として公開できるIPv4ネットワーク・アドレスの使用可能なグループであり、単一の連続したIPv4 CIDRブロックとして表されますたとえば、10.96.0.0/16です。指定するIPv4 CIDRブロックは、VCNのIPv4 CIDRブロックと重複することはできません。デュアル・スタック・クラスタの場合は、KubernetesサービスのIPv6接頭辞を指定することもできます。「IPv4 CIDRブロックおよびKubernetesエンジン(OKE)」を参照してください。
   • KubernetesサービスのIPv6接頭辞: デュアル・スタック・クラスタを作成する場合、Kubernetesサービス(ClusterIPs)として公開できるIPv6ネットワーク・アドレスの使用可能なグループであり、単一の連続したIPv6 CIDRブロックとして表されます。たとえば、fd00:eeee:eeee:0001::/108です。指定するIPv6 CIDRブロックは、VCNのIPv6 CIDRブロックと重複することはできません。デュアル・スタック・クラスタの場合は、KubernetesサービスCIDRブロックを指定することもできます。「IPv4およびIPv6に対するクラスタの有効化」を参照してください。
   • ポッドCIDRブロック: 「ネットワーク・タイプ」として「チャネル・オーバーレイ: 」を選択した場合、クラスタで実行されているポッドに割り当てることができるネットワーク・アドレスの使用可能なグループであり、単一の連続したIPv4 CIDRブロックとして表されます. たとえば、10.244.0.0/16です。指定するCIDRブロックは、VCN内のサブネットのCIDRブロックと重複してはならず、VCN CIDRブロックの外にあってもかまいません。デュアル・スタック・クラスタの場合は、IPv4 CIDRブロックとIPv6 CIDRブロックの両方を指定できます(カンマ区切り)。VCNネイティブ・ポッド・ネットワーキングをクラスタのネットワーク・タイプとして選択した場合、CIDRブロックを指定しないでください。「IPv4 CIDRブロックおよびKubernetesエンジン(OKE)」を参照してください。

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

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

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

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

     使用可能なKubernetesバージョン番号は、x.y形式で表示されます。ここで、xはメジャー・バージョン、yはマイナー・バージョンです。x.y形式でKubernetesバージョンを選択した後、オプションで「パッチ・バージョンの表示」を選択し、選択したmajor.minorバージョンに対してサポートされているパッチ・バージョンを指定できます。ただし、Kubernetesエンジンがマイナー・バージョンに対してサポートされている最新のパッチ・バージョンを自動的に選択できるようにするには、x.y形式のKubernetesバージョンを選択するのみをお薦めします。詳細は、KubernetesバージョンおよびKubernetes Engine (OKE)を参照してください。

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

     Kubernetesバージョンのリストには、早期アクセス・テストおよび検証の目的でのみ提供されるプレビュー・バージョンが含まれています。これらのプレビュー・バージョンには、パッチ・バージョン番号として.0があります(たとえば、1.34.0)。プレビュー・バージョンは本番ワークロード向けではなく、既知の問題を含む場合があります。本番ワークロードにプレビュー・バージョンを使用することはお薦めしません。

8. 「ネットワーク・タイプ」として「VCNネイティブ・ポッド・ネットワーキング」を選択し、「ノード・タイプ」として「管理対象」を選択した場合、または「ネットワーク・タイプ」として「チャネル・オーバーレイ: 」を選択した場合:

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

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

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

        ノード・プールがコンピュート・クラスタを使用する場合は、フォルト・ドメインを指定しないでください。管理対象ノード・プール内のすべてのワーカー・ノードは、コンピュート・クラスタを含む可用性ドメインに作成されます。コンピュート・クラスタを使用した管理対象ノードのプロビジョニングを参照してください。

      • ネットワーク起動タイプ: 必要に応じて、ワーカー・ノード・ネットワーキングのネットワーク起動タイプを選択します。値を選択しない場合、PARAVIRTUALIZEDがデフォルトとして使用されます。

        ほとんどの場合、「PARAVIRTUALIZED」を選択します。選択したシェイプおよびイメージがハードウェア支援のSR-IOVネットワークをサポートし、ワークロードで必要な場合にのみ、「VFIO」を選択します。準仮想化ネットワークをサポートしないイメージまたはワークロードとの互換性のために必要な場合にのみ、「E1000」を選択します。各起動タイプのサポートは、選択したコンピュート・シェイプおよびイメージによって異なります。

      • プライマリVNIC: (VCNネイティブ・ポッド・ネットワーキングのみ)オプションで、ノード・プール内のワーカー・ノードのプライマリVNICに追加する1つ以上の(最大5つ) ZPRセキュリティ属性を指定します。

        リソースを作成する権限がある場合、そのリソースにセキュリティ属性を追加する権限もあります。セキュリティ属性を追加するには、セキュリティ属性ネームスペースを使用する権限が必要です。セキュリティ属性およびセキュリティ属性ネームスペースの詳細は、Zero Trust Packet Routingを参照してください。セキュリティ属性を追加するかどうかわからない場合は、このオプションをスキップするか、管理者に問い合せてください。セキュリティ属性は後で追加できます。

        クラスタ関連リソースへのセキュリティ属性の追加およびZPRポリシーの適用も参照してください

      • ノードのセカンダリVNICの構成: (VCNネイティブ・ポッド・ネットワーキングのみ)オプションで、1つ以上のセカンダリVNICを定義します。詳細は、ポッド・ネットワーキングのための複数のセカンダリVNICのアタッチを参照してください。

      • ノード・シェイプ: 管理対象ノード・プールのワーカー・ノードに使用するシェイプ。シェイプによって、各管理対象ノードに割り当てるCPU数とメモリー量を決定します。デフォルトのシェイプを変更するには、「シェイプの変更」を選択します。

        Kubernetes Engineでサポートされているテナンシで使用可能なシェイプのみが表示されます。フレキシブル・シェイプを選択した場合は、CPUの数とメモリー量を明示的に指定できます。「ワーカー・ノードにサポートされているイメージ(カスタム・イメージを含む)およびシェイプ」を参照してください。

        管理対象ノード・プールにコンピュート・クラスタを指定する場合、RDMAおよびコンピュート・クラスタをサポートするノード・シェイプを選択します。コンピュート・クラスタを使用した管理対象ノードのプロビジョニングを参照してください。

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

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

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

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

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

          Kubernetesバージョン1.35 (以降)を実行しているクラスタでは、プラットフォーム・イメージ(OL7プラットフォーム・イメージとOL8プラットフォーム・イメージの両方)の使用はお薦めしません。すべての新規デプロイメントおよびアップグレードにOKEイメージを使用することを強くお薦めします。

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

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

        オプションで、「拡張オプション」を選択して、管理対象ノード・プール内の1つのワーカー・ノードで実行するポッドの最大数(最大256)を指定します。256の制限は、ワーカー・ノードに割り当てることができるIPアドレスの最大数です。十分なVNICアタッチメントをサポートするシェイプを選択し、セカンダリVNICプロファイルに構成されたipCount値を使用してポッドIP容量が適切にサイズ設定されていることを確認します。セカンダリVNICプロファイルでアプリケーション・リソースを定義する場合、ポッドは単一のアプリケーション・リソースに、選択した1つのプロファイルに固定するようにリクエストでき、ノード・テイントに必要な許容範囲を含める必要があります。マルチインタフェース・ポッドをデプロイする場合は、MultusおよびNADを使用して追加のインタフェースをアタッチし、Multusネットワーク注釈を同じポッド仕様のポッド・レベルのアプリケーション・リソース・リクエストと組み合せないでください。詳細は、異なるシェイプでサポートされるVNICおよびポッドの最大数およびポッド・ネットワーキングのための複数のセカンダリVNICのアタッチを参照してください。

        アプリケーション・リソースを公開するノード・プールは、明示的なアプリケーション・リソース・リクエストのないポッドがそれらのノードでスケジューリングされないように汚染されます。アプリケーション・リソースをリクエストするポッドには、一致する許容範囲を含める必要があります。

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

   2. 拡張管理対象ノード・プール・オプションのデフォルトを受け入れるか、「拡張オプション」を選択して、次のように代替を指定します。

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

        • 削除猶予期間(分):ワーカー・ノードを停止または終了する前に、ワーカー・ノードをコード化およびドレインできる時間の長さ。デフォルト(最大値である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を参照)。
      • ノード・プール・タグおよびノード・タグ: (オプション)ノード・プールに追加する1つ以上のタグ、およびノード・プール内のワーカー・ノードをホストするコンピュート・インスタンス。タグ付けにより、コンパートメント間で異なるリソースをグループ化でき、独自のメタデータを使用してリソースに注釈を付けることもできます。Kubernetesクラスタ関連リソースのタグ付けを参照してください。
      • SSHキーの追加: (オプション)キー・ペアを生成するか、またはノード・プールの各ノードへのSSHアクセスに使用するキー・ペアの公開キー部分をアップロードします。公開キーは、クラスタ内のすべてのワーカー・ノードにインストールされます。公開SSHキーを指定しない場合、Kubernetes Engineによって公開SSHキーが提供されます。ただし、対応する秘密キーがないため、ワーカー・ノードへのSSHアクセスはできません。SSHを使用して、プライベート・サブネット内のワーカー・ノードに直接アクセスすることはできません(SSHを使用したプライベート・サブネットの管理対象ノードへの接続を参照)。
      • コンピュート・クラスタ: (オプション)管理対象ノード・プールのコンピュート・クラスタを指定します。コンピュート・クラスタを含むコンパートメントを選択し、コンピュート・クラスタを選択します。コンピュート・クラスタがアクティブである必要があります。管理対象ノード・プールの作成時にのみ、コンピュート・クラスタを指定できます。コンピュート・クラスタは後で追加、削除または変更できません。コンピュート・クラスタを使用した管理対象ノードのプロビジョニングを参照してください。

9. 「ノード・タイプ」として「仮想」を選択した場合:

   1. 仮想ノード・プールの構成詳細を指定します:
      • ノード配置構成:
        • 可用性ドメイン:仮想ノードを配置する可用性のドメイン。
        • フォルト・ドメイン: (オプション)仮想ノードを配置する可用性ドメイン内の1つ以上のフォルト・ドメイン。

        仮想ノードが作成されると、選択した可用性ドメインおよびフォルト・ドメイン間で可能なかぎり均等に分配されます。次の推奨事項を検討してください:

        • 「ノード数」を3つ以上に設定します。複数の可用性ドメインがあるリージョンでは、可用性ドメインにノードを分散します。単一の可用性ドメインを持つリージョンでは、フォルト・ドメイン全体にノードを分散します。
        • 使用可能なコンピュート容量を持つフォルト・ドメインで仮想ノードがポッドを作成できるようにするには、フォルト・ドメインを指定しないでください(つまり、フォルト・ドメインを空のままにします)。このアプローチは、配置に対するファイングレイン制御が不要で、潜在的な容量制約を回避する場合に推奨されます。
        • 高可用性をサポートするには、ノード配置構成に3行を指定します。複数の可用性ドメインがあるリージョンでは、可用性ドメインごとに1行あります。可用性ドメインが1つのリージョンでは、フォルト・ドメインごとに1行あります。
      • ノードの数:仮想ノード・プールに作成する仮想ノードの数。選択した可用性ドメイン、および各可用性ドメインに指定したリージョナルド・サブネット(推奨)またはAD固有のサブネットに配置される。

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

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

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

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

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

   2. 拡張仮想ノード・プール・オプションのデフォルトを受け入れるか、「拡張オプション」を選択して、次のように代替を指定します。

      • ノード・プール・タグ: (オプション)仮想ノード・プールに追加する1つ以上のタグ。タグ付けにより、コンパートメント間で異なるリソースをグループ化でき、独自のメタデータを使用してリソースに注釈を付けることもできます。Kubernetesクラスタ関連リソースのタグ付けを参照してください。
      • Kubernetesラベル: (オプション) (デフォルト・ラベルに加えて)仮想ノード・プールの仮想ノードに追加するための1つまたは複数のラベル。特定のノード・プールでワークロードのターゲットに設定できるようになります。詳細は、Kubernetesのドキュメントのノードへのポッドの割当てを参照してください。
      • Kubernetesテイント: (オプション)仮想ノード・プール内の仮想ノードに追加する1つ以上のテイント。塗料を使用すると、仮想ノードはポッドを再ペルできるため、ポッドが特定の仮想ノード・プールの仮想ノードで実行されないようにできます。taintは仮想ノードにのみ適用できることに注意してください。詳細は、Kubernetesのドキュメントのノードへのポッドの割当てを参照してください。
10. 「次」を選択して、新しいクラスタ用に入力した詳細を確認します。
11. 拡張クラスタ機能を選択していないときに、新しいクラスタを拡張クラスタとしてではなく基本クラスタとして作成する場合は、「確認および作成」ページで「基本クラスタの作成」オプションを選択します。拡張クラスタおよび基本クラスタの使用を参照してください。

12. 「クラスタの作成」を選択して、新しいクラスタを今すぐ作成します。

    Kubernetesエンジンは、指定した名前でクラスタの作成を開始します。

    1つ以上のノード・プールの詳細を指定すると、Kubernetesエンジンによって次のものが作成されます:

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

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

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

13. コンソールに戻るには、「閉じる」を選択します。

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

また、Kubernetesエンジンによって、kubectlを使用してクラスタにアクセスするために使用するKubernetes kubeconfig構成ファイルも作成されます。