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

「クイック作成」ワークフローを使用して、Kubernetesエンジン(OKE)を使用してデフォルト設定および新しいネットワーク・リソースでKubernetesクラスタを作成する方法をご紹介します。

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

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

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

3. 「クラスタ・リスト」ページで、「クラスタの作成」をクリックします。
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の数とメモリー量を明示的に指定できます。リストには、Kubernetesエンジンでサポートされているテナンシで使用可能なシェイプのみが表示されます。「ワーカー・ノードにサポートされているイメージ(カスタム・イメージを含む)およびシェイプ」を参照してください。

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

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

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

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

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

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

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

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

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

        • ブート・ボリュームのカスタム・サイズを指定するには、「カスタム・ブート・ボリューム・サイズを指定します」チェック・ボックスを選択します。次に、カスタム・サイズを50GBから32TBの範囲で入力します。指定するサイズは、選択したイメージのデフォルトのブート・ボリューム・サイズより大きくする必要があります。詳細は、カスタム・ブート・ボリュームのサイズを参照してください。

          ブート・ボリューム・サイズを増やす場合は、より大きなサイズを利用するために、ブート・ボリューム(ルート・パーティション)のパーティションも拡張する必要があることに注意してください。ブート・ボリュームのパーティションの拡張を参照してください。Oracle Linuxプラットフォーム・イメージには、oci-utilsパッケージが含まれています。カスタムcloud-initスクリプトでそのパッケージからoci-growfsコマンドを使用して、ルート・パーティションを拡張し、ファイル・システムを拡張できます。詳細は、ワーカー・ノードのルート・パーティションの拡張を参照してください。

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

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

      • このクラスタでのイメージ検証ポリシーの有効化: (オプション)特定のマスター暗号化キーによって署名されたOracle Cloud Infrastructure Registryからのイメージのデプロイメントのみを許可するかどうか。暗号化キーおよびそれを含むボールトを指定します。「レジストリからの署名付きイメージの使用の強制」を参照してください。
      • 公開SSHキー: (オプション)ノード・プールの各ノードへのSSHアクセスに使用するキー・ペアの公開キー部分。公開キーは、クラスタ内のすべてのワーカー・ノードにインストールされます。公開SSHキーを指定しない場合、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. 仮想ノードの詳細を指定します:
      • ノード数:仮想ノード・プールに作成する仮想ノードの数で、クラスタ用に作成されたリージョン・サブネットに配置されます。ノードは、リージョン内の可用性ドメイン全体(または、単一の可用性ドメインを持つリージョンの場合、その可用性ドメイン内のフォルト・ドメイン全体)に可能なかぎり均等に分散されます。

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

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

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

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

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

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

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

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

    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アドレスと同じです)

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

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

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

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

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