LoadBalancerタイプのKubernetesサービスに対するOCI Load Balancerのプロビジョニング
Kubernetes Engine (OKE)を使用して、LoadBalancerタイプのKubernetesサービスにOCIロード・バランサをプロビジョニングする方法をご覧ください。
OCIロード・バランサはOSIレイヤー4 (TCP)およびレイヤー7 (HTTP)プロキシで、SSL終了や高度なHTTPルーティング・ポリシーなどの機能をサポートします。レスポンシブなスケール・アップとスケール・ダウンにより、最大限の柔軟性を提供します。10 Mbpsと8,000 Mbpsの両方で、カスタムの最小帯域幅とオプションの最大帯域幅を選択します。最小帯域幅は常に使用可能であり、ワークロードに対してすぐに準備できます。
OCIロード・バランサの詳細は、Load Balancerの概要を参照してください。
タイプLoadBalancerのKubernetesサービスに対してOCIロード・バランサをプロビジョニングすると、次のことが可能になります:
- レイヤ4およびレイヤ7 (TCPおよびHTTP)トラフィック
- ロード・バランサでのSSL/TLSの終了
KubernetesエンジンがLoadBalancerタイプのKubernetesサービスのOCIロード・バランサをプロビジョニングすると、ロード・バランサのサブネットとの間のインバウンドおよびアウトバウンド・トラフィックを許可するセキュリティ・ルールがデフォルトで自動的に作成されます。ロード・バランサおよびネットワーク・ロード・バランサのセキュリティ・ルールを参照してください。
OCIロード・バランサ・メトリックを使用して、LoadBalancerタイプのKubernetesサービス用にプロビジョニングされたOCIロード・バランサのヘルスを監視します(Load Balancerメトリックを参照)。
OCI Load Balancerの注釈の指定
oci.oraclecloud.com/load-balancer-type: "lb"
lb
は、oci.oraclecloud.com/load-balancer-type
注釈のデフォルト値です。サービス定義に注釈を明示的に含めない場合は、注釈のデフォルト値が使用されます。
たとえば、nginx_lb.yaml
という構成ファイルがあるとします。これは、nginx
アプリケーションのデプロイメント(kind: Deployment
)を定義し、その後に、nginx
アプリケーションのポート80でhttpトラフィックを分散するLoadBalancer (type: LoadBalancer
)タイプのサービスを定義します。
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: my-nginx-svc
labels:
app: nginx
annotations:
oci.oraclecloud.com/load-balancer-type: "lb"
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: nginx
構成ファイルの最初の部分ではNginxデプロイメントを定義しており、nginx:latest
イメージを実行する3つのポッドでホストされ、ポート80のコンテナへのトラフィックを受け入れることをリクエストしています。
構成ファイルの2番目の部分ではNginxサービスを定義しており、これは、タイプLoadBalancerを使用して、使用可能なポッド間でポート80のNginxトラフィックのバランスをとります。
Kubernetesクラスタへの接続中にnginx_lb.yaml
で定義されるデプロイメントとサービスを作成するには、次のコマンドを入力します:
kubectl apply -f nginx_lb.yaml
このコマンドは、デプロイメントおよびロード・バランサの作成が成功すると、次の内容を出力します:
deployment "my-nginx" created
service "my-nginx-svc" created
ロード・バランサが保留中の状態から完全に動作するまでには、数分かかる場合があります。次のように入力すると、クラスタの現在の状態を表示できます:
kubectl get all
前述のコマンドの出力に、現在の状態が表示されます:
NAME READY STATUS RESTARTS AGE
po/my-nginx-431080787-0m4m8 1/1 Running 0 3m
po/my-nginx-431080787-hqqcr 1/1 Running 0 3m
po/my-nginx-431080787-n8125 1/1 Running 0 3m
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
svc/kubernetes 203.0.113.1 <NONE> 443/TCP 3d
svc/my-nginx-svc 203.0.113.7 192.0.2.22 80:30269/TCP 3m
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
deploy/my-nginx 3 3 3 3 3m
NAME DESIRED CURRENT READY AGE
rs/my-nginx-431080787 3 3 3 3m
出力は、my-nginx
デプロイメントが3つのポッドで実行され(po/my-nginxエントリ)、ロード・バランサが実行されていて(svc/my-nginx-svc)、ポッドにデプロイされたアプリケーションに接続するためにクライアントが使用できる外部IP (192.0.2.22)が含まれていることを示しています。
Load BalancerでのSSL/TLSの終了
Kubernetes EngineがLoadBalancerタイプのKubernetesサービスのロード・バランサをプロビジョニングする場合、ロード・バランサでSSLを終了するように指定できます。この構成はフロントエンドSSLと呼ばれます。フロントエンドSSLを実装するには、443などのポートでリスナーを定義し、SSL証明書をリスナーに関連付けます。
ワーカー・ノードで実行されているクライアントとアプリケーション・ポッド間の完全なポイントツーポイントSSL暗号化を実装できます。これを行うには、(この項で説明するように) SSL終端を持つロード・バランサを作成し、SSL証明書をロード・バランサのバックエンド・セットに関連付けます(「Load Balancerとワーカー・ノード間のSSL/TLSの実装」を参照)。
この例では、SSLサポートを使用したロード・バランサの構成および作成について順を追って詳しく説明します。
次の構成ファイルnginx-demo-svc-ssl.yaml
を考えてみます。これはNginxデプロイメントを定義し、ポート80でhttpを、ポート443でhttpsを処理するロード・バランサ経由で公開します。このサンプルでは、タイプがLoadBalancer (type: LoadBalancer
)のサービスを定義することで、Oracle Cloud Infrastructureロード・バランサを作成します。
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
name: nginx-service
annotations:
oci.oraclecloud.com/load-balancer-type: "lb"
service.beta.kubernetes.io/oci-load-balancer-ssl-ports: "443"
oci.oraclecloud.com/oci-load-balancer-listener-ssl-config: '{"CipherSuiteName":"oci-default-http2-tls-12-13-ssl-cipher-suite-v1", "Protocols":["TLSv1.3"]}'
service.beta.kubernetes.io/oci-load-balancer-tls-secret: ssl-certificate-secret
spec:
selector:
app: nginx
type: LoadBalancer
ports:
- name: http
port: 80
targetPort: 80
- name: https
port: 443
targetPort: 80
ここで説明するように、ロード・バランサの注釈は非常に重要です。
httpsトラフィックをサポートするポートは、service.beta.kubernetes.io/oci-load-balancer-ssl-ports注釈の値によって定義されます。注釈の値のカンマ区切りリストを使用して、複数のSSLポートを宣言できます。たとえば、注釈の値を「443, 3000」に設定して、ポート443および3000でSSLをサポートできます。
ロード・バランサで使用する暗号スイートは、oci.oraclecloud.com/oci-load-balancer-listener-ssl-config注釈の値によって定義されます。暗号スイートは、HTTPSトラフィックのセキュリティ、互換性および速度を決定します(詳細は、ロード・バランサの暗号スイートを参照)。暗号スイート名(oci-default-http2-TLS-12-13-ssl-cipher-suite-v1など)とTLSバージョン(TLSv1.3など)の両方を指定します。Oracle Cloud Infrastructureによって事前構成された事前定義済の暗号スイート(事前定義済ロード・バランサ暗号スイートを参照)または自分で作成した暗号スイートを指定できます。oci.oraclecloud.com/oci-load-balancer-listener-ssl-config注釈を含めずにservice.beta.kubernetes.io/oci-load-balancer-tls-secret注釈を含めると、oci-default-ssl-cipher-suite-v1暗号スイートが使用されます。
必要なTLSシークレットssl-certificate-secretをKubernetesで作成する必要があります。この例では、自己署名証明書を作成して使用します。ただし、本番環境では、最も一般的なシナリオは、認証局によって署名された公開証明書を使用することです。
次のコマンドでは、自己署名証明書tls.crt
が、対応するキーtls.key
とともに作成されます:
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=nginxsvc/O=nginxsvc"
証明書を作成したので、証明書とそのキーの両方をKubernetesにシークレットとして格納する必要があります。シークレットの名前は、ロード・バランサの定義のservice.beta.kubernetes.io/oci-load-balancer-tls-secret注釈の名前と一致する必要があります。次のコマンドを使用して、KubernetesにTLSシークレットを作成します。そのキーと証明書の値は、それぞれ--key
と--cert
によって設定されます。
kubectl create secret tls ssl-certificate-secret --key tls.key --cert tls.crt
サービスはシークレットの定義でシークレットを参照するため、サービスを作成する前にKubernetesシークレットを作成する必要があります。次のコマンドを使用して、サービスを作成します:
kubectl create -f manifests/demo/nginx-demo-svc-ssl.yaml
次のように入力して、サービスを監視し、パブリックIPアドレス(EXTERNAL-IP)がNginxサービス(nginx-service)に割り当てられるまで待機します:
kubectl get svc --watch
前述のコマンドの出力に、サービスへの接続に使用するロード・バランサIPが表示されます。
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-service 192.0.2.1 198.51.100.1 80:30274/TCP 5m
ロード・バランサは実行されています。つまり、次のようにサービスにアクセスできます:
- 次のように入力してhttpを使用します:
curl http://198.51.100.1
- 次のように入力してhttpsを使用します:
curl --insecure https://198.51.100.1
この例では自己署名証明書が使用されているため、httpsを使用してサービスにアクセスするには
--insecure
フラグを使用します。パブリック証明書が認証局によって署名された本番環境では、このフラグを使用しないでください。
ノート: クラスタが削除されても、サービスの作成時に動的に作成されるロード・バランサは削除されません。クラスタを削除する前に、サービスを削除します。これにより、ロード・バランサが削除されます。このコマンドの構文は次のとおりです:
kubectl delete svc SERVICE_NAME
たとえば、前の例からサービスを削除するには、次のように入力します:
kubectl delete svc nginx-service
既存のロード・バランサのTLS証明書の更新
- 新しいTLS証明書を取得します。本番環境では、最も一般的なシナリオは、認証局によって署名された公開証明書を使用することです。
-
新しいKubernetesシークレットを作成します。たとえば、次のように入力します:
kubectl create secret tls new-ssl-certificate-secret --key new-tls.key --cert new-tls.crt
- サービス構成の
service.beta.kubernetes.io/oci-load-balancer-tls-secret
注釈を変更して、新しいKubernetesシークレットを参照するようにサービス定義を変更します。例:apiVersion: v1 kind: Service metadata: name: nginx-service annotations: service.beta.kubernetes.io/oci-load-balancer-ssl-ports: "443" service.beta.kubernetes.io/oci-load-balancer-tls-secret: new-ssl-certificate-secret spec: selector: app: nginx type: LoadBalancer ports: - name: http port: 80 targetPort: 80 - name: https port: 443 targetPort: 80
- サービスを更新します。たとえば、次のように入力します:
kubectl apply -f new-nginx-demo-svc-ssl.yaml
Load Balancerとワーカー・ノード間のSSL/TLSの実装
Kubernetes EngineがLoadBalancerタイプのKubernetesサービスのロード・バランサをプロビジョニングする場合、ロード・バランサとバックエンド・セット内のバックエンド・サーバー(ワーカー・ノード)の間にSSLを実装するように指定できます。この構成はバックエンドSSLと呼ばれます。バックエンドSSLを実装するには、SSL証明書をロード・バランサのバックエンド・セットに関連付けます。
ワーカー・ノードで実行されているクライアントとアプリケーション・ポッド間の完全なポイントツーポイントSSL暗号化を実装できます。これを行うには、SSL証明書をロード・バランサのバックエンド・セットに関連付け(この項を参照)、SSL終了を使用してロード・バランサを作成します(Load BalancerでのSSL/TLSの終了を参照)。
暗号スイートは、HTTPSトラフィックのセキュリティ、互換性および速度を決定します(詳細は、ロード・バランサの暗号スイートを参照)。ロード・バランサのバックエンド・セットで使用する暗号スイートを指定するには、マニフェスト・ファイルのメタデータ・セクションに次の注釈を追加します:
oci.oraclecloud.com/oci-load-balancer-backendset-ssl-config: '{"CipherSuiteName":"<cipher-suite-name>", "Protocols":["<tls-version>"]}'
ここでは:
"CipherSuiteName":"<cipher-suite-name>"
は、Oracle Cloud Infrastructureによって事前構成された事前定義済の暗号スイートの名前(「事前定義済のロード・バランサ暗号スイート」を参照)、または自分で作成した暗号スイートの名前です。たとえば、"CipherSuiteName":"oci-default-http2-tls-12-13-ssl-cipher-suite-v1"
です。"Protocols":["<tls-version>"]
は、1つ以上のTLSバージョンをカンマ区切りリストで指定します。たとえば、"Protocols":["TLSv1.2", "TLSv1.3"]
例:
oci.oraclecloud.com/oci-load-balancer-backendset-ssl-config: '{"CipherSuiteName":"oci-default-http2-tls-12-13-ssl-cipher-suite-v1", "Protocols":["TLSv1.2", "TLSv1.3"]}'
oci.oraclecloud.com/oci-load-balancer-backendset-ssl-config
アノテーションを含めずにservice.beta.kubernetes.io/oci-load-balancer-tls-backendset-secret
アノテーションを含めると、oci-wider-compatible-ssl-cipher-suite-v1暗号スイートが使用されます。
バックエンド・セットに関連付ける証明書を指定するには、マニフェスト・ファイルのメタデータ・セクションに次の注釈を追加します:
service.beta.kubernetes.io/oci-load-balancer-tls-backendset-secret: <value>
<value>
は、署名付き証明書と証明書への秘密キーを含めるために作成したKubernetesシークレットの名前です。サービスはシークレットの定義でシークレットを参照するため、サービスを作成する前にKubernetesシークレットを作成する必要があります。
次の例では、自己署名証明書を作成および使用します。自己署名証明書は、通常、ロード・バランサとバックエンド・セット間の内部通信で受け入れられます。ただし、必要に応じて、認証局によって署名された公開証明書を使用できます。
例:
次の情報を入力して、秘密キーを生成します。
openssl genrsa -out ca.key 2048
次のように入力して証明書を生成します。
openssl req -x509 -new -nodes -key ca.key -subj "/CN=nginxsvc/O=nginxsvc" -days 10000 -out ca.crt
次のように入力して、証明書およびキーをシークレットとしてKubernetesに格納します:
kubectl create secret generic ca-ser-secret --from-file=tls.crt=tls.crt --from-file=tls.key=tls.key --from-file=ca.crt=ca.crt
- Nginxデプロイメントを定義し、ポート80でhttp、ポート443でhttpsを提供するロード・バランサを介して公開します。
(type: LoadBalancer
のサービスを定義することで、Oracle Cloud Infrastructureロード・バランサを作成します。 apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
---
apiVersion: v1
metadata:
name: nginx-service
annotations:
oci.oraclecloud.com/load-balancer-type: "lb"
oci.oraclecloud.com/oci-load-balancer-backendset-ssl-config: '{"CipherSuiteName":"oci-default-http2-tls-12-13-ssl-cipher-suite-v1", "Protocols":["TLSv1.2", "TLSv1.3"]}'
service.beta.kubernetes.io/oci-load-balancer-tls-backendset-secret: ca-ser-secret
service.beta.kubernetes.io/oci-load-balancer-ssl-ports: "443"
spec:
selector:
app: nginx
type: LoadBalancer
ports:
- name: http
port: 80
targetPort: 80
- name: https
port: 443
targetPort: 443
ロード・バランサとバックエンド・セット内のワーカー・ノード間の通信は、前に作成したca-ser-secret
Kubernetesシークレットに格納されているキーおよび証明書を使用して暗号化されます。
代替ロード・バランサ・シェイプの指定
Oracle Cloud Infrastructureロード・バランサのシェイプによって、その最大合計帯域幅(イングレスとエグレス)が指定されます。デフォルトでは、ロード・バランサは100Mbpsのシェイプで作成されます。他のシェイプ(400Mbpsや8000Mbpsなど)も使用できます。
ロード・バランサの代替のシェイプを指定するには、マニフェスト・ファイルのメタデータ・セクションに次の注釈を追加します:
service.beta.kubernetes.io/oci-load-balancer-shape: <value>
value
はシェイプの帯域幅です(たとえば、100Mbps、400Mbps、8000Mbps)。
例:
apiVersion: v1
kind: Service
metadata:
name: my-nginx-svc
labels:
app: nginx
annotations:
oci.oraclecloud.com/load-balancer-type: "lb"
service.beta.kubernetes.io/oci-load-balancer-shape: 400Mbps
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: nginx
指定するシェイプに対して、十分なロード・バランサの割当てがリージョンで使用できる必要があります。次のkubectlコマンドを入力して、ロード・バランサの作成が割当ての不足によって失敗しなかったことを確認します:
kubectl describe service <service-name>
Oracleでは、固定シェイプ(動的)ロード・バランサではなく、コスト効率の高い柔軟なロード・バランサとしてLoadBalancerタイプのKubernetesサービスを実装することをお薦めします(フレキシブルLoad Balancerシェイプの指定を参照)。
フレキシブルなロード・バランサのシェイプの指定
Oracle Cloud Infrastructureロード・バランサのシェイプによって、その最大合計帯域幅(イングレスとエグレス)が指定されます。代替ロード・バランサ・シェイプの指定で説明されているように、異なるロード・バランサのシェイプを指定できます。
また、ロード・バランサの最小帯域幅と最大帯域幅を定義して、Oracle Cloud Infrastructureロード・バランサのフレキシブル・シェイプを指定することもできます。
ロード・バランサにフレキシブル・シェイプを指定するには、マニフェスト・ファイルのメタデータ・セクションに次の注釈を追加します:
service.beta.kubernetes.io/oci-load-balancer-shape: "flexible"
service.beta.kubernetes.io/oci-load-balancer-shape-flex-min: "<min-value>"
service.beta.kubernetes.io/oci-load-balancer-shape-flex-max: "<max-value>"
ここでは:
"<min-value>"
は、Mbps単位のロード・バランサの最小帯域幅です(「10」など)。"<max-value>"
は、Mbps単位のロード・バランサの最大帯域幅です(「100」など)
フレキシブルなロード・バランサのシェイプに帯域幅の値を指定する場合は、測定単位を含めないことに注意してください(事前定義済シェイプの場合とは異なります)。たとえば、最小帯域幅を10Mbps
ではなく10
と指定します。
例:
apiVersion: v1
kind: Service
metadata:
name: my-nginx-svc
labels:
app: nginx
annotations:
oci.oraclecloud.com/load-balancer-type: "lb"
service.beta.kubernetes.io/oci-load-balancer-shape: "flexible"
service.beta.kubernetes.io/oci-load-balancer-shape-flex-min: "10"
service.beta.kubernetes.io/oci-load-balancer-shape-flex-max: "100"
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: nginx
ロード・バランサ接続タイムアウトの指定
タイプLoadBalancerのKubernetesサービスに対してOracle Cloud Infrastructureロード・バランサをプロビジョニングする際には、クライアントとバックエンド・サーバー間の連続する2つの受信操作または連続する2つの送信操作の間に許容される最大アイドル時間(秒)を指定できます。
最大アイドル時間を明示的に指定するには、マニフェスト・ファイルのメタデータ・セクションに次の注釈を追加します:
service.beta.kubernetes.io/oci-load-balancer-connection-idle-timeout: <value>
value
は秒数です。
例:
apiVersion: v1
kind: Service
metadata:
name: my-nginx-svc
labels:
app: nginx
annotations:
oci.oraclecloud.com/load-balancer-type: "lb"
service.beta.kubernetes.io/oci-load-balancer-connection-idle-timeout: 100
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: nginx
最大アイドル時間を明示的に指定しない場合は、デフォルト値が使用されます。デフォルト値は、リスナーのタイプによって異なります:
- TCPリスナーの場合、デフォルトの最大アイドル時間は300秒です
- HTTPリスナーの場合、デフォルトの最大アイドル時間は60秒です
リスナー・プロトコルの指定
KubernetesエンジンがタイプLoadBalancerのKubernetesサービスのロード・バランサをプロビジョニングする場合、リスナーが接続リクエストを受け入れるプロトコルを指定することによって、リスナーが受け入れるトラフィックのタイプを定義できます。
プロトコルを明示的に指定しない場合は、デフォルト値として「TCP」が使用されます。
KubernetesエンジンがLoadBalancerタイプのKubernetesサービスのロード・バランサをプロビジョニングするときにロード・バランサ・リスナー・プロトコルを明示的に指定するには、マニフェスト・ファイルのメタデータ・セクションに次の注釈を追加します:
service.beta.kubernetes.io/oci-load-balancer-backend-protocol: <value>
<value>
は、リスナーが受け入れたトラフィックのタイプを定義するプロトコルです。たとえば、"HTTP"です。有効なプロトコルは「HTTP」と「TCP」です。
例:
apiVersion: v1
kind: Service
metadata:
name: my-nginx-svc
labels:
app: nginx
annotations:
oci.oraclecloud.com/load-balancer-type: "lb"
service.beta.kubernetes.io/oci-load-balancer-backend-protocol: "HTTP"
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: nginx
OCI 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のセキュリティ・リスト管理機能でセキュリティ・リストがどのように管理されるかを指定するには、マニフェスト・ファイルのメタデータ・セクションに次の注釈を追加します:
service.beta.kubernetes.io/oci-load-balancer-security-list-management-mode: <value>
<value>
は次のいずれかです:
"None"
: (推奨)セキュリティ・リスト管理は有効になりません。ノード・ポート範囲、kube-proxyヘルス・ポートおよびヘルス・チェック・ポート範囲の適切なポートへのインバウンド・トラフィックを許可するセキュリティ・ルールを設定する必要があります。さらに、セキュリティ・ルールを設定して、ロード・バランサへのインバウンド・トラフィックを許可する必要があります(ロード・バランサおよびネットワーク・ロード・バランサのセキュリティ・ルールを参照)。"All"
: (デフォルト)ロード・バランサ・サービスに必要なすべてのセキュリティ・リスト・ルールが管理されます。"Frontend"
: ロード・バランサ・サービスへのイングレスのセキュリティ・リスト・ルールのみが管理されます。ノード・ポート範囲、kube-proxyヘルス・ポートおよびヘルス・チェック・ポート範囲の適切なポートへのインバウンド・トラフィックを許可するセキュリティ・ルールを設定する必要があります。
Oracleでは、service.beta.kubernetes.io/oci-load-balancer-security-list-management-mode
を明示的にNone
に設定することをお薦めします。
管理対象ノードがあるクラスタで、管理モードを明示的に指定しない場合、または無効な値を指定した場合、すべてのセキュリティ・リスト・ルールが管理されます("All"
と同等)。この場合、Kubernetes Engineは、0.0.0.0/0 (またはマニフェスト・ファイルで指定されたソース・ポート範囲)からリスナー・ポートへのインバウンド・トラフィックを許可するセキュリティ・ルールを作成することに注意してください。仮想ノードを持つクラスタでは、セキュリティ・リスト管理は有効化されず、セキュリティ・ルールを常に手動で構成する必要があります("None"
と同等)。
セキュリティ・リストで許可されるイングレスおよびエグレス・ルールの数に制限があることに注意してください(セキュリティ・リストの制限を参照)。イングレス・ルールまたはエグレス・ルールの数が制限を超え、<value>
が"All"
または"Frontend"
に設定されている場合、ロード・バランサの作成または更新は失敗します。
例:
apiVersion: v1
kind: Service
metadata:
name: my-nginx-svc
labels:
app: nginx
annotations:
oci.oraclecloud.com/load-balancer-type: "lb"
service.beta.kubernetes.io/oci-load-balancer-security-list-management-mode: "Frontend"
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: nginx