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

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

ワーカー・ノードをパブリック・サブネットにデプロイする場合、サブネット・ルート表には、インターネット・ゲートウェイを宛先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: クラスタとFlannel CNIプラグイン、パブリックKubernetes APIエンドポイント、プライベート・ワーカー・ノードおよびパブリック・ロード・バランサおよび例3: クラスタとOCI CNIプラグイン、パブリックKubernetes APIエンドポイント、プライベート・ワーカー・ノードおよびパブリック・ロード・バランサを参照)。
  • Kubernetes APIエンドポイントにパブリックIPアドレスがない場合は、サービス・ゲートウェイおよびNATゲートウェイを使用してエンドポイントにアクセスできるように、ルート・ルールおよびセキュリティ・ルールが存在する必要があります(例2:Flannel CNIプラグイン、Private Kubernetes API Endpoint、Private Worker NodesおよびPublic Load Balancersを使用したクラスタと例4: OCI CNIプラグインを含むクラスタ、Private Kubernetes APIエンドポイント、Private Worker NodesおよびPublic Load Balancers)。
  • クラスタを作成した後、パブリック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内から内部的にアクセスされる場合は、ロード・バランサ・サブネットにプライベート・サブネットを使用します。アプリケーションがインターネットからアクセスされる場合は、ロード・バランサ・サブネットにパブリック・サブネットを使用します。

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

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

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

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

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

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

就業者ノードのセキュリティ・ルール

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

デフォルトでは、Container Engine for Kubernetesプロキシ・リクエストによってプロビジョニングされた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アドレスで終了するように指定した場合、クライアントIPアドレスをIPパケットのヘッダーに保持するかどうかを指定することもできます(oci-network-load-balancer.oraclecloud.com/is-preserve-source注釈を使用)。「クライアントIPアドレスの保持」を参照してください。

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

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

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