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の注釈の指定

タイプLoadBalancerのKubernetesサービス用にOracle Cloud Infrastructureロード・バランサをプロビジョニングするには、タイプLoadBalancerのサービスを定義します。このサービスには、マニフェスト・ファイルのメタデータ・セクションに次の注釈が含まれます。
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証明書を更新するには:
  1. 新しいTLS証明書を取得します。本番環境では、最も一般的なシナリオは、認証局によって署名された公開証明書を使用することです。
  2. 新しいKubernetesシークレットを作成します。たとえば、次のように入力します:

    kubectl create secret tls new-ssl-certificate-secret --key new-tls.key --cert new-tls.crt
    
  3. サービス構成の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
  4. サービスを更新します。たとえば、次のように入力します:
    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シークレットを作成する必要があります。

次の例では、自己署名証明書を作成および使用します。自己署名証明書は、通常、ロード・バランサとバックエンド・セット間の内部通信で受け入れられます。ただし、必要に応じて、認証局によって署名された公開証明書を使用できます。

例:

  1. 次の情報を入力して、秘密キーを生成します。

    openssl genrsa -out ca.key 2048
  2. 次のように入力して証明書を生成します。

    openssl req -x509 -new -nodes -key ca.key -subj "/CN=nginxsvc/O=nginxsvc" -days 10000 -out ca.crt
  3. 次のように入力して、証明書およびキーをシークレットとして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
  4. 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
---
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