Oracle Cloud Infrastructureドキュメント

Kubernetesクラスタの作成

Container Engine for Kubernetesを使用して、新しいKubernetesクラスタを作成することができます。 クラスタを作成するには、テナンシ管理者グループに属するか、またはポリシーがCLUSTER_MANAGE権限を付与するグループに所属する必要があります。 また、ルート・コンパートメントのポリシーは、テナンシ内のすべてのリソースにContainer Engine for Kubernetesアクセス権を付与する必要があります。 「クラスタの作成とデプロイメントのためのポリシー構成」も参照してください。

まず、新しいクラスタの基本的な詳細(クラスタ名とマスター・ノードにインストールするKubernetesバージョン)を指定します。 そのあと、次の2つの方法のいずれかでクラスタを作成できます:

  • デフォルト設定を使用して、必要に応じて新しいネットワーク・リソースでクイック・クラスタを作成します。 この方法は、新しいクラスタを最も速く作成する方法です。 すべてのデフォルト値を受け入れると、いくつかのクリックで新しいクラスタを作成できます。 クイック・クラスタの新しいネットワーク・リソースが自動的に作成されます(ワーカー・ノード用の1つのリージョナル・サブネット、およびロード・バランサ用の別のリージョナル・サブネットが含まれます)。 ロード・バランサのリージョナル・サブネットはパブリックですが、ワーカー・ノードのリージョナル・サブネットがパブリックかプライベートかを指定できます。 クイック・クラスタのワーカー・ノードに専用のリージョナル・サブネットを指定している場合は、(インターネット・ゲートウェイに加えて) NATゲートウェイも作成されることに注意してください。 クイック・クラスタを作成するには、新しいネットワーク・リソースを作成するために必要な権限をポリシーで付与するグループに属している必要があります(「グループに対する1つ以上の追加ポリシーの作成」を参照)。
  • カスタム設定を使用してカスタム・クラスタを作成します。 この方法では、新しいクラスタを最も細かく制御できます。 新しいクラスタのプロパティは明示的に定義できます。 また、ワーカー・ノードやロード・バランサを作成するための既存のパブリック・サブネットまたはプライベート・サブネットを含め、使用する既存のネットワーク・リソースを明示的に指定できます。 サブネットは、リージョナル・サブネット(推奨)またはAD固有のサブネットです。 通常は新しいカスタム・クラスタを定義するときにノード・プールをただちに定義する必要はありませんが、定義する必要はありません。 ノード・プールなしでカスタム・クラスタを作成し、後でノード・プールを追加できます。

クラスタの作成方法に関係なく、Container Engine for Kubernetesはワーカー・ノードに次の書式で名前を付けます:

oke-c<part-of-cluster-OCID>-n<part-of-node-pool-OCID>-s<part-of-subnet-OCID>-<slot>

説明:

  • okeは、Container Engine for Kubernetesによって作成されるすべてのワーカー・ノードの標準接頭辞です
  • c<part-of-cluster-OCID > は、文字cを先頭に付けたクラスタOCIDの一部です。

  • n<part-of-node-pool-OCID>は、ノード・プールOCIDの一部で、文字nが先頭に付加されます。
  • s<part-of-subnet-OCID>は、先頭に文字sを付けたサブネットOCIDの一部です。
  • <slot>はサブネット内のノードの序数です(01など)

たとえば、クラスタを指定してノード・プールに2つのノードがある場合、2つのノードに名前が付けられます:

  • oke-cywiqripuyg-nsgagklgnst-st2qczvnmba-0
  • oke-cywiqripuyg-nsgagklgnst-st2qczvnmba-1

Container Engine for Kubernetesによりワーカー・ノードに割り当てられた自動生成された名前は変更しないでください。

高可用性を確保するには、Container Engine for Kubernetes:

  • Kubernetes Control Planeを複数のOracle管理対象マスター・ノード上に作成します(サポートされているリージョン内の異なる可用性ドメインにマスター・ノードを分散します)
  • 可用性ドメイン内の各フォルト・ドメインにワーカー・ノードを作成します(これにより、フォルト・ドメイン全体に可能なかぎりワーカー・ノードが均等に配分され、他のインフラストラクチャ制限の対象となります)。

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

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

  1. コンソールで、「ナビゲーション・メニュー」を開きます。 ソリューションおよびプラットフォームの下で、開発者サービスに移動して「コンテナ・クラスタ」をクリックします。
  2. 作業権限のある「コンパートメント」を選択し、その中に新しいクラスタと、関連するネットワーク・リソースの両方を作成します。

  3. 「クラスタ・リスト」ページで、「クラスタの作成」をクリックします。
  4. 新しいクラスタに対してデフォルトの構成の詳細を受け入れるか、次のように代替を指定します:

    • 名: 新しいクラスタの名前。 デフォルト名をそのまま使用するか、任意の名前を入力します。 機密情報を入力しないでください。
    • Kubernetesバージョン: クラスタのマスター・ノードおよびワーカー・ノードで実行するKubernetesのバージョン。 デフォルト・バージョンを受け入れるか、任意のバージョンを選択します。 とりわけ、選択したKubernetesバージョンによって、作成されたクラスタでオンになるアド・ミッション・コントローラのデフォルト・セットが決定されます(このセットは、そのバージョンのKubernetes documentationで指定されている推奨事項に従います)。
  5. 「クイック作成」を選択すると、新しいクラスタの新しいネットワーク・リソースとともに、デフォルト設定で新しいクラスタが作成されます。

    「仮想クラウド・ネットワークの作成」パネルには、デフォルトで作成されるネットワーク・リソースが表示されます。

  6. 「プライベート」または「パブリック」のいずれかを選択して、ワーカー・ノードをホストするプライベートまたはパブリック・リージョン・サブネットのいずれを作成するかを指定します(ここでの選択に関係なく、パブリック・リージョン・サブネットは常にクイック・クラスタのロード・バランサをホストするために作成されます):

    • プライベート: プライベート・リージョナル・サブネットを、ワーカー・ノードをホストするために(リージョナル・サブネットとともに)作成する場合に選択します。
    • パブリック: パブリック・リージョン・サブネットを作成して、ワーカー・ノードをホストする場合に選択します(パブリック・リージョン・サブネットとともに、ロード・バランサをホストします)。

    「ノード・プールの作成」パネルには、作成されるクラスタ内の最初のノード・プールの固定プロパティが表示されます:

    • ノード・プールの名前(常時pool1)
    • ノード・プールが作成されるコンパートメント(常に新しいネットワーク・リソースが存在するコンパートメントと同じ)
    • ノード・プールの各ワーカー・ノードで実行されるKubernetesのバージョン(常にマスター・ノードに指定されたバージョンと同じ)
    • ノード・プールの各ノードで使用するイメージ

    「ノード・プールの作成」パネルには、変更できるノード・プールのプロパティの一部も含まれていますが、それらのプロパティには適切なデフォルト値が指定されています。

  7. すべてのデフォルト構成の詳細をそのまま使用し、次のステップに進んでクラスタをすぐに作成するか、次のように代替を指定します:

    1. ノード・プールに対してデフォルトの構成の詳細を受け入れるか、次のように「ノード・プールの作成」パネルで代替を指定します:
      • シェイプ: ノード・プールの各ノードに使用するシェイプ。 シェイプによって、CPUの数、および各ノードに割り当てられるメモリーの量が決まります。 リストは、Container Engine for Kubernetesでサポートされているテナンシで使用可能なシェイプのみを示します。
      • ノード数: ノード・プールに作成する、クイック・クラスタに作成されたリージョン・サブネットに配置されるワーカー・ノードの数。 ノードは、リージョン内の可用性ドメイン間で可能なかぎり(または、1つの可用性ドメインを持つリージョンの場合はその可用性ドメイン内のフォルト・ドメイン間)に均等に分散されます。
      • 公開SSHキー: (オプション)ノード・プール内の各ノードへのSSHアクセスに使用するキー・ペアの公開キー部分。 公開キーは、クラスタ内のすべてのワーカー・ノードにインストールされます。 公開SSHキーを指定しないと、Container Engine for Kubernetesが提供することに注意してください。 ただし、対応する秘密キーがないので、ワーカー・ノードへのSSHアクセスはありません。 クイック・クラスタのワーカー・ノードをプライベート・リージョン・サブネット内でホストするように指定する場合は、SSHを使用して直接アクセスすることはできません(「SSHを使用したプライベート・サブネットのワーカー・ノードへの接続」を参照)。
      • Kubernetesラベル: ノード・プールのワーカー・ノードに追加する1つ以上のラベル(デフォルト・ラベルに加えて)。これにより、特定のノード・プールでワークロードのターゲット指定が可能になります。
    2. 残りのクラスタの詳細のデフォルト値を受け入れるか、「追加アドオン」パネルで次のように代替を指定します:

      • Kubernetesダッシュボード有効: Kubernetesダッシュボードを使用してコンテナ化アプリケーションのデプロイとトラブルシューティングを行い、Kubernetesリソースを管理する場合に選択します。 「Kubernetesダッシュボードの起動」を参照してください。
      • ティラー(ヘルム)有効: Tiller (Helmのサーバー部分)をKubernetesクラスタで実行するかどうかを選択します。 クラスタ内でTillerを実行すると、Helmを使用してKubernetesリソースを管理できます。
    3. (オプション) 「このクラスタがリクエストされた後の詳細ページの表示」を選択すると、クラスタ作成プロセスの最後にコンソール内の「クラスタ詳細」タブ(「クラスタ・リスト」ページではなく)に戻ります。
  8. 「作成」をクリックして、新しいネットワーク・リソースと新しいクラスタを作成します。

    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>の形式が自動生成された名前

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

  9. 「閉じる」をクリックして、コンソールに戻ります。
  10. 「このクラスタがリクエストされた後の詳細ページの表示」を選択した場合は、コンソールの「クラスタ詳細」タブに戻ります。 「このクラスタがリクエストされた後の詳細ページの表示」を選択しなかった場合は、「クラスタ・リスト」ページに戻ります。

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

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

コンソールを使用して、明示的に定義された設定でカスタム・クラスタを作成する

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

  1. コンソールで、「ナビゲーション・メニュー」を開きます。 ソリューションおよびプラットフォームの下で、開発者サービスに移動して「コンテナ・クラスタ」をクリックします。
  2. 作業権限があり、新しいクラスタを作成する「コンパートメント」を選択します。
  3. 「クラスタ・リスト」ページで、「クラスタの作成」をクリックします。
  4. 新しいクラスタの構成の詳細を指定します:

    • 名: 新しいクラスタの名前。 デフォルト名をそのまま使用するか、任意の名前を入力します。 機密情報を入力しないでください。
    • Kubernetesバージョン: クラスタのマスター・ノードで実行するKubernetesのバージョン。 デフォルト・バージョンを受け入れるか、任意のバージョンを選択します。 とりわけ、選択したKubernetesバージョンによって、作成されたクラスタでオンになるアド・ミッション・コントローラのデフォルト・セットが決定されます(このセットは、そのバージョンのKubernetes documentationで指定されている推奨事項に従います)。
  5. 新しいクラスタ・プロパティと使用する既存のネットワーク・リソースを明示的に定義することによって新しいクラスタを作成するには、「カスタム作成」を選択します。

  6. 「ネットワークの選択」パネルで新しいクラスタに使用する既存のネットワーク・リソースを指定します:

    • ネットワーク・コンパートメント: 既存のネットワーク・リソースが存在するコンパートメント。
    • VCN: クラスタの作成およびデプロイ用に構成された既存の仮想クラウド・ネットワーク。 「VCN構成」を参照してください。
    • KubernetesサービスLBサブネット: オプションで、ロード・バランサをホストするように構成されている既存のサブネット。 ロード・バランサ・サブネットは、ワーカー・ノード・サブネットとは異なる必要があり、パブリックまたはプライベートにすることも、リージョン(推奨)またはAD固有にすることもできます。 ロード・バランサ・サブネットを指定する必要はありません。 ただし、ロード・バランサ・サブネットを指定した場合、指定するロード・バランサ・サブネットの数は、クラスタを作成するリージョンおよびサブネットが地域またはAD固有のものかどうかによって異なります。

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

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

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

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

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

    • KubernetesサービスCIDRブロック: Kubernetesサービス(ClusterIP)として公開可能なネットワーク・アドレスの利用可能なグループ。単一の連続した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ブロック外にあることがあります。 「CIDRブロックおよびContainer Engine for Kubernetes」も参照してください。
  7. 「キー管理」サービスを使用して、