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

ワーカー・ノード・サブネットのルート表

ワーカー・ノードをパブリック・サブネットにデプロイする場合、サブネット・ルート表には、インターネット・ゲートウェイを宛先CIDRブロック0.0.0.0/0のターゲットとして指定するルート・ルールが必要です。

ワーカー・ノードをプライベート・サブネットにデプロイする場合、サブネット・ルート表には次のものが必要です:

• Oracle Services Networkのすべての<region>サービスのターゲットとしてサービス・ゲートウェイを指定するルート・ルール
• NATゲートウェイを宛先CIDRブロック0.0.0.0/0のターゲットとして指定するルート・ルール

Kubernetes APIエンドポイント・サブネットのルート表

パブリック・サブネットにKubernetes APIエンドポイントをデプロイする場合、サブネット・ルート表には、宛先CIDRブロック0.0.0.0/0のターゲットとしてインターネット・ゲートウェイを指定するルート・ルールが必要です。

プライベート・サブネットにKubernetes APIエンドポイントをデプロイする場合、サブネット・ルート表には次のものが必要です:

• Oracle Services Networkのすべての<region>サービスのターゲットとしてサービス・ゲートウェイを指定するルート・ルール
• NATゲートウェイを宛先CIDRブロック0.0.0.0/0のターゲットとして指定するルート・ルール

ロード・バランサ・サブネットのルート表

パブリック・サブネットにロード・バランサをデプロイする場合、サブネット・ルート表には、宛先CIDRブロック0.0.0.0/0のターゲットとしてインターネット・ゲートウェイを指定するルート・ルールが必要です。

ロード・バランサをプライベート・サブネットにデプロイする場合は、サブネット・ルート表を空にできます。

ポッド・サブネットのルート表

ポッド・ネットワークにOCI VCNネイティブ・ポッド・ネットワークCNIプラグインを使用する場合は、プライベート・サブネットにポッドをデプロイします。サブネット・ルート表には次のものが必要です:

• Oracle Services Networkのすべての<region>サービスのターゲットとしてサービス・ゲートウェイを指定するルート・ルール
• NATゲートウェイを宛先CIDRブロック0.0.0.0/0のターゲットとして指定するルート・ルール

ポッドネットワーキングにflannel CNIプラグインを使用する場合、ポッドサブネットは必要ありません。

ルート表の構成に関するノート

• 非対称ルーティングの可能性を回避するために、パブリック・サブネットのルート表には、インターネット・ゲートウェイをターゲットとするルート・ルールと、サービス・ゲートウェイをターゲットとするルート・ルールの両方を含めることはできません(Oracleサービスからサービス・ゲートウェイを介してパブリック・インスタンスにアクセスする場合の問題を参照)。

• ルート表の設定の詳細は、次を参照してください:

  • インターネット・ゲートウェイ
  • NATゲートウェイ
  • Oracleサービスへのアクセス: サービス・ゲートウェイ
  • ネットワーク・リソース構成例

Kubernetes APIエンドポイント・サブネットの構成

Kubernetes APIエンドポイント・サブネットは、クラスタ・コントロール・プレーン上のKubernetes APIへのアクセスを提供するエンドポイントをホストします。

Kubernetes APIエンドポイント・サブネットはリージョナル・サブネットである必要があり、プライベート・サブネットまたはパブリック・サブネットにすることができます:

• Kubernetes APIエンドポイントにパブリック・サブネットを指定する場合、エンドポイントにパブリックIPアドレスを割り当てることで、オプションでエンドポイントをインターネットに公開できます。パブリックIPアドレスを使用すると、サード・パーティのクラウド・サービス(SaaS CI/CDサービスなど)がKubernetes APIエンドポイントにアクセスできます。次の点に注意してください:
  • Kubernetes APIエンドポイントにパブリックIPアドレスがある場合、インターネット・ゲートウェイを使用してエンドポイントにアクセスできるようにするには、ルート・ルールおよびセキュリティ・ルールが存在する必要があります(例1: チャネルCNIプラグイン、パブリックKubernetes APIエンドポイント、プライベート・ワーカー・ノードおよびパブリック・ロード・バランサを含むクラスタおよび例3: OCI CNIプラグイン、パブリックKubernetes APIエンドポイント、プライベート・ワーカー・ノードおよびパブリック・ロード・バランサを含むクラスタを参照)。
  • Kubernetes APIエンドポイントにパブリックIPアドレスがない場合は、サービス・ゲートウェイおよびNATゲートウェイを使用してエンドポイントにアクセスできるように、ルート・ルールおよびセキュリティ・ルールが存在する必要があります(例2を参照: チャネルCNIプラグイン、プライベートKubernetes APIエンドポイント、プライベート・ワーカー・ノード、パブリック・ロード・バランサを含むクラスタおよび例4: OCI CNIプラグインを含むクラスタ、プライベートKubernetes APIエンドポイント、プライベート・ワーカー・ノード、パブリック・ロード・バランサ。
  • クラスタを作成した後、パブリックIPアドレスがKubernetes APIエンドポイントに割り当てられるかどうかを変更できます。パブリックIPアドレスがエンドポイントに割り当てられているかどうかを変更する場合は、ルート・ルールおよびセキュリティ・ルールも適切に更新する必要があることに注意してください。
• Kubernetes APIエンドポイントにプライベート・サブネットを指定すると、トラフィックは、VCN内の別のサブネット、別のVCNまたはオンプレミス・ネットワーク(FastConnectでピアリングされている)からKubernetes APIエンドポイント・サブネットにアクセスできます。パブリック・サブネット上の要塞ホストをKubernetes APIエンドポイントに到達するように設定することもできます(クラスタ・アクセス用の要塞の設定を参照)。

ワーカー・ノード・サブネットの構成

ワーカー・ノード・サブネットは、ワーカー・ノードをホストします。ノード・プール内のすべての管理対象ノードは、同じワーカー・ノード・サブネットに属します。

ワーカー・ノード・サブネットは、単一のリージョナル・サブネットまたは複数のAD固有のサブネット(各可用性ドメインに1つずつ)のいずれかです。

管理対象/自己管理ノード:ワーカー・ノード・サブネットは、パブリック・サブネットまたはプライベート・サブネットのいずれかです。ただし、最大のセキュリティのために、ワーカー・ノード・サブネットはプライベート・サブネットにすることをお薦めします。

仮想ノード:ワーカー・ノード・サブネットは、パブリック・サブネットまたはプライベート・サブネットのいずれかです。ただし、最大のセキュリティのために、ワーカー・ノード・サブネットはプライベート・サブネットにすることをお薦めします。また、ワーカー・ノード・サブネットとポッド・サブネットは同じサブネットであることをお薦めします(その場合、仮想ノードではポッド・サブネットがプライベート・サブネットであることが必要なため、ワーカー・ノード・サブネットはプライベート・サブネットである必要があります)。

ポッド・サブネットの構成

ポッド・サブネットは、VCNネイティブ・ポッド・ネットワークを使用するときに、ノード・プール内のワーカー・ノード上のポッドをホストします(「ポッド・ネットワーク用のOCI VCNネイティブ・ポッド・ネットワークCNIプラグインの使用」を参照)。

ポッド・サブネットは、単一のリージョナル・サブネットである必要があります。

管理対象ノード:ポッド・サブネットはプライベート・サブネットである必要があります。

仮想ノード:ポッド・サブネットはプライベート・サブネットである必要があります。ポッド・サブネットとワーカー・ノード・サブネットは同じサブネット(この場合、ワーカー・ノード・サブネットもプライベート・サブネットである必要があります)にすることをお薦めします。

ロード・バランサ・サブネットの構成

ロード・バランサ・サブネットは、LoadBalancerタイプのKubernetesサービスによって作成されたOracle Cloud Infrastructureロード・バランサを接続します。

ロード・バランサ・サブネットは、単一のリージョナル・サブネットまたはAD固有のサブネット(各可用性ドメインに1つずつ)です。ただし、リージョナル・サブネットをお薦めします。

ロード・バランサ・サブネットは、クラスタにデプロイされたアプリケーションへのアクセス方法に応じて、パブリック・サブネットまたはプライベート・サブネットのいずれかになります。アプリケーションがVCN内から内部的にアクセスされる場合は、ロード・バランサ・サブネットにプライベート・サブネットを使用します。アプリケーションがインターネットからアクセスされる場合は、ロード・バランサ・サブネットにパブリック・サブネットを使用します。

要塞サブネット構成(オプション)

要塞サブネット内のオプションの要塞は、Kubernetes APIエンドポイントへのセキュアなアクセス、およびワーカー・ノードへのSSHアクセスを提供できます。クラスタ・アクセスの基本設定を参照してください。

Kubernetes APIエンドポイントのセキュリティ・ルール

Kubernetes APIエンドポイント、ネットワーク・セキュリティ・グループ(推奨)またはセキュリティ・リスト(あるいはその両方)に対して、次のイングレス・ルールを定義する必要があります:

Kubernetes APIエンドポイント、ネットワーク・セキュリティ・グループ(推奨)またはセキュリティ・リスト(あるいはその両方)に、次のオプションのイングレス・ルールを定義できます:

Kubernetes APIエンドポイント、ネットワーク・セキュリティ・グループ(推奨)またはセキュリティ・リスト(あるいはその両方)に、次のエグレス・ルールを定義する必要があります:

ワーカー・ノードのセキュリティ・ルール

ワーカー・ノードは、クラスタ内のノード・プールを定義するときにパブリック・サブネットとプライベート・サブネットのどちらを指定するかに応じて、パブリックIPアドレスまたはプライベートIPアドレスを使用して作成されます。Kubernetes Engineはワーカー・ノードにアクセスできる必要があります。

ワーカー・ノード、ネットワーク・セキュリティ・グループ(推奨)またはセキュリティ・リスト(あるいはその両方)に対して、次のイングレス・ルールを定義する必要があります。

次のオプションのイングレス・ルールは、ワーカー・ノード(管理対象ノードのみ)、ネットワーク・セキュリティ・グループ(推奨)またはセキュリティ・リスト(あるいはその両方)に対して定義できます:

ワーカー・ノード、ネットワーク・セキュリティ・グループ(推奨)またはセキュリティ・リスト(あるいはその両方)に対して、次のエグレス・ルールを定義する必要があります。

ワーカー・ノード、ネットワーク・セキュリティ・グループ(推奨)またはセキュリティ・リスト(あるいはその両方)に対して、次のオプションのエグレス・ルールを定義できます。

ポッド・サブネットのセキュリティ・ルール

ポッド・ネットワークにOCI VCNネイティブ・ポッド・ネットワークCNIプラグインを使用する場合:

• ネットワーク・セキュリティ・グループ(推奨)またはセキュリティ・リスト(あるいはその両方)のワーカー・ノード・サブネットに定義されているセキュリティ・ルールには、次のものを含める必要があります。

  • ワーカー・ノード間のすべてのトラフィックを許可するステートフル・イングレスおよびエグレス・ルール
  • ワーカー・ノードとロード・バランサ間のすべてのトラフィックを許可するステートフル・イングレスおよびエグレス・ルール
  • ワーカー・ノードとKubernetes Engine間のトラフィックを許可するステートフルなエグレス・ルール
• ポッド・サブネット(ネットワーク・セキュリティ・グループ(推奨)またはセキュリティ・リスト(あるいはその両方)に定義されているセキュリティ・ルールには、ポッド間のすべてのトラフィックを許可するステートフル・イングレス・ルールおよびエグレス・ルールを含める必要があります

ポッド・サブネット、ネットワーク・セキュリティ・グループ(推奨)またはセキュリティ・リスト(あるいはその両方)に対して、次のイングレス・ルールを定義する必要があります。

ポッド・サブネット、ネットワーク・セキュリティ・グループ(推奨)またはセキュリティ・リスト(あるいはその両方)に対して、次のエグレス・ルールを定義する必要があります。

次のオプションのエグレス・ルールは、ポッド・サブネット、ネットワーク・セキュリティ・グループ(推奨)またはセキュリティ・リスト(あるいはその両方)に対して定義できます:

ロード・バランサとネットワーク・ロード・バランサのセキュリティ・ルール

KubernetesエンジンがLoadBalancerタイプのKubernetesサービスに対してOCIロード・バランサまたはネットワーク・ロード・バランサをプロビジョニングする場合、ロード・バランサまたはネットワーク・ロード・バランサのサブネットとの間でインバウンド・トラフィックとアウトバウンド・トラフィックを許可するための適切なセキュリティ・ルールが存在する必要があります。管理対象ノード(仮想ノードではない)の場合、これらのセキュリティ・ルールは、ロード・バランサに対してデフォルトで自動的に作成されますが、ネットワーク・ロード・バランサに対してデフォルトでは自動的に作成されません。LoadBalancerタイプのKubernetesサービスに対するOCIロード・バランサまたはネットワーク・ロード・バランサのプロビジョニングの詳細は、LoadBalancerタイプのKubernetesサービスの定義を参照してください。

ネットワーク・セキュリティ・グループ(推奨)またはセキュリティ・リスト(あるいはその両方)のサブネットに対して、イングレスおよびエグレス・セキュリティ・ルールを定義できます。詳細は、次を参照してください:

• ネットワーク・セキュリティ・グループの指定(推奨)
• OCI Load Balancerのプロビジョニング時のセキュリティ・リスト管理オプションの指定
• OCI Network Load Balancerのプロビジョニング時のセキュリティ・リスト管理オプションの指定

次のイングレス・セキュリティ・ルールを、いずれかまたは両方で定義します。

• ロード・バランサまたはネットワーク・ロード・バランサ・リソースが追加されたネットワーク・セキュリティ・グループ(推奨)
• ロード・バランサまたはネットワーク・ロード・バランサのサブネットに関連付けられたセキュリティ・リスト

特定のアプリケーション要件に合せて、イングレス・ルールのプロトコルおよび宛先ポートを適切に設定します。たとえば、UDPトラフィックを処理するアプリケーションのプロトコルとして UDPを指定します。

次のエグレス・セキュリティ・ルールを、いずれかまたは両方で定義します。

• ロード・バランサまたはネットワーク・ロード・バランサ・リソースが追加されたネットワーク・セキュリティ・グループ(推奨)
• ロード・バランサまたはネットワーク・ロード・バランサのサブネットに関連付けられたセキュリティ・リスト

デフォルトでは、Kubernetes Engineプロキシ・リクエストによってプロビジョニングされたOCIロード・バランサまたはネットワーク・ロード・バランサは、クラスタ内のすべてのワーカー・ノードにプロビジョニングされます。リクエストがクラスタ内のワーカー・ノードにプロキシされる場合、ロード・バランサまたはネットワーク・ロード・バランサがポート10256 (kube-proxyヘルス・ポート)のワーカー・ノードと通信するには、次のイングレスおよびエグレス・セキュリティ・ルールが(ネットワーク・セキュリティ・グループ(推奨)またはセキュリティ・リスト(あるいはその両方)に存在する必要があります:

• ロード・バランサまたはネットワーク・ロード・バランサがワーカー・ノード上のkube-proxyと通信できるようにする、ワーカー・ノード・サブネットのセキュリティ・リスト(またはネットワーク・セキュリティ・グループ)のイングレス・セキュリティ・ルール:

  状態	ソース	プロトコル/宛先ポート	説明
  ステートフル	ロード・バランサまたはネットワーク・ロード・バランサ・サブネットCIDR	ALL/10256	OCIロード・バランサまたはネットワーク・ロード・バランサが、ワーカー・ノードでkube-proxyと通信できるようにします。

• ロード・バランサまたはネットワーク・ロード・バランサ・サブネットのセキュリティ・リスト(またはネットワーク・セキュリティ・グループ)のエグレス・セキュリティ・ルールを使用して、ロード・バランサまたはネットワーク・ロード・バランサがワーカー・ノードでkube-proxyと通信できるようにします:

  状態	宛先	プロトコル/宛先ポート	説明
  ステートフル	ワーカー・ノード・サブネットCIDR	ALL/10256	OCIロード・バランサまたはネットワーク・ロード・バランサが、ワーカー・ノードでkube-proxyと通信できるようにします。

LoadBalancerタイプのKubernetesサービスのネットワーク・ロード・バランサをプロビジョニングする場合:

• リクエストが、クラスタ内の他のワーカー・ノードにプロキシされるのではなく、IPパケットのヘッダーで指定されたクライアントIPアドレスで終了するように指定できます(externalTrafficPolicy: Localを設定)。「受信ノードでのリクエストの終了」を参照してください。
• リクエストがクライアントIPアドレスで終了するように指定した場合、(oci-network-load-balancer.oraclecloud.com/is-preserve-source注釈を使用して)クライアントIPアドレスをIPパケットのヘッダーに保持するかどうかも指定できます。「クライアントIPアドレスの保持」を参照してください。

どちらの場合も、クライアント接続が行われるCIDRブロックからすべてのノード・ポート(30000から32767)へのイングレス・トラフィックを許可するには、クラスタ内のワーカー・ノードに対して(ネットワーク・セキュリティ・グループ(推奨)またはセキュリティ・リスト(あるいはその両方)に)セキュリティ・ルールを設定する必要があります。アプリケーションがインターネットに公開されている場合は、セキュリティ・ルールのソースCIDRブロックを0.0.0.0/0に設定します。または、セキュリティ・ルールのソースCIDRブロックを特定のCIDRブロックに設定します(たとえば、クライアント接続が特定のサブネットからの場合)。

要塞サブネットのセキュリティ・ルール

要塞サブネット内のオプションの要塞は、Kubernetes APIエンドポイントへのセキュアなアクセス、およびワーカー・ノードへのSSHアクセスを提供できます。定義するイングレスおよびエグレス・セキュリティ・ルールの詳細は、「クラスタ・アクセス用の要塞の設定」を参照してください。