LoadBalancerタイプのKubernetesサービスに対するOCI Network Load Balancerのプロビジョニング
Kubernetes Engine (OKE)を使用して、LoadBalancerタイプのKubernetesサービスにOCIネットワーク・ロード・バランサをプロビジョニングする方法をご覧ください。
この項では、LoadBalancerタイプのKubernetesサービスに対してOCIネットワーク・ロード・バランサをプロビジョニングする方法について説明します。
Oracle Cloud Infrastructureネットワーク・ロード・バランサは、OSIレイヤー3およびレイヤー4 (TCP/UDP/ICMP)のワークロードのパススルー・ロード・バランシングを実行する非プロキシ・ロード・バランシング・ソリューションです。これは、最小または最大帯域幅構成要件のないクライアント・トラフィックに基づいてスケール・アップまたはスケール・ダウンできる、柔軟にスケーラブルなリージョナル仮想IP (VIP)アドレスを提供します。また、フローの高可用性、ソースと宛先のIPアドレス、およびポート保存の利点も提供します。
Oracle Cloud Infrastructureネットワーク・ロード・バランサの詳細は、Flexible Network Load Balancerの概要を参照してください。
タイプLoadBalancerのKubernetesサービス用にOCIネットワーク・ロード・バランサをプロビジョニングすると、次のことが可能になります:
- 高スループットおよび低レイテンシの負荷分散トラフィック
- ソースおよび宛先のIPアドレスおよびポートの保持
- TCPおよびUDPトラフィックの処理
Kubernetes EngineがLoadBalancerタイプのKubernetesサービス用にOCIネットワーク・ロード・バランサをプロビジョニングする場合、ネットワーク・ロード・バランサのサブネットとの間のインバウンドおよびアウトバウンド・トラフィックを許可するセキュリティ・ルールは、デフォルトでは自動的に作成されません。適切なセキュリティ・ルールを定義して、ロード・バランサまたはネットワーク・ロード・バランサのサブネットとの間のインバウンドおよびアウトバウンド・トラフィックを許可する必要があります。ロード・バランサおよびネットワーク・ロード・バランサのセキュリティ・ルールを参照してください。
OCIネットワーク・ロード・バランサのメトリックを使用して、LoadBalancerタイプのKubernetesサービス用にプロビジョニングされたOCIネットワーク・ロード・バランサのヘルスを監視します(ネットワークLoad Balancerメトリックを参照)。
OCI Network Load Balancerの注釈の指定
LoadBalancerタイプのKubernetesサービス用にネットワーク・ロード・バランサをプロビジョニングするには、マニフェスト・ファイルのメタデータ・セクションに次の注釈を追加します:
oci.oraclecloud.com/load-balancer-type: "nlb"
apiVersion: v1
kind: Service
metadata:
name: my-nginx-svc
labels:
app: nginx
annotations:
oci.oraclecloud.com/load-balancer-type: "nlb"
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: nginx
lb
は、oci.oraclecloud.com/load-balancer-type
注釈のデフォルト値です。サービス定義にアノテーションを明示的に含めない場合は、アノテーションのデフォルト値が使用され、(ネットワーク・ロード・バランサではなく)ロード・バランサがプロビジョニングされます。
受信ノードでのリクエストの終了
タイプLoadBalancerのKubernetesサービスのネットワーク・ロード・バランサをプロビジョニングする場合、リクエストが、クラスタ内の他のワーカー・ノードにプロキシされるのではなく、IPパケットのヘッダーで指定されたクライアントIPアドレスで終了するように指定できます。
デフォルトでは、リクエストはクラスタ内の他のワーカー・ノードにプロキシされます。
リクエストが(プロキシされるのではなく)クライアントIPアドレスで終了するように指定すると、ワーカー・ノード間のトラフィックを排除することで、数千のワーカー・ノードを持つ非常に大規模なクラスタのパフォーマンスを向上させることができます。クライアントIPアドレスで終了するリクエストを指定すると、ネットワーク・ロード・バランサのCIDRブロックからのイングレス・トラフィックのみを許可するクラスタ内のワーカー・ノードに対して(ネットワーク・セキュリティ・グループ(推奨)またはセキュリティ・リスト(あるいはその両方)で)セキュリティ・ルールを設定できるため、実装を簡素化し、潜在的なセキュリティ上の懸念事項を削除することもできます。
クライアントIPアドレスで要求を終了するには、マニフェストファイルのspecセクションに次の設定を追加します。
externalTrafficPolicy: Local
クラスタ内の他のワーカー・ノードにリクエストをプロキシするには、マニフェスト・ファイルのspecセクションに次の設定を追加します。
externalTrafficPolicy: Cluster
Cluster
は、externalTrafficPolicy
設定のデフォルト値です。サービス定義に設定を明示的に含めない場合は、設定のデフォルト値が使用されます。
また、externalTrafficPolicy
がCluster
に設定されている場合、oci-network-load-balancer.oraclecloud.com/is-preserve-source
注釈の値に関係なく、クライアントIPアドレスは保持されません。externalTrafficPolicy
がCluster
に設定され、oci-network-load-balancer.oraclecloud.com/is-preserve-source
注釈がtrue
またはfalse
に明示的に設定されている場合、リクエストはエラーで失敗します。「クライアントIPアドレスの保持」を参照してください。
クライアントIPアドレスでリクエストを終了するには、次のセキュリティ・ルールも設定しておく必要があります。
- クライアント接続が行われるCIDRブロックからすべてのノード・ポート(
30000 to 32767
)へのイングレス・トラフィックを許可するには、クラスタ内のワーカー・ノードのセキュリティ・ルール(ネットワーク・セキュリティ・グループ(推奨)またはセキュリティ・リスト(あるいはその両方)内)を設定する必要があります。アプリケーションがインターネットに公開されている場合は、セキュリティ・ルールのソースCIDRブロックを0.0.0.0/0に設定します。または、セキュリティ・ルールのソースCIDRブロックを特定のCIDRブロックに設定します(たとえば、クライアント接続が特定のサブネットからの場合)。状態 ソース プロトコル/宛先ポート 説明 ステートフル 0.0.0.0/0またはサブネットCIDR すべて/30000-32767 ワーカー・ノードがOCI Network Load Balancerを介して接続を受信できるようにします。 -
ロード・バランサおよびネットワーク・ロード・バランサのセキュリティ・ルールの説明に従って、ネットワーク・ロード・バランサのイングレス・セキュリティ・ルールおよびエグレス・セキュリティ・ルールを設定する必要があります。
たとえば、(プロキシされるのではなく)クライアントIPアドレスでリクエストを終了するKubernetesサービス定義を次に示します:
apiVersion: v1
kind: Service
metadata:
name: my-nginx-svc
labels:
app: nginx
annotations:
oci.oraclecloud.com/load-balancer-type: "nlb"
oci-network-load-balancer.oraclecloud.com/oci-network-security-groups: "ocid1.networksecuritygroup.oc1.phx.aaaaaa....vdfw"
spec:
type: LoadBalancer
externalTrafficPolicy: Local
ports:
- port: 80
selector:
app: nginx
クライアントIPアドレスの保持
タイプLoadBalancerのKubernetesサービスのネットワーク・ロード・バランサをプロビジョニングする場合、IPパケットのヘッダーにクライアントIPアドレスを保持するか、保持しないようにするかを指定できます。
IPパケット・ヘッダーで指定されたクライアントIPアドレスでリクエストが終了した場合にのみ、クライアントIPアドレスを保持するオプションがあります。つまり、externalTrafficPolicy
設定がLocal
に設定されている場合です。externalTrafficPolicy
がCluster
に設定されている場合、クライアントIPアドレスは保持されません。「受信ノードでのリクエストの終了」を参照してください。
クライアントのIPアドレスが保持されないようにするには、マニフェストファイルのメタデータセクションに次の注釈を追加します。
oci-network-load-balancer.oraclecloud.com/is-preserve-source: "false"
クライアントのIPアドレスを保持するには、マニフェストファイルのメタデータセクションに次の注釈を追加します。
oci-network-load-balancer.oraclecloud.com/is-preserve-source: "true"
true
は、oci-network-load-balancer.oraclecloud.com/is-preserve-source
注釈のデフォルト値です。サービス定義に注釈を明示的に含めない場合は、注釈のデフォルト値が使用されます。
また、externalTrafficPolicy
がCluster
に設定されている場合、oci-network-load-balancer.oraclecloud.com/is-preserve-source
注釈の値に関係なく、クライアントIPアドレスは保持されません。externalTrafficPolicy
がCluster
に設定され、oci-network-load-balancer.oraclecloud.com/is-preserve-source
注釈がtrue
またはfalse
に明示的に設定されている場合、リクエストはエラーで失敗します。したがって、externalTrafficPolicy
がCluster
に設定されている場合、oci-network-load-balancer.oraclecloud.com/is-preserve-source
注釈を追加しないでください。
管理対象ノード・プールを使用する場合、クライアントIPアドレスは保持できますが、仮想ノード・プールを使用する場合には保持できません。
クライアントIPアドレスを保持するには、次のセキュリティ・ルールも設定しておく必要があります。
- クライアント接続が行われるCIDRブロックからすべてのノード・ポート(
30000 to 32767
)へのイングレス・トラフィックを許可するには、クラスタ内のワーカー・ノードのセキュリティ・ルール(ネットワーク・セキュリティ・グループ(推奨)またはセキュリティ・リスト(あるいはその両方)内)を設定する必要があります。アプリケーションがインターネットに公開されている場合は、セキュリティ・ルールのソースCIDRブロックを0.0.0.0/0に設定します。または、セキュリティ・ルールのソースCIDRブロックを特定のCIDRブロックに設定します(たとえば、クライアント接続が特定のサブネットからの場合)。状態 ソース プロトコル/宛先ポート 説明 ステートフル 0.0.0.0/0またはサブネットCIDR すべて/30000-32767 ワーカー・ノードがOCI Network Load Balancerを介して接続を受信できるようにします。 -
ロード・バランサおよびネットワーク・ロード・バランサのセキュリティ・ルールの説明に従って、ネットワーク・ロード・バランサのイングレス・セキュリティ・ルールおよびエグレス・セキュリティ・ルールを設定する必要があります。
たとえば、クライアントIPアドレスの保存を防止するKubernetesサービス定義を次に示します:
apiVersion: v1
kind: Service
metadata:
name: my-nginx-svc
labels:
app: nginx
annotations:
oci.oraclecloud.com/load-balancer-type: "nlb"
oci-network-load-balancer.oraclecloud.com/oci-network-security-groups: "ocid1.networksecuritygroup.oc1.phx.aaaaaa....vdfw"
oci-network-load-balancer.oraclecloud.com/is-preserve-source: "false"
spec:
type: LoadBalancer
externalTrafficPolicy: Local
ports:
- port: 80
selector:
app: nginx
TCPおよびUDPアプリケーションの公開
KubernetesエンジンがLoadBalancerタイプのKubernetesサービスのネットワーク・ロード・バランサをプロビジョニングする場合、リスナーが接続リクエストを受け入れるプロトコルを指定することによって、リスナーが受け入れるトラフィック・タイプを定義できます。
プロトコルを明示的に指定しない場合は、デフォルト値として「TCP」が使用されます。
KubernetesエンジンがLoadBalancerタイプのKubernetesサービスのネットワーク・ロード・バランサをプロビジョニングするときにリスナー・プロトコルを明示的に指定するには、マニフェスト・ファイルのspecセクションに次の設定を追加します:
protocol: <value>
<value>
は、リスナーが受け入れたトラフィックのタイプを定義するプロトコルです。たとえば、"UDP"です。有効なプロトコルは「UDP」と「TCP」です。
例:
apiVersion: v1
kind: Service
metadata:
name: my-nginx-svc
labels:
app: nginx
annotations:
oci.oraclecloud.com/load-balancer-type: "nlb"
spec:
type: LoadBalancer
ports:
- port: 80
protocol: UDP
selector:
app: nginx
バックエンド・セット・ポリシーの指定
Kubernetes EngineがLoadBalancerタイプのKubernetesサービスのネットワーク・ロード・バランサをプロビジョニングする場合、バックエンド・セットのポリシーを定義して、受信トラフィックをバックエンド・サーバーに分散する方法を指定できます。詳細は、ネットワーク・ロード・バランサ・ポリシーを参照してください。
バックエンド・セットのポリシーを明示的に指定しない場合、「FIVE_TUPLE」がデフォルト値として使用されることに注意してください。
KubernetesエンジンがLoadBalancerタイプのKubernetesサービスのネットワーク・ロード・バランサをプロビジョニングするときにバックエンド・セットのポリシーを指定するには、マニフェスト・ファイルのメタデータ・セクションに次の注釈を追加します:
oci-network-load-balancer.oraclecloud.com/backend-policy: <value>
<value>
は次のいずれかです:
"TWO_TUPLE"
: 受信トラフィックが2タプル(ソースIP、宛先IP)のハッシュに基づいてルーティングされます。"THREE_TUPLE"
: 受信トラフィックが3タプル(ソースIP、宛先IP、プロトコル)のハッシュに基づいてルーティングされます。"FIVE_TUPLE"
: 受信トラフィックが5タプル(ソースIPおよびポート、宛先IPおよびポート、プロトコル)のハッシュに基づいてルーティングされます。
例:
apiVersion: v1
kind: Service
metadata:
name: my-nginx-svc
labels:
app: nginx
annotations:
oci.oraclecloud.com/load-balancer-type: "nlb"
oci-network-load-balancer.oraclecloud.com/backend-policy: "THREE_TUPLE"
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: nginx
OCI Network Load Balancerのプロビジョニング時のセキュリティ・リスト管理オプションの指定
複雑なデプロイメントおよびTerraformなどのツールでKubernetesセキュリティ・リスト管理機能を使用すると、スケーラビリティやその他の問題が発生する場合があります。このような理由から、本番環境でのKubernetesセキュリティ・リスト管理機能の使用はお薦めしません。
また、セキュリティ・リストを使用してセキュリティ・ルールを管理する機能は、将来のリリースで非推奨になることに注意してください。このため、Oracleでは、ネットワーク・セキュリティ・グループ(NSG)およびoci.oraclecloud.com/security-rule-management-mode
注釈(ロード・バランサおよびネットワーク・ロード・バランサのセキュリティ・ルール管理オプションの指定を参照)を使用することをお薦めします。
セキュリティ・リスト管理機能を使用して、KubernetesエンジンがタイプLoadBalancerのKubernetesサービス用にプロビジョニングするOracle Cloud Infrastructureネットワーク・ロード・バランサに対してセキュリティ・リスト・ルールを管理する方法を構成できます。この機能は、Kubernetesを初めて使用する場合や、基本的なデプロイメントの場合に便利です。
KubernetesエンジンがLoadBalancerタイプのKubernetesサービスのネットワーク・ロード・バランサをプロビジョニングするときに、Kubernetesのセキュリティ・リスト管理機能でセキュリティ・リストがどのように管理されるかを指定するには、マニフェスト・ファイルのメタデータ・セクションに次の注釈を追加します:
oci-network-load-balancer.oraclecloud.com/security-list-management-mode: <value>
<value>
は次のいずれかです:
"None"
: (デフォルトおよび推奨)セキュリティ・リスト管理は有効になりません。ノード・ポート範囲、kube-proxyヘルス・ポートおよびヘルス・チェック・ポート範囲の適切なポートへのインバウンド・トラフィックを許可するセキュリティ・ルールを設定する必要があります。さらに、ネットワーク・ロード・バランサへのインバウンド・トラフィックを許可するようにセキュリティ・ルールを設定する必要があります(ロード・バランサおよびネットワーク・ロード・バランサのセキュリティ・ルールを参照)。"All"
: ネットワーク・ロード・バランサ・サービスに必要なすべてのセキュリティ・リスト・ルールが管理されます。"Frontend"
: ネットワーク・ロード・バランサ・サービスへのイングレスのセキュリティ・リスト・ルールのみが管理されます。ノード・ポート範囲、kube-proxyヘルス・ポートおよびヘルス・チェック・ポート範囲の適切なポートへのインバウンド・トラフィックを許可するセキュリティ・ルールを設定する必要があります。
Oracleでは、oci-network-load-balancer.oraclecloud.com/security-list-management-mode
を明示的にNone
に設定することをお薦めします。
管理対象ノードがあるクラスタでは、管理モードを明示的に指定しない場合、セキュリティ・リスト管理は有効化されません("None"
と同等)。仮想ノードを持つクラスタでは、セキュリティ・リスト管理は有効化されず、セキュリティ・ルールを常に手動で構成する必要があります("None"
と同等)。
セキュリティ・リストで許可されるイングレスおよびエグレス・ルールの数に制限があることに注意してください(セキュリティ・リストの制限を参照)。イングレス・ルールまたはエグレス・ルールの数が制限を超え、<value>
が"All"
または"Frontend"
に設定されている場合、ロード・バランサの作成または更新は失敗します。
例:
apiVersion: v1
kind: Service
metadata:
name: my-nginx-svc
labels:
app: nginx
annotations:
oci.oraclecloud.com/load-balancer-type: "nlb"
oci-network-load-balancer.oraclecloud.com/security-list-management-mode: "Frontend"
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: nginx