Oracle Cloud Infrastructureドキュメント

クラスタの作成とデプロイメントのためのネットワーク・リソース構成

Container Engine for Kubernetesを使用してテナンシ内のリージョンにクラスタを作成およびデプロイするには:

  • ルート・コンパートメントには、Container Engine for Kubernetesがテナンシ内で操作を実行できるようにするポリシーが含まれている必要があります。 「Kubernetesのコンテナ・エンジンに必須のポリシーを作成」も参照してください。
  • テナンシ内には、必要なネットワーク・リソース(VCN、サブネット、インターネット・ゲートウェイ、ルート表、セキュリティ・リストなど)を含むコンパートメントがすでに存在している必要があります。 そのようなコンパートメントが存在しない場合は、作成する必要があります。 ネットワーク・リソースはルート・コンパートメントに配置できます。 ただし、複数のチームでクラスタを作成する場合は、チームごとに別個のコンパートメントを作成することをお薦めします。
  • コンパートメント内では、ネットワーク・リソース(VCN、サブネット、インターネット・ゲートウェイ、ルート表、セキュリティ・リストなど)を作成およびデプロイする各リージョンで適切に構成する必要があります。 新しいクラスタを作成する場合、新しいクイック・クラスタ用に新しいネットワーク・リソースを自動的に作成して構成するContainer Engine for Kubernetesを設定できます。 または、カスタム・クラスタに使用する既存のネットワーク・リソースを明示的に指定できます。 既存のネットワーク・リソースを指定する場合は、このトピックで説明するように、自身または他のユーザーがこのリソースを適切に構成している必要があります。

このトピックでは、各ネットワーク・リソースに必要な構成について説明します。 一般的な構成の詳細を表示するには、「ネットワーク・リソース構成の例」を参照してください。

紹介のチュートリアルは、「Oracle Cloud Infrastructure Container Engine for Kubernetesを使用したクラスタの作成」を参照してください。

ルート・コンパートメント構成

Container Engine for Kubernetesがテナンシ上で操作を実行できるようにするには、ルート・コンパートメントのポリシーを定義する必要があります。 「Kubernetesのコンテナ・エンジンに必須のポリシーを作成」も参照してください。

VCN構成

クラスタを作成してデプロイするVCNは、次のように構成する必要があります:

  • VCNには、作成するクラスタに指定するサブネット数に十分な大きさのCIDRブロックが定義されている必要があります。 たとえば、3つの可用性ドメインを持つリージョンに可用性の高いクラスタを作成するには、通常、必要な数のワーカー・ノードおよびロード・バランサをサポートするために、2つのリージョナル・サブネット(推奨)または5つのAD固有のサブネットが必要となります。 ただし、サブネット数が少ないクラスタを作成することもできます。 /16 CIDRブロックは、ほとんどすべてのユースケース(10.0.0.0/16など)に十分な大きさになります。 VCNに指定するCIDRブロックは、podsおよびKubernetesサービスに指定したCIDRブロックと重ならないようにしてください(「CIDRブロックおよびContainer Engine for Kubernetes」を参照)。
  • VCNにはインターネット・ゲートウェイが定義されている必要があります。 「インターネット・ゲートウェイの構成」を参照してください。
  • プライベート・サブネットにワーカー・ノードをデプロイする場合は、VCNにNATゲートウェイが定義されている必要があります。 「NATゲートウェイ構成」も参照してください。
  • VCNには、宛先CIDRブロックのターゲットとしてインターネット・ゲートウェイを指定するルート・ルールを持つルート表が定義されている必要があります。 プライベート・サブネットにワーカー・ノードをデプロイする場合は、ルート表に、宛先CIDRブロックのターゲットとしてNATゲートウェイを指定するルート・ルールも必要です。 「ルート表の構成」を参照してください。
  • VCNには、適切な数のサブネットが定義されている必要があります。 たとえば、3つの可用性ドメインを持つリージョンに高可用性クラスタを作成するには、VCNに次が含まれる必要があります:

    • 就業者ノード: リージョナル・サブネット(推奨)、またはAD固有の3つのサブネット(各可用性ドメインに1つ)。
    • ロード・バランサの場合: オプション(ただし、通常は異なる可用性ドメイン内)で、追加のリージョナル・サブネット(推奨)または2つのAD固有のサブネット(それぞれ異なる可用性ドメインにあります)。

    ただし、ワーカー・ノードの数が少なく、ロード・バランサの数が少ないかまたは少ないクラスタを作成することができるため、サブネットの数が少なくなります。 ベスト・プラクティスは、リージョンのサブネットを使用して、可用性ドメイン全体でより簡単にフェイルオーバーできるようにすることです。 「サブネット構成」を参照してください。

  • VCNには、ワーカー・ノード・サブネットおよびロード・バランサ・サブネット(指定されている場合)に定義されたセキュリティ・リストが必要です。 「セキュリティ・リストの構成」を参照してください。

また、VCNに対してDNS解決が選択されていることをお薦めします。

「VCNとサブネット」および「ネットワーク・リソース構成の例」を参照してください。

インターネット・ゲートウェイの構成

クラスタを作成してデプロイするVCNには、インターネット・ゲートウェイが必要です。 インターネット・ゲートウェイは、ルート表内のルート・ルール内の宛先CIDRブロック0.0.0.0/0のターゲットとして指定する必要があります。

「VCNとサブネット」および「ネットワーク・リソース構成の例」を参照してください。

NATゲートウェイ構成

プライベート・サブネットにワーカー・ノードをデプロイする場合は、VCNに(インターネット・ゲートウェイに加えて) NATゲートウェイを割り当てて、ワーカー・ノードがインターネットへの接続を開始できるようにする必要があります。 別々のルート表で、ルート・ルールで宛先CIDRブロック0.0.0.0/0のターゲットとしてNATゲートウェイを指定する必要があります。

「NATゲートウェイ」および「ネットワーク・リソース構成の例」を参照してください。

ルート表の構成

クラスタを作成してデプロイするVCNにはルート表が必要です。 ルート表には、宛先CIDRブロック0.0.0.0/0のターゲットとしてインターネット・ゲートウェイを指定するルート・ルールが必要です。

プライベート・サブネットにワーカー・ノードをデプロイする場合は、宛先CIDRブロック0.0.0.0/0のターゲットとしてNATゲートウェイを指定するルート・ルールがなければ、ワーカー・ノードがインターネットへの接続を開始できるようになりません。 このルート表は、インターネット・ゲートウェイをターゲットとして指定するルート表に追加されます。

「インターネット・ゲートウェイ」および「ネットワーク・リソース構成の例」を参照してください。

DHCPオプション構成

クラスタを作成してデプロイするVCNには、DHCPオプションが構成されている必要があります。 InternetおよびVCN Resolverの「DNSタイプ」のデフォルト値はそのまま使用できます。

「DHCPオプション」および「ネットワーク・リソース構成の例」を参照してください。

セキュリティ・リストの構成

クラスタを作成およびデプロイするVCNは、ワーカー・ノード・サブネットおよびロード・バランサ・サブネット(指定した場合)にセキュリティ・リストが定義されている必要があります。 ワーカー・ノード・サブネットおよびロード・バランサ・サブネットのセキュリティ・リストは、異なる必要があります。 ロード・バランサ・サブネットのセキュリティ・リストは、一意であり、その排他的使用にする必要があります。

ワーカー・ノードは、クラスタ内のノード・プールを定義するときにパブリックまたはプライベートのサブネットを指定したかどうかに応じて、パブリックまたはプライベートのIPアドレスで作成されます。 どちらの場合も、ワーカー・ノードはインターネットへのアウトバウンド接続を可能にする必要があります。 Container Engine for Kubernetesもワーカー・ノードにアクセスできる必要があります。

「セキュリティ・リスト」および「ネットワーク・リソース構成の例」を参照してください。

パブリック・ワーカー・ノード・サブネット・セキュリティ・リストの構成

パブリック・ワーカー・ノード・サブネットのセキュリティ・リストを構成する場合は、セキュリティ・リストに次が含まれている必要があります:

  • 異なるワーカー・スレッドとノード間のトラフィックをすべて許可するステートレス・イングレス・ルールおよびエグレス・ルール
  • ワーカー・ノード・サブネットとロード・バランサ・サブネット(指定されている場合)間のすべてのトラフィックを許可する、ステートレス・イングレスおよびエグレス・ルール
  • インターネットへのすべての発信トラフィックを許可するエグレス・ルール
  • Container Engine for Kubernetesがポート22のワーカー・ノードに次のソースCIDRブロックからアクセスできるようにするためのイングレス・ルール:
    • 130.35.0.0/16
    • 134.70.0.0/17
    • 138.1.0.0/16
    • 140.91.0.0/17
    • 147.154.0.0/16
    • 192.29.0.0/16

必要に応じて、パブリック・ワーカー・ノード・サブネットのイングレス・ルールを次のように含めることができます:

プライベート・ワーカー・ノードのサブネット・セキュリティ・リストの構成

プライベート・ワーカー・ノード・サブネットのセキュリティ・リストを構成する場合は、セキュリティ・リストに次が含まれている必要があります:

  • 異なるワーカー・ノード・サブネット間のすべてのトラフィックを許可するステートレス・イングレスおよびエグレス・ルール
  • ワーカー・ノード・サブネットとロード・バランサ・サブネット間のすべてのトラフィックを許可するステートレスのイングレスおよびエグレス・ルール
  • インターネットへのすべての発信トラフィックを許可するエグレス・ルール

オプションで、プライベート・ワーカー・ノード・サブネットのためのイングレス・ルールを次のように含めることができます:

サブネット構成

作成するクラスタの特性と、クラスタをデプロイするリージョン内の可用性ドメインの数により、構成するサブネットの数が決まります。 たとえば、3つの可用性ドメインを持つリージョンで可用性の高いクラスタを作成するには、次を実行する必要があります:

  • 就業者ノード: リージョナル・サブネット(推奨)、またはAD固有の3つのサブネット(各可用性ドメインに1つ)。
  • ロード・バランサの場合: オプション(ただし、通常は異なる可用性ドメイン内)で、追加のリージョナル・サブネット(推奨)または2つのAD固有のサブネット(それぞれ異なる可用性ドメインにあります)。

ベスト・プラクティスは、リージョンのサブネットを使用して、可用性ドメイン全体でより簡単にフェイルオーバーできるようにすることです。

クラスタを作成およびデプロイするVCNには、ワーカー・ノードをデプロイするために定義されたサブネットが少なくとも1つ必要です。 ワーカー・ノードのサブネットは、パブリックまたはプライベートのいずれかにでき、追加のセキュリティを実現できます(「サブネット・アクセス」プロパティで指定)。 作成するワーカー・ノード・サブネットの数は、クラスタを作成するリージョンによって異なります:

  • 複数の可用性ドメインを持つリージョンでクラスタを作成する場合は、1つのリージョナル・サブネット、または複数のAD固有のサブネット(各可用性ドメインに1つずつ)を定義できます。
  • 単一の可用性ドメインがあるリージョンでクラスタを作成する場合は、単一のリージョナル・サブネット(推奨)または単一のAD固有のサブネットを定義できます。

作成するクラスタ内にロード・バランサを定義して使用するオプションがあります。 ロード・バランサを定義して使用する場合、クラスタを作成およびデプロイするVCNには、ロード・バランサをホストするために少なくとも1つのサブネットが定義されている必要があります。 ロード・バランサ・サブネットは、パブリックまたはプライベートにできます(「サブネット・アクセス」プロパティで指定したとおり)。 ただし、ロード・バランサはオプションであるため、ロード・バランサ・サブネットは定義しない場合があります。 定義するロード・バランサ・サブネットの数は、クラスタを作成するリージョンによって異なります:

  • 3つの可用性ドメインを持つリージョンでクラスタを作成する場合は、次のものを定義できます:
    • 0または1つのロード・バランサ・リージョン・サブネット(推奨)
    • 0(ゼロ)または2つのロード・バランサのAD固有サブネット。 2つのロード・バランサのAD固有のサブネットを定義する場合、それらのサブネットは異なる可用性ドメインにある必要があります。
  • 単一の可用性ドメインがあるリージョンでクラスタを作成する場合、0または1つのロード・バランサ・サブネットを定義できます:

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

さらに、すべてのサブネットに次のプロパティが設定されている必要があります:

  • ルート表: 宛先CIDRブロックのターゲットとしてインターネット・ゲートウェイ(パブリック・ワーカー・ノード・サブネットの場合)またはNATゲートウェイ(プライベート・ワーカー・ノード・サブネットの場合)を指定するルート・ルールを持つルート表の名前0.0.0.0/0
  • DHCPオプション: デフォルト

ワーカー・ノードおよびロード・バランサ・サブネットに指定するCIDRブロックは、クラスタで実行されているポッドに指定するCIDRブロックと重ならないようにしてください(「CIDRブロックおよびContainer Engine for Kubernetes」を参照)。

ワーカー・ノード・サブネットは、ロード・バランサ・サブネットに異なるセキュリティ・リストを持つ必要があります。

「VCNとサブネット」および「ネットワーク・リソース構成の例」を参照してください。