コンソールを使用した、クイック作成ワークフローでのデフォルト設定によるクラスタの作成

Container Engine for Kubernetes (OKE)を使用してデフォルト設定および新しいネットワーク・リソースでKubernetesクラスタを作成するためにクイック作成ワークフローを使用する方法を確認します。

Container Engine for Kubernetesを使用して、クイック作成ワークフローでデフォルト設定および新しいネットワーク・リソースでクラスタを作成するには:

1. ナビゲーション・メニューを開き、「開発者サービス」をクリックします「コンテナとアーティファクト」で、「Kubernetesクラスタ(OKE)」をクリックします。

2. 作業する権限があるコンパートメントを選択します。

3. 「Cluster List」ページで、「Create cluster」をクリックします。
4. 「クラスタの作成」ダイアログで、「クイック作成」を選択して「送信」をクリックします。

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

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

   • Kubernetes APIエンドポイント: クラスタのKubernetes APIエンドポイントへのアクセスのタイプ。Kubernetes APIエンドポイントは、プライベート(VCN内の他のサブネットからアクセス可能)またはパブリック(インターネットから直接アクセス可能)のいずれかです:

     • プライベート・エンドポイント: プライベート・リージョン・サブネットが作成され、Kubernetes APIエンドポイントがそのサブネットでホストされます。Kubernetes APIエンドポイントにはプライベートIPアドレスが割り当てられます。
     • パブリック・エンドポイント: パブリック・リージョン・サブネットが作成され、Kubernetes APIエンドポイントがそのサブネットでホストされます。Kubernetes APIエンドポイントには、パブリックIPアドレスおよびプライベートIPアドレスが割り当てられます。

     プライベート・エンドポイントおよびパブリック・エンドポイントには、Kubernetes APIエンドポイント(TCP/6443)へのアクセス権を付与するセキュリティ・ルール(セキュリティ・リストの一部として)が割り当てられます。

     詳細は、Kubernetesクラスタ・コントロール・プレーンおよびKubernetes APIを参照してください。

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

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

6. 「ノード・タイプ」として「管理対象」を選択した場合は、次のようになります。

   1. 管理対象ノードの詳細を指定します。

      • Kubernetesワーカー・ノード: クラスタのワーカー・ノードへのアクセスのタイプ。ワーカー・ノードは、プライベート(他のVCNサブネットを介してアクセス可能)またはパブリック(インターネットから直接アクセス可能)のいずれかです:

        • 非公開就業者: 推奨。ワーカー・ノードをホストするために、プライベート・リージョン・サブネットが作成されます。ワーカー・ノードにはプライベートIPアドレスが割り当てられます。
        • パブリック・ワーカー:パブリック・リージョン・サブネットが作成され、ワーカー・ノードがホストされます。ワーカー・ノードには、パブリックIPアドレスおよびプライベートIPアドレスが割り当てられます。

        パブリック・リージョナル・サブネットは、ここでの選択に関係なく、クイック作成ワークフローで作成されたクラスタでロード・バランサをホストするために常に作成されます。

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

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

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

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

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

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

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

      • ノード数:ノード・プールに作成するワーカー・ノードの数で、クラスタ用に作成されたリージョナル・サブネットに配置されます。ノードは、リージョン内の可用性ドメイン全体(または、単一の可用性ドメインを持つリージョンの場合、その可用性ドメイン内のフォルト・ドメイン全体)に可能なかぎり均等に分散されます。

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

      • ブート・ボリューム: ワーカー・ノードのブート・ボリュームのサイズおよび暗号化オプションを構成します:

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

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

      • このクラスタでのイメージ検証ポリシーの有効化: (オプション)特定のマスター暗号化キーによって署名されたOracle Cloud Infrastructure Registryからのイメージのデプロイメントのみを許可するかどうか。暗号化キーとそれを含むボールトを指定します。レジストリからの署名付きイメージ使用の強制を参照してください。
      • 公開SSHキー: (オプション)ノード・プールの各ノードへのSSHアクセスに使用するキー・ペアの公開キー部分。公開キーは、クラスタ内のすべてのワーカー・ノードにインストールされます。公開SSHキーを指定しない場合、Container Engine for Kubernetesによって提供されることに注意してください。ただし、対応する秘密キーがないため、ワーカー・ノードへのSSHアクセスはできません。クラスタ内のワーカー・ノードをプライベート・リージョナル・サブネットでホストするように指定した場合、SSHを使用して直接アクセスすることはできません(SSHを使用したプライベート・サブネットの管理対象ノードへの接続を参照)。
      • Kubernetesラベル: (オプション) (デフォルト・ラベルに加えて)ノード・プールのワーカー・ノードに追加するための1つ以上のラベル。特定のノード・プールでワークロードをターゲットに設定できるようになります。たとえば、ノード・プール内のすべてのノードをロード・バランサ・バックエンド・セット内のバックエンド・サーバーのリストから除外するには、node.kubernetes.io/exclude-from-external-load-balancers=trueを指定します(node.kubernetes.io/exclude-from-external-load-balancersを参照)。

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

   1. 仮想ノード詳細の指定:
      • ノード数:仮想ノード・プールに作成する仮想ノードの数で、クラスタ用に作成されたリージョナル・サブネットに配置されます。ノードは、リージョン内の可用性ドメイン全体(または、単一の可用性ドメインを持つリージョンの場合、その可用性ドメイン内のフォルト・ドメイン全体)に可能なかぎり均等に分散されます。

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

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

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

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

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

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

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

10. 「クラスタの作成」をクリックして、新しいネットワーク・リソースおよび新しいクラスタを今すぐ作成します。

    Container Engine for Kubernetesでは、リソースの作成が開始されます(「クラスタと関連ネットワーク・リソースの作成」ダイアログに表示):

    • ネットワーク・リソース(VCN、インターネット・ゲートウェイ、NATゲートウェイ、ルート表、セキュリティ・リスト、ワーカー・ノード用のリージョナル・サブネットおよびロード・バランサ用の別のリージョナル・サブネットなど)と、oke-<resource-type>-quick-<cluster-name>-<creation-date>形式の自動生成された名前
    • 指定した名前のクラスタ
    • pool1という名前のノード・プール
    • ワーカー・ノード、自動生成された名前(管理対象ノード名の形式はoke-c<part-of-cluster-OCID>-n<part-of-node-pool-OCID>-s<part-of-subnet-OCID>-<slot>、仮想ノード名はノードのプライベートIPアドレスと同じ)

    Container Engine for Kubernetesによって自動生成されたリソース名は変更しないでください。なんらかの理由でクラスタが正常に作成されない場合(たとえば、権限が不十分な場合やテナンシのクラスタ制限を超えた場合)、クラスタ作成プロセス中に作成されたネットワーク・リソースは自動的に削除されません。このような未使用のネットワーク・リソースは、手動で削除する必要があります。

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

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

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

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