ロード・バランサおよびネットワーク・ロード・バランサの構成

Oracle Cloud Infrastructureロード・バランサおよびネットワーク・ロード・バランサを作成して、クラスタ上にあるサービスへのアクセスを制御できます:

• カスタム作成ワークフローでクラスタを作成する場合、新しいクラスタで使用するネットワーク・リソースを含む既存のVCNを選択します。ロード・バランサまたはネットワーク・ロード・バランサを使用してVCN内のトラフィックを制御する場合は、そのVCN内の既存のパブリック・サブネットまたはプライベート・サブネットを選択してそれをホストします。
• クイック作成ワークフローでクラスタを作成する場合、自動的に作成されるVCNには、ロード・バランサまたはネットワーク・ロード・バランサをホストするためのパブリック・リージョン・サブネットが含まれます。ロード・バランサまたはネットワーク・ロード・バランサをプライベート・サブネットでホストする場合は、後でプライベート・サブネットをVCNに追加できます。

または、クラスタ内でLoadBalancerタイプの内部Kubernetesサービス(通常は単に「内部ロード・バランサ」と呼ばれます)を定義して、クラスタと同じVCNで実行されている他のプログラムがクラスタ内のサービスにアクセスできるようにすることもできます。内部ロード・バランサをプロビジョニングできます。

• ロード・バランサとして、またはネットワーク・ロード・バランサとして
• パブリックIPアドレス、またはプライベートIPアドレス(Load BalancerサービスまたはNetwork Load Balancerサービスによって割り当てられます)
• パブリック・サブネット内またはプライベート・サブネット内

パブリックIPアドレスを持つロード・バランサまたはネットワーク・ロード・バランサは、パブリックと呼ばれます。パブリック・ロード・バランサまたはネットワーク・ロード・バランサは、パブリック・サブネットまたはプライベート・サブネットでホストできます。

プライベートIPアドレスを持つロード・バランサまたはネットワーク・ロード・バランサは、プライベートと呼ばれます。プライベート・ロード・バランサまたはネットワーク・ロード・バランサは、パブリック・サブネットまたはプライベート・サブネットでホストできます。

デフォルトでは、内部ロード・バランサはパブリックIPアドレスでプロビジョニングされ、パブリック・サブネットでホストされます。

詳細は次を参照してください。

• Oracle Cloud Infrastructureのパブリックおよびプライベートのロード・バランサについては、Load Balancerのタイプを参照してください。
• Oracle Cloud Infrastructureのパブリックおよびプライベート・ネットワーク・ロード・バランサについて、ネットワークLoad Balancerのタイプを参照してください

service.beta.kubernetes.io/oci-load-balancer-internal: "true"

service.beta.kubernetes.io/oci-load-balancer-internal: "true"

service.beta.kubernetes.io/oci-load-balancer-subnet1: "ocid1.subnet.oc1..aaaaaa....vdfw"

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-internal: "true"
    service.beta.kubernetes.io/oci-load-balancer-subnet1: "ocid1.subnet.oc1..aaaaaa....vdfw"
spec:
  type: LoadBalancer
  ports:
  - port: 8100
  selector:
    app: nginx

oci-network-load-balancer.oraclecloud.com/internal: "true"

oci-network-load-balancer.oraclecloud.com/internal: "true"

oci-network-load-balancer.oraclecloud.com/subnet: "ocid1.subnet.oc1..aaaaaa....vdfw"

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/internal: "true"
    oci-network-load-balancer.oraclecloud.com/subnet: "ocid1.subnet.oc1..aaaaaa....vdfw"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

タイプLoadBalancerのKubernetesサービスがクラスタにデプロイされると、Kubernetes Engineは、クラスタへのトラフィックを受け入れるOracle Cloud Infrastructureパブリック・ロード・バランサまたはネットワーク・ロード・バランサを作成します。デフォルトでは、Oracle Cloud Infrastructureのパブリック・ロード・バランサまたはネットワーク・ロード・バランサにエフェメラル・パブリックIPアドレスが割り当てられます。ただし、一時的パブリックIPアドレスは一時的であり、パブリック・ロード・バランサまたはネットワーク・ロード・バランサの存続期間中のみ続きます。

デプロイメント後にKubernetes Engineによって作成されるOracle Cloud Infrastructureパブリック・ロード・バランサまたはネットワーク・ロード・バランサに同じパブリックIPアドレス・デプロイメントを持たせる場合は、予約済パブリックIPv4アドレスのプールから予約済パブリックIPv4アドレスを割り当てることができます。予約済パブリックIPv4アドレスの作成および表示の詳細は、パブリックIPアドレスを参照してください。

予約済パブリックIPv4アドレスは、Kubernetes Engineによって作成されるOracle Cloud Infrastructureパブリック・ロード・バランサまたはネットワーク・ロード・バランサに、次のいずれかの方法で割り当てることができます:

• 方法1: oci.oraclecloud.com/reserved-ips注釈の使用(推奨)
• 方法2: spec.loadBalancerIPフィールドの使用

oci.oraclecloud.com/reserved-ips: "<reserved_ipv4_address>"

apiVersion: v1
kind: Service
metadata:
  name: my-lb-service
  annotations:
    oci.oraclecloud.com/reserved-ips: "10.0.0.1"
    oci.oraclecloud.com/load-balancer-type: "lb"
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 80
  selector:
    app: my-app

apiVersion: v1
kind: Service
metadata:
  name: my-nlb-service
  annotations:
    oci.oraclecloud.com/reserved-ips: "10.0.0.1"
    oci.oraclecloud.com/load-balancer-type: "nlb"
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 80
  selector:
    app: my-app

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
spec:
  loadBalancerIP: 144.25.97.173
  type: LoadBalancer
  ports:
    - port: 80
  selector:
    app: nginx

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "nlb"
spec:
  loadBalancerIP: 144.25.97.173
  type: LoadBalancer
  ports:
    - port: 80
  selector:
    app: nginx

Oracle Cloud Infrastructureネットワーク・セキュリティ・グループ(NSG)を使用すると、リソースとの間で、およびリソース間のトラフィックを制御できます。NSGに定義されたセキュリティ・ルールにより、そのNSG内のすべてのリソースが同じセキュリティ・ポスチャを持つことが保証されます。詳細は、ネットワーク・セキュリティ・グループを参照してください。

NSGを使用して、KubernetesエンジンがタイプLoadBalancerのKubernetesサービスにプロビジョニングするOracle Cloud Infrastructureロード・バランサまたはネットワーク・ロード・バランサへのアクセスを制御できます。

NSGを使用してアクセスを制御する場合は、ロード・バランサまたはネットワーク・ロード・バランサのサブネットとの間でインバウンドおよびアウトバウンド・トラフィックを許可するための適切なセキュリティ・ルールが存在する必要があります。ロード・バランサおよびネットワーク・ロード・バランサのセキュリティ・ルールを参照してください。

NSGを使用してロード・バランサまたはネットワーク・ロード・バランサへのアクセスを制御する場合:

• NSGおよびセキュリティ・ルールは、oci-cloud-controller-managerによって完全に管理できます(ロード・バランサおよびネットワーク・ロード・バランサのセキュリティ・ルール管理オプションの指定を参照)。
• NSGおよびセキュリティ・ルールを自分で管理し、ロード・バランサまたはネットワーク・ロード・バランサを既存のNSGに追加できます(この項を参照)。
• oci-cloud-controller-managerは、あるNSGで一部のセキュリティ・ルールを管理し、別のNSGで他のセキュリティ・ルールを管理するようにできます。

管理するNSGを使用してアクセスを制御するには、マニフェスト・ファイルに注釈を含めて、ロード・バランサまたはネットワーク・ロード・バランサを追加するNSGを指定します。

oci.oraclecloud.com/oci-network-security-groups: "<nsg-ocid>"

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    oci.oraclecloud.com/oci-network-security-groups: "ocid1.networksecuritygroup.oc1.phx.aaaaaa....vdfw"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

oci-network-load-balancer.oraclecloud.com/oci-network-security-groups: "<nsg-ocid>"

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
  ports:
  - port: 80
  selector:
    app: nginx

次の点に注意してください:

• 指定するNSGは、Oracle Cloud Infrastructureロード・バランサまたはネットワーク・ロード・バランサと同じVCN内にある必要があります。
• 指定したNSGがクラスタの別のコンパートメントに属している場合は、IAMポリシーに次のようなポリシー・ステートメントを含める必要があります:

  ALLOW any-user to use network-security-groups in TENANCY where ALL { request.principal.type = 'cluster' }

  このポリシー・ステートメントが許容しすぎると考えられる場合は、NSGが属するコンパートメントを明示的に指定したり、クラスタを明示的に指定したりする権限を制限できます。例:

  Allow any-user to use network-security-groups in compartment <compartment-ocid> where all { request.principal.id = '<cluster-ocid>' }

• 次の形式で、最大5つのNSGをカンマ区切りリストで指定できます。

  oci.oraclecloud.com/oci-network-security-groups: "<nsg1-ocid>,<nsg2-ocid>,<nsg3-ocid>,<nsg4-ocid>,<nsg5-ocid>"

• NSGからロード・バランサまたはネットワーク・ロード・バランサを削除したり、ロード・バランサまたはネットワーク・ロード・バランサが存在するNSGを変更するには、注釈を更新してマニフェストを再適用します。

• 管理するNSGを使用してOracle Cloud Infrastructureロード・バランサまたはネットワーク・ロード・バランサへのアクセスを制御する場合、Oracleでは、ロード・バランサまたはネットワーク・ロード・バランサのマニフェスト・ファイルのメタデータ・セクションに次の注釈のいずれかをそれぞれ追加して、Kubernetesセキュリティ・リスト管理を無効にすることをお薦めします。

  service.beta.kubernetes.io/oci-load-balancer-security-list-management-mode: "None"

  oci-network-load-balancer.oraclecloud.com/security-list-management-mode:  "None"

  または、次の同等の注釈を追加できます。

  oci.oraclecloud.com/security-rule-management-mode: "None" 

  推奨事項に従って注釈を追加した場合、Kubernetesセキュリティ・リスト管理は有効になりません。ノード・プールおよびKubernetes APIエンドポイントのイングレスおよびエグレス・セキュリティ・ルールを使用してNSGを設定する必要があります(詳細は、ネットワーク・セキュリティ・グループまたはセキュリティ・リスト(あるいはその両方)のセキュリティ・ルール構成およびネットワーク・リソース構成の例を参照してください)。また、kube-proxyヘルス・ポート、ヘルス・チェック・ポート範囲およびロード・バランサのイングレスおよびエグレス・セキュリティ・ルールを使用してNSGを設定する必要があります。

セキュリティ・ルールは、タイプがLoadBalancerのKubernetesサービスに対してプロビジョニングされるOracle Cloud Infrastructureロード・バランサおよびネットワーク・ロード・バランサへのアクセスを制御します。セキュリティ・ルールは、次の方法で管理(作成、更新および削除)できます。

• ネットワーク・セキュリティ・グループまたはNSG (推奨) NSGのセキュリティ・ルールは、NSGに追加されたKubernetesリソースに適用されます。そのため、NSGは個々のリソースにきめ細かいアクセス制御を提供できます。
• セキュリティ・リスト内。 セキュリティ・リスト内のセキュリティ・ルールは、サブネット内のすべてのKubernetesリソースに適用されます。セキュリティ・リストは、サブネット内の個々のリソースに対するファイングレイン・アクセス制御を提供しません。

セキュリティ・ルールの仕組みに関する重要な情報、およびセキュリティ・リストとネットワーク・セキュリティ・グループの一般的な比較については、セキュリティ・ルールを参照してください。

必要に応じて、セキュリティ・ルールを自分で管理し、ルールを作成、更新および削除できます。または、oci-cloud-controller-manager (クラスタ・コントロール・プレーン上で実行)が、セキュリティ・ルールの一部またはすべてを管理することを指定することもできます。Kubernetes Engineは、oci-cloud-controller-managerを使用して、タイプLoadBalancerのKubernetesサービスのロード・バランサおよびネットワーク・ロード・バランサをプロビジョニングします。

oci-cloud-controller-managerがNSGまたはセキュリティ・リストのロード・バランサまたはネットワーク・ロード・バランサのセキュリティ・ルールを管理するかどうかを指定するには、次のように様々な注釈を使用します。

• NSGでセキュリティ・ルールを管理するには、oci.oraclecloud.com/security-rule-management-mode: "NSG"注釈を使用します(推奨)。

  oci-cloud-controller-managerでNSGのセキュリティ・ルールを管理する場合は(Oracleで推奨)、oci.oraclecloud.com/security-rule-management-mode: "NSG"注釈を使用する必要があります。この注釈の使用の詳細は、oci.oraclecloud.com/security-rule-management-mode注釈を使用したNSGおよびセキュリティ・リストのセキュリティ・ルールの管理を参照してください。

• セキュリティ・リスト内のセキュリティ・ルールを管理するには、oci.oraclecloud.com/security-rule-management-mode注釈を使用するか、service.beta.kubernetes.io/oci-load-balancer-security-list-management-modeおよびoci-network-load-balancer.oraclecloud.com/security-list-management-mode注釈を使用します。

  oci-cloud-controller-managerで、ロード・バランサまたはネットワーク・ロード・バランサのサブネットのセキュリティ・リストのセキュリティ・ルールを管理する場合は、次のいずれかを実行します:

  • "SL-All"または"SL-Frontend"に設定されたoci.oraclecloud.com/security-rule-management-mode注釈を使用します。この注釈の使用の詳細は、oci.oraclecloud.com/security-rule-management-mode注釈を使用したNSGおよびセキュリティ・リストのセキュリティ・ルールの管理を参照してください。
  • "All"または"Frontend"に設定されたservice.beta.kubernetes.io/oci-load-balancer-security-list-management-modeおよびoci-network-load-balancer.oraclecloud.com/security-list-management-mode注釈をそれぞれ使用します。これらの2つの注釈の使用の詳細は、OCI Load Balancerのプロビジョニング時のセキュリティ・リスト管理オプションの指定およびOCI Network Load Balancerのプロビジョニング時のセキュリティ・リスト管理オプションの指定をそれぞれ参照してください。

使用する注釈に関係なく、また、ユーザーまたはoci-cloud-controller-managerがセキュリティ・リストまたはNSGのセキュリティ・ルールを管理しているかどうかに関係なく、oci-cloud-controller-managerがロード・バランサまたはネットワーク・ロード・バランサを追加する1つ以上の追加NSGのOCIDを指定することもできます。この場合、oci.oraclecloud.com/oci-network-security-groupsまたはoci-network-load-balancer.oraclecloud.com/oci-network-security-groups注釈を使用します。oci-cloud-controller-managerは、これらの注釈で指定された追加のNSGのセキュリティ・ルールを管理しないため、セキュリティ・ルールの管理はユーザーの責任です。oci.oraclecloud.com/oci-network-security-groupsまたはoci-network-load-balancer.oraclecloud.com/oci-network-security-groupsアノテーションの使用の詳細は、ネットワーク・セキュリティ・グループの指定(推奨)を参照してください。

Oracle Cloud Infrastructureのロード・バランサとネットワーク・ロード・バランサは、ヘルス・チェック・ポリシーを適用してバックエンド・サーバーを継続的に監視します。ヘルス・チェックは、バックエンド・サーバーの可用性を確認するためのテストで、リクエストまたは接続の試行である場合があります。サーバーがヘルス・チェックに失敗すると、ロード・バランサまたはネットワーク・ロード・バランサは一時的にそのサーバーをローテーションから除外します。その後、サーバーがヘルス・チェックに合格すると、ロード・バランサまたはネットワーク・ロード・バランサはそれをローテーションに戻します。

ヘルス・チェック・ポリシーには多数のパラメータが含まれ、それぞれにデフォルト値があります。Kubernetes EngineがOCIロード・バランサまたはネットワーク・ロード・バランサをLoadBalancerタイプのKubernetesサービスにプロビジョニングする場合、マニフェスト・ファイルのメタデータ・セクションに注釈を含めることで、ヘルス・チェック・パラメータのデフォルト値をオーバーライドできます。これらの注釈は、後で追加、変更および削除できます。ヘルス・チェック・パラメータの値を指定した注釈を削除すると、ロード・バランサまたはネットワーク・ロード・バランサはかわりにパラメータのデフォルト値を使用します。

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-health-check-retries: "5"
    service.beta.kubernetes.io/oci-load-balancer-health-check-interval: "15000"
    service.beta.kubernetes.io/oci-load-balancer-health-check-timeout: "4000"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

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/health-check-retries: "5"
    oci-network-load-balancer.oraclecloud.com/health-check-interval: "15000"
    oci-network-load-balancer.oraclecloud.com/health-check-timeout: "4000"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

マニフェスト・ファイルのメタデータ・セクションに注釈を含めてヘルス・チェック・パラメータ値を明示的に指定しない場合は、次のデフォルトが使用されます:

また、ノードをバックエンドとして使用する場合は、表に示すヘルス・チェックの注釈が適用されます。具体的には、ノードをバックエンドとして使用する場合、oci-load-balancer.oraclecloud.com/health-checkまたはoci-network-load-balancer.oraclecloud.com/health-check注釈を設定しないでください。これらの2つの注釈は、ポッドをバックエンドとして使用する場合にのみ適用されるためです(「バックエンドとしてのポッドの指定」を参照)。

Oracle Cloud Infrastructureロード・バランサおよびネットワーク・ロード・バランサのヘルス・チェック・ポリシーの詳細は、次を参照してください:

• ロード・バランサのヘルス・チェック
• ネットワーク・ロード・バランサのヘルス・チェック・ポリシー

Oracle Cloud Infrastructureロード・バランサまたはネットワーク・ロード・バランサへの受信トラフィックは、バックエンド・セット内のバックエンド・サーバー間で分散されます。デフォルトでは、Kubernetes EngineがOracle Cloud Infrastructureロード・バランサまたはネットワーク・ロード・バランサをタイプLoadBalancerのKubernetesサービスにプロビジョニングすると、クラスタ内のすべてのワーカー・ノードがバックエンド・セットに含まれます。

ただし、特定のロード・バランサまたはネットワーク・ロード・バランサのバックエンド・セットに含めるクラスタ内のワーカー・ノードのサブセットのみを選択するオプションがあります。異なるロード・バランサおよびネットワーク・ロード・バランサのバックエンド・セットにクラスタのワーカー・ノードのサブセットを含めることで、単一のKubernetesクラスタを複数の論理クラスタ(サービス)として表示できます。

oci.oraclecloud.com/node-label-selector: <label>

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    oci.oraclecloud.com/node-label-selector: lbset=set1
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

oci-network-load-balancer.oraclecloud.com/node-label-selector: <label>

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/node-label-selector: lbset=set1
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

標準のKubernetesラベル・セレクタ表記を使用して、マニフェスト・ファイルのメタデータ・セクションの注釈にラベル・キーおよび値を指定します。標準のKubernetesラベル・セレクタ表記の詳細は、Kubernetesドキュメントのラベル・セレクタを参照してください。

この表は、標準のKubernetesラベル・セレクタ表記の例を示しています。

Kubernetes EngineがLoadBalancerタイプのKubernetesサービスのロード・バランサまたはネットワーク・ロード・バランサをプロビジョニングする場合、バックエンド・セットのポリシーを定義して、受信トラフィックをバックエンド・サーバーに分散する方法を指定できます。

詳細は次を参照してください。

• ロード・バランサおよびバックエンド・セット・ポリシーについては、ロード・バランサ・ポリシーを参照してください。
• ネットワーク・ロード・バランサおよびバックエンド・セット・ポリシーについては、ネットワーク・ロード・バランサ・ポリシーを参照してください

oci.oraclecloud.com/loadbalancer-policy: <value>

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    oci.oraclecloud.com/loadbalancer-policy: "LEAST_CONNECTIONS"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

oci-network-load-balancer.oraclecloud.com/backend-policy: <value>

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

KubernetesエンジンがLoadBalancerタイプのKubernetesサービスに対してOracle Cloud Infrastructureロード・バランサまたはネットワーク・ロード・バランサをプロビジョニングする場合、ポッド・レディネス・ゲートを使用して、トラフィックがバックエンド・セットに正常に追加され、トラフィックを受信する準備ができているポッドにのみルーティングされるようにできます。

ポッド準備ゲートは、ポッドがトラフィックを受信する準備ができていることを示す追加の条件です。ポッド・レディネス・ゲートを使用すると、複雑なカスタム・レディネス・チェックを実装でき、ローリング・デプロイメント中にゼロ・ダウンタイムを実現できます。詳細は、Kubernetesドキュメントのポッド・レディネス詳細を参照してください。

ロード・バランサまたはネットワーク・ロード・バランサをプロビジョニングする場合、バックエンド・セットは、Readyという条件を持つデプロイメントのポッド・レプリカのIPアドレスで構成されます。デプロイメントを更新すると(たとえば、新しいイメージを使用するには)、既存のポッド・レプリカが新しいポッド・レプリカに置き換えられます。ただし、次の理由により、すべてのポッド・レプリカを置き換えるには時間がかかり、バックエンドが使用できなくなる可能性があります:

• 既存のポッド・レプリカは、バックエンド・セットが新しいポッド・レプリカのIPアドレスで更新される前に終了する場合があります。
• バックエンド・セットは、新しいポッド・レプリカがトラフィックを受信する準備が整う前に、新しいポッド・レプリカのIPアドレスで更新される場合があります。

ポッド・レディネス・ゲートの使用を指定すると、バックエンドがロード・バランサまたはネットワーク・ロード・バランサで常に使用可能になります。既存のポッドは、新しいポッドがバックエンド・セットに追加され、新しいポッドがトラフィックを受信する準備が整うまで終了しません。

Kubernetesエンジンが、LoadBalancerタイプのサービスのセレクタに一致するラベルを持つ特定のネームスペース内のポッドのポッド仕様にポッド準備ゲートを注入することを指定するには、次のように入力してloadbalancer.oci.oraclecloud.com/pod-readiness-gate-inject=enabledラベルをネームスペースに追加します:

kubectl label ns <namespace> loadbalancer.oci.oraclecloud.com/pod-readiness-gate-inject=enabled

次の例は、ポッド準備ゲートを使用してロード・バランサを作成する方法を示しています。

まず、次のように入力して、pdrネームスペースにラベルを付けて、ネームスペースのポッド準備ゲートを指定します:

kubectl label ns pdr loadbalancer.oci.oraclecloud.com/pod-readiness-gate-inject=enabled

コマンドの出力により、ネームスペースにラベルが付けられていることが確認されます。

namespace/pdr labeled

次に、次のように入力して、Nginxをpdrネームスペースにデプロイします。

kubectl apply -f https://raw.githubusercontent.com/oracle-devrel/oci-oke-virtual-nodes/main/nginx-svc/nginx.yaml -n pdr

次のように入力して、pdrネームスペース内のポッドをリストします:

kubectl get pods -n pdr

これで、Nginxマニフェストのイメージ・バージョンを更新し、既存のポッドが新しいポッドに置き換えられるように、マニフェストを再適用することで、ポッド・レディネス・ゲートの使用をデモンストレーションできます。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25.1
...

次のように入力してマニフェストを再適用してください:

kubectl apply -f ./nginx.yaml -n pdr

次のように入力して、ロールアウトされる新しいポッドを確認します。

kubectl get pods -o wide -n pdr

例:

NAME                     READY   STATUS    RESTARTS   AGE   IP            NODE          NOMINATED NODE   READINESS GATES
nginx-678976847c-8bqs7   1/1     Running   0          44m   10.0.10.153   10.0.10.253   <none>           1/1
nginx-678976847c-ttqms   1/1     Running   0          47m   10.0.10.201   10.0.10.253   <none>           1/1

次のように入力して、新しいポッドのステータスを確認します:

kubectl describe pod <pod-name> -n pdr

例:

kubectl describe pod nginx-678976847c-ttqms  -n pdr

コマンドの出力によって、podreadiness.loadbalancer.oraclecloud.com準備ゲートのステータスが確認されます。例:

...
Readiness Gates:
  Type                                                             Status
  podreadiness.loadbalancer.oraclecloud.com/f913fe603a9be9b5d51f   True 
Conditions:
  Type                                                             Status
  podreadiness.loadbalancer.oraclecloud.com/f913fe603a9be9b5d51f   True 
  PodScheduled                                                     True 
  Initialized                                                      True 
  Ready                                                            True 
  ContainersReady                                                  True 

Kubernetes EngineがLoadBalancerタイプのKubernetesサービス用にOracle Cloud Infrastructureロード・バランサまたはネットワーク・ロード・バランサをプロビジョニングする場合、クラスタ内から発信するトラフィックをロード・バランサまたはネットワーク・ロード・バランサのIPアドレスにルーティングする方法を指定できます。

Kubernetesバージョン1.30以降を実行しているクラスタでは、LoadBalancerIPMode Kubernetes機能ゲートが有効になり、LoadBalancerタイプのサービスのipModeフィールドにはデフォルト値がVIPになります。ipModeの値がVIPの場合、クラスタ内のポッドからLoadBalancerタイプのサービスのIPアドレスに送信されるトラフィックは、LoadBalancerサービスをバイパスしてパフォーマンスを最適化するために、アプリケーション・ポッドに直接ルーティングされます。詳細は、Kubernetesドキュメントのロード・バランサ・ステータスのIPModeの指定を参照してください。

ただし、状況によっては、トラフィックをアプリケーション・ポッドに直接ルーティングすることが適切でない場合があります。たとえば、クラスタ内で発生したトラフィックがアプリケーション・ポッドに直接ルーティングされる場合、ロード・バランサ・レベルでSSL終了を実装することはできません。

クラスタ内からロード・バランサまたはネットワーク・ロード・バランサのIPアドレスに送信されるトラフィックをルーティングする方法を指定するには、マニフェスト・ファイルのメタデータ・セクションに次の注釈を追加します:

oci.oraclecloud.com/ingress-ip-mode: <value>

<value>は次のいずれかです:

• "VIP": クラスタ内から発生し、LoadBalancerタイプのサービスのIPアドレスに送信されるすべてのトラフィックは、LoadBalancerサービスをバイパスしてパフォーマンスを最適化するために、アプリケーション・ポッドに直接ルーティングされます。
• "proxy": クラスタ内から発信され、LoadBalancerタイプのサービスのIPアドレスに送信されるすべてのトラフィックは、LoadBalancerサービス用にプロビジョニングされたOracle Cloud Infrastructureロード・バランサまたはネットワーク・ロード・バランサにルーティングされます。ロード・バランサまたはネットワーク・ロード・バランサは、トラフィックをアプリケーション・ポッドに転送します。

例:

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    oci.oraclecloud.com/ingress-ip-mode: "proxy"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

oci.oraclecloud.com/ingress-ip-mode注釈を指定しない場合、またはその後注釈を削除した場合、LoadBalancer型のサービスのipModeプロパティのデフォルト値は"VIP"になります。

また、oci-network-load-balancer.oraclecloud.com/is-preserve-source注釈をtrueに設定してプライベート・ネットワーク・ロード・バランサを使用する場合、ネットワーク・ロード・バランサには、ソース・ノードと宛先バックエンド・ノードが同じノードであるトラフィックを許可しない既知の制限があります。この制限により、次の条件がすべて満たされている場合に、ネットワーク・ロード・バランサを介して同じノード上のポッド間の通信が防止されます。

• oci.oraclecloud.com/ingress-ip-mode注釈はproxyに設定されています。
• oci-network-load-balancer.oraclecloud.com/is-preserve-source注釈はtrueに設定されています。
• ネットワーク・ロード・バランサはプライベートです。

Kubernetesエンジンが、タイプLoadBalancerのKubernetesサービス用にOracle Cloud Infrastructureロード・バランサまたはネットワーク・ロード・バランサをプロビジョニングすると、ロード・バランサ・サブネットによって、ロード・バランサまたはネットワーク・ロード・バランサがトラフィックを受信するIPアドレスのIPアドレス・ファミリを介した制御が決定されます。

• サブネットがIPv4シングル・スタック・サブネットの場合、サブネットはIPv4アドレス指定のみ用に構成されます。ロード・バランサまたはネットワーク・ロード・バランサには、外部トラフィックを受信するIPv4アドレスのみが割り当てられます。ロード・バランサまたはネットワーク・ロード・バランサが外部トラフィックを受信するIPアドレスのIPアドレス・ファミリは変更できません。
• サブネットがIPv4/IPv6デュアル・スタック・サブネットの場合、サブネットはIPv4とIPv6の両方のアドレス指定用に構成されます。ロード・バランサまたはネットワーク・ロード・バランサには、外部トラフィックを受信するIPv4アドレスとIPv6アドレスのいずれかまたは両方を割り当てることができます。この状況では、サービス・マニフェストのKubernetes spec.ipFamilyPolicyおよびspec.ipFamiliesフィールドを使用して、ロード・バランサまたはネットワーク・ロード・バランサがIPv4アドレスのみで外部トラフィックを受信するか、IPv6アドレスのみで外部トラフィックを受信するか、IPv4アドレスとIPv6アドレスの両方で受信するかを指定できます。

リスナーとバックエンド・セット間のトラフィックに使用されるIPアドレス・ファミリは、ロード・バランサとネットワーク・ロード・バランサで異なる方法で決定されます。

• ロード・バランサ:ロード・バランサ・リスナーとバックエンド・セット間のトラフィックでは、常にIPv4アドレスが使用されます。
• ネットワーク・ロード・バランサ:ネットワーク・ロード・バランサ・リスナーとバックエンド・セット間のトラフィックは、ネットワーク・ロード・バランサ・リスナーが外部トラフィックを受信するIPアドレスと同じIPアドレス・ファミリを使用します。

この表は、ロード・バランサ・サブネットのIPアドレス・ファミリ間の相互作用、spec.ipFamilyPolicyとspec.ipFamiliesの設定、IPアドレスがロード・バランサまたはネットワーク・ロード・バランサに割り当てられるIPアドレス・ファミリ、およびリスナーとバックエンド・セット間のIPプロトコルを示しています。有効な組合せのみが表示されます。

service.beta.kubernetes.io/oci-load-balancer-subnet1注釈を使用して、クラスタの作成時にロード・バランサに指定されたサブネットの代替サブネットを指定する場合は、代替サブネットのアドレス・ファミリがサービス・マニフェストのspec.ipFamilyPolicyおよびspec.ipFamiliesフィールドと互換性があることを確認してください。

KubernetesでのIPv4およびIPv6のサポートの詳細は、KubernetesドキュメントのIPv4/IPv6デュアルスタックを参照してください。

apiVersion: v1
kind: Service
metadata:
  name: nginx-lb
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb" 
spec:
  type: LoadBalancer
  ipFamilyPolicy: RequireDualStack
  ipFamilies:
  - IPv6
  - IPv4
  ports:
  - name: http
    port: 80
    targetPort: 80
  selector:
    app: nginx

apiVersion: v1
kind: Service
metadata:
  name: nginx-lb
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    service.beta.kubernetes.io/oci-load-balancer-subnet1: "ocid1.subnet.oc1..aaaaaa....vdfw"  
spec:
  type: LoadBalancer
  ipFamilyPolicy: PreferDualStack
  ipFamilies:
  - IPv4
  - IPv6
  ports:
  - name: http
    port: 80
    targetPort: 80
  selector:
    app: nginx

KubernetesエンジンがLoadBalancerタイプのKubernetesサービスに対してOracle Cloud Infrastructureネットワーク・ロード・バランサをプロビジョニングすると、ネットワーク・ロード・バランサ・サービスは1つ以上のIPアドレスをネットワーク・ロード・バランサに割り当てます。

ネットワーク・ロード・バランサ・サービスは、プライベートIPv4アドレスを割り当て、外部ネットワーク・ロード・バランサの場合は追加のパブリックIPv4アドレスも割り当てます。ネットワーク・ロード・バランサのサブネットに互換性がある場合は、ネットワーク・ロード・バランサ・サービスでIPv6アドレスを割り当てることもできます(「ロード・バランサおよびネットワーク・ロード・バランサに対するIPアドレス・ファミリの指定」を参照)。

Kubernetesバージョン1.29以降を実行しているクラスタでは、ネットワーク・ロード・バランサ・サービスで割り当てるIPアドレスを選択するのではなく、ネットワーク・ロード・バランサに割り当てるIPアドレスを指定できます。割り当てることができるIPアドレスは、次のように、ネットワーク・ロード・バランサ・サブネットのIPアドレス・ファミリによって異なります:

• IPv4:ネットワーク・ロード・バランサのサブネットがIPv4単一スタック・サブネットまたはIPv4/IPv6デュアル・スタック・サブネットの場合、プライベートIPv4アドレスをネットワーク・ロード・バランサに割り当てることができます。
• IPv4およびIPv6:ネットワーク・ロード・バランサのサブネットがIPv4/IPv6デュアル・スタック・サブネットの場合、プライベートのIPv4アドレスとIPv6アドレスのいずれかまたは両方をネットワーク・ロード・バランサに割り当てることができます。

ネットワーク・ロード・バランサに割り当てるプライベートIPv4アドレスを指定するには、マニフェスト・ファイルのメタデータ・セクションに次の注釈を追加します。

oci-network-load-balancer.oraclecloud.com/assigned-private-ipv4: "<ipv4-address>"

ここで、<ipv4-address>は、ネットワーク・ロード・バランサのサブネットに指定されたIPv4 CIDRブロックからの有効なIPv4アドレスです。例:

oci-network-load-balancer.oraclecloud.com/assigned-private-ipv4: "10.0.0.1"

ネットワーク・ロード・バランサに割り当てるIPv6アドレスを指定するには、マニフェスト・ファイルのメタデータ・セクションに次の注釈を追加します。

oci-network-load-balancer.oraclecloud.com/assigned-ipv6: "<ipv6-address>"

ここで、<ipv6-address>は、ネットワーク・ロード・バランサのサブネットに指定されたIPv6 CIDRブロックからの有効なIPv6 ULAまたはGUAアドレスです。例:

• oci-network-load-balancer.oraclecloud.com/assigned-ipv6: "fd8a:4b3c:7d91:abcd::1"
• oci-network-load-balancer.oraclecloud.com/assigned-ipv6: "2607:9b80:9a0a:9a7e:abcd:ef01:2345:6789"

例:

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/assigned-private-ipv4: "10.0.0.1"
    oci-network-load-balancer.oraclecloud.com/assigned-ipv6: "fd8a:4b3c:7d91:abcd::1"
spec:
  type: LoadBalancer
  ipFamilyPolicy: RequireDualStack
  ipFamilies:
  - IPv6
  - IPv4
  ports:
  - port: 80
  selector:
    app: nginx

有効なIPアドレスを指定する責任があります。IPアドレスを有効にするには、次の条件を満たす必要があります。

• IPアドレスは、使用する注釈の正しい形式(IPv4またはIPv6)である必要があります。
• IPアドレスは、ネットワーク・ロード・バランサのサブネットに指定された適切なCIDRブロックからのものである必要があります。
• IPアドレスは、別のリソースによってまだ使用されていない必要があります。

次の点に注意してください:

• IPアドレスが正しい形式でない場合、または適切なCIDRブロックからでない場合、ネットワーク・ロード・バランサの作成リクエストは受け入れられません。
• IPアドレスが正しい形式であり、適切なCIDRブロックにあるが、IPアドレスが別のリソースによってすでに使用されている場合、ネットワーク・ロード・バランサの作成リクエストが受け入れられます。ただし、関連付けられた作業リクエストは失敗し、コンパートメントには「失敗」状態のネットワーク・ロード・バランサが含まれます。
• IPアドレスが有効な場合、ネットワーク・ロード・バランサは、指定されたIPアドレスが割り当てられて作成されます。

Kubernetesエンジンが、タイプがLoadBalancerのKubernetesサービスに対してパブリックOracle Cloud Infrastructureネットワーク・ロード・バランサをプロビジョニングすると、ネットワーク・ロード・バランサ・サービスは、パブリックIPアドレスとプライベートIPアドレスの両方をネットワーク・ロード・バランサに割り当てます。プライベートIPアドレスは、ヘルス・チェックおよびポート・アドレス変換(PAT)に使用されますが、VCN外部からの外部トラフィック(パブリック・インターネットからのものを含む)を受信することはできません。

ネットワーク・ロード・バランサ・サービスがネットワーク・ロード・バランサに割り当てたパブリックIPアドレスおよびプライベートIPアドレスを表示するには、kubectl get serviceコマンド(または同様)を入力します。例:

kubectl get service my-nginx-svc -o json | jq .status

{
  "loadBalancer": {
    "ingress": [
      {
        "ip": "203.0.113.2"
      },
      {
        "ip": "10.30.3.24"
      }
    ]
  }
}

状況によっては、ネットワーク・ロード・バランサのパブリックIPアドレスのみを公開し、プライベートIPアドレスを非表示にする場合があります。例:

• ExternalDNSアドオンを使用するときに、LoadBalancerタイプのKubernetesサービスのマニフェストにexternal-dns.alpha.kubernetes.io/hostname注釈を含めることで、ネットワーク・ロード・バランサのわかりやすいDNS名を指定できます。ExternalDNSは、クラスタ用に構成した外部DNSプロバイダにネットワーク・ロード・バランサのDNSレコードを作成します。DNSレコードは、DNS名をパブリックIPアドレスとプライベートIPアドレスの両方にマップします。その結果、外部トラフィックがDNS名を使用する場合、プライベートIPアドレスが外部トラフィックを受信できない場合でも、トラフィックがネットワーク・ロード・バランサのプライベートIPアドレスにルーティングされる可能性があります。
• kubectl get serviceコマンド(または類似)を使用してネットワーク・ロード・バランサのIPアドレスを取得する自動化を設定できます。外部トラフィックのルーティングが含まれている場合は、ネットワーク・ロード・バランサのパブリックIPアドレスのみが必要です。ただし、デフォルトでは、kubectl get serviceコマンドはネットワーク・ロード・バランサのパブリックIPアドレスとプライベートIPアドレスの両方を返します。

kubectl get serviceコマンド(または類似コマンド)がネットワーク・ロード・バランサのパブリックIPアドレスのみを返すように指定するには、マニフェスト・ファイルのメタデータ・セクションに次の注釈を追加します:

oci-network-load-balancer.oraclecloud.com/external-ip-only: "true"

"false"は、oci-network-load-balancer.oraclecloud.com/external-ip-only注釈のデフォルト値です。サービス定義にアノテーションを明示的に含めない場合、kubectl get serviceコマンドはネットワーク・ロード・バランサのパブリック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/external-ip-only: "true"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

マニフェストにoci-network-load-balancer.oraclecloud.com/external-ip-only: "true"注釈を含めると、kubectl get serviceコマンド(または類似コマンド)を入力したときに、パブリックIPアドレスのみが返されます。例:

kubectl get service my-nginx-svc -o json | jq .status

{
  "loadBalancer": {
    "ingress": [
      {
        "ip": "203.0.113.2"
      }
    ]
  }
}

Oracle Cloud Infrastructureロード・バランサまたはネットワーク・ロード・バランサのバックエンド・セット内のバックエンド・サーバーのリストから特定のワーカー・ノードを除外できます。詳細は、node.kubernetes.io/exclude-from-external-load-balancersを参照してください。

Kubernetes EngineがLoadBalancerタイプのKubernetesサービスにプロビジョニングするロード・バランサまたはネットワーク・ロード・バランサにタグを追加できます。タグ付けにより、コンパートメント間で異なるリソースをグループ化でき、独自のメタデータを使用してリソースに注釈を付けることもできます。ロード・バランサへのタグの適用を参照してください。

Kubernetes EngineがOracle Cloud Infrastructureロード・バランサまたはネットワーク・ロード・バランサをLoadBalancerタイプのKubernetesサービスにプロビジョニングする場合、TCPベースのリスナーでプロキシ・プロトコル機能を有効にするかどうかを指定できます。プロキシ・プロトコルを有効にすると、クライアントのIPアドレスなどのトランスポート接続情報を複数のプロキシ・レイヤーにわたってバックエンド・サーバーに安全に転送できます。次のプロキシ・プロトコル・バージョンを使用できます。

• バージョン1は、テキストベースのヘッダーを使用してプロキシ間で情報を渡し、小規模の実装に最適です。
• バージョン2。生成および解析の効率を高めるためにテキストベースおよびバイナリ・ヘッダーを使用し、大規模な実装に最適です。

Kubernetes Engineによってプロビジョニングされたロード・バランサは、プロキシ・プロトコル・バージョン1およびバージョン2をサポートします。Kubernetes Engineによってプロビジョニングされるネットワーク・ロード・バランサは、プロキシ・プロトコル・バージョン2をサポートします。

詳細は次を参照してください。

• ロード・バランサおよびプロキシ・プロトコル機能については、ロード・バランサのプロキシ・プロトコルを参照してください。
• ネットワーク・ロード・バランサおよびプロキシ・プロトコル機能については、ネットワーク・ロード・バランサのプロキシ・プロトコルを参照してください。

service.beta.kubernetes.io/oci-load-balancer-connection-proxy-protocol-version: "<value>"

oci-network-load-balancer.oraclecloud.com/is-ppv2-enabled: "<value>"

Oracle Cloud Infrastructureロード・バランサまたはネットワーク・ロード・バランサへの受信トラフィックは、バックエンド・セットのバックエンド間で分散されます。デフォルトでは、KubernetesエンジンがLoadBalancerタイプのKubernetesサービスにOracle Cloud Infrastructureロード・バランサまたはネットワーク・ロード・バランサをプロビジョニングすると、クラスタ内のワーカー・ノードがバックエンド・セットのバックエンドになります。このデフォルト構成では、ロード・バランサまたはネットワーク・ロード・バランサは外部トラフィックをワーカー・ノードにルーティングし、その後、クラスタ内のアプリケーションを実行している適切なポッドにトラフィックを転送します。

ただし、バックエンド・セットのバックエンドとしてポッドを直接使用する代替構成を指定するオプションもあります。この「バックエンドとしてのポッド」構成では、ロード・バランサまたはネットワーク・ロード・バランサは、ノードを完全にバイパスして、トラフィックをポッドIPに直接転送します。Kubernetesエンジンは、構成されたヘルス・チェックのバックエンドとしてポッドIPを使用して、サービス・ポートごとに1つのリスナーとバックエンド・セットのペアを作成します。トラフィックは次のように処理されます。

1. クライアントは、ロード・バランサにリクエストを送信します。
2. ロード・バランサはリクエストとバックエンド・セットを照合し、正常なポッドIPを選択します。
3. リクエストはポッドのIPに直接ルーティングされます。
4. ポッドはリクエストを処理して応答します。
5. レスポンスは、ロード・バランサを介してクライアントに返されます。

バックエンドとして(ノードではなく)ポッドを使用すると、次の利点があります:

• ネットワーク効率の向上:中間ノード・ルーティングを排除することで、ネットワークの輻輳とオーバーヘッドが軽減されます。
• リソース使用率の最適化:正常なポッドのみがバックエンドとして登録され、バックエンド管理が簡素化され、スケーラビリティが改善される可能性があります。
• ヘルス・チェックの簡略化:ロード・バランサは各アプリケーション・ポッドを直接プローブするため、より正確なヘルス監視を実現します。
• ノードへの負荷の低減:ノードからトラフィックをオフロードすると、処理負荷が軽減され、アプリケーション・パフォーマンスがより予測可能になります。

(ノードではなく)ポッドをバックエンドとして使用する場合は、次の点に注意してください:

• OCIロード・バランサとネットワーク・ロード・バランサは、バックエンド・セットごとまたはロード・バランサごとに最大512個のバックエンドをサポートします。LoadBalancerタイプのサービスがこれよりも多くのポッドを選択した場合、最初の512のみがバックエンドとして登録されます。
• ポッドをバックエンドとして使用することは、ポッド・ネットワーキングにOCI VCNネイティブ・ポッド・ネットワーキングCNIプラグインを使用するクラスタでのみサポートされます。
• LoadBalanceタイプのサービスのバックエンドとしてのポッドの使用は、サービスのノード・ポートが無効になっている場合にのみサポートされます。
• 現在バックエンドとしてノードを使用しているLoadBalancerタイプの既存のサービスを移行して、かわりにポッドをバックエンドとして使用できます(LoadBalancerタイプのサービスのバックエンドとしてのノードの使用からバックエンドとしてのポッドの使用およびVice Versaを参照)。

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx 
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    oci-load-balancer.oraclecloud.com/health-check: '{"protocol": "HTTP", "port": 8080, "urlPath": "/healthz", "returnCode": 200, "retries": 2, "timeoutInMillis": 5000}'
    oci.oraclecloud.com/security-rule-management-mode: "NSG"
    oci.oraclecloud.com/oci-backend-network-security-group: "<nsg-ocid>"
spec:
  type: LoadBalancer
  selector:
    app: nginx
  ports:
    - name: http
      port: 80
      targetPort: 8080
  allocateLoadBalancerNodePorts: false

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/health-check: '{"protocol": "TCP", "port": 8081, "retries": 3, "timeoutInMillis": 4000}'
    oci.oraclecloud.com/security-rule-management-mode: "NSG"
    oci.oraclecloud.com/oci-backend-network-security-group: "<nsg-ocid>"
spec:
  type: LoadBalancer
  selector:
    app: nginx
  ports:
    - name: tcp
      port: 81
      targetPort: 8081
  allocateLoadBalancerNodePorts: false

oci-load-balancer.oraclecloud.com/health-check: '{"protocol": "HTTP", "port": 8080, "urlPath": "/", "returnCode": 200, "retries": 2, "timeoutInMillis": 5000}'

oci-network-load-balancer.oraclecloud.com/health-check: '{"protocol": "HTTP", "port": 8080, "urlPath": "/", "returnCode": 200, "retries": 2, "timeoutInMillis": 5000}'

oci-load-balancer.oraclecloud.com/health-checkアノテーションまたはoci-network-load-balancer.oraclecloud.com/health-checkアノテーションを使用して定義したヘルス・チェック構成は、ポッドをバックエンドとして使用する場合にのみ適用されます。oci-load-balancer.oraclecloud.com/health-checkおよびoci-network-load-balancer.oraclecloud.com/health-check注釈は、ノードをバックエンドとして使用する場合に適用される注釈を置き換えます。具体的には、ポッドをバックエンドとして使用する場合、次の注釈は有効になりません。

• ロード・バランサの場合、ポッドをバックエンドとして使用する場合、次の注釈は有効になりません。

  • service.beta.kubernetes.io/oci-load-balancer-health-check-retries
  • service.beta.kubernetes.io/oci-load-balancer-health-check-timeout
  • service.beta.kubernetes.io/oci-load-balancer-health-check-interval

• ネットワーク・ロード・バランサの場合、ポッドをバックエンドとして使用する場合、次の注釈は有効にならないようにします。

  • oci-network-load-balancer.oraclecloud.com/health-check-retries
  • oci-network-load-balancer.oraclecloud.com/health-check-timeout
  • oci-network-load-balancer.oraclecloud.com/health-check-interval

すでに説明したように、これらの注釈は、ポッドをバックエンドとして使用する場合には有効になりませんが、oci-load-balancer.oraclecloud.com/health-checkまたはoci-network-load-balancer.oraclecloud.com/health-check注釈および関連するJSONオブジェクトを使用して、対応するヘルス・チェック構成設定の値を指定できます。

kubectl label ns <namespace> loadbalancer.oci.oraclecloud.com/pod-readiness-gate-inject=enabled

Kubernetes EngineがタイプLoadBalancerのKubernetesサービスに対してOracle Cloud Infrastructureロード・バランサまたはネットワーク・ロード・バランサをプロビジョニングする場合、ロード・バランサまたはネットワーク・ロード・バランサが作成されるコンパートメントを指定できます。デフォルトでは、Kubernetes Engineは、クラスタと同じコンパートメントにロード・バランサまたはネットワーク・ロード・バランサを作成します。

ロード・バランサまたはネットワーク・ロード・バランサを作成する代替コンパートメントを指定するには、マニフェスト・ファイルのメタデータ・セクションに次の注釈を追加します:

oci.oraclecloud.com/compartment-id: <compartment-ocid>

<compartment-ocid>は、ロード・バランサまたはネットワーク・ロード・バランサを作成するコンパートメント のOCIDです。

たとえば、ロード・バランサを作成する代替コンパートメントを指定するには:

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    oci.oraclecloud.com/compartment-id: ocid1.compartment.oc1..aaaaaaaay______t6q
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: nginx

このマニフェストでは、OCID ocid1.compartment.oc1..aaaaaaaay______t6qを使用してロード・バランサをコンパートメントに作成することを指定します。

Kubernetes Engineは、作成後のコンパートメント間でのロード・バランサまたはネットワーク・ロード・バランサの移動をサポートしていないことに注意してください。次の推奨事項を検討してください:

• ベスト・プラクティスとして、LoadBalancerタイプのサービスをデプロイする前に、コンパートメント割当てを慎重に計画することをお薦めします。
• Kubernetes Engineによって作成されたロード・バランサまたはネットワーク・ロード・バランサが現在存在するコンパートメントを変更する場合は、LoadBalancerタイプのサービスを削除することをお薦めします。次に、サービス・マニフェストのoci.oraclecloud.com/compartment-idアノテーションを更新して必要なコンパートメントを指定してから、サービスを再デプロイできます。
• ロード・バランサ・サービスおよびネットワーク・ロード・バランサ・サービスでは可能ですが、Kubernetes Engineが作成したロード・バランサまたはネットワーク・ロード・バランサをコンパートメント間で移動しないことを強くお薦めします。ロード・バランサまたはネットワーク・ロード・バランサをコンパートメント間で移動すると、元のコンパートメントに「孤立」ロード・バランサまたはネットワーク・ロード・バランサが作成される可能性があります。孤立したロード・バランサまたはネットワーク・ロード・バランサは、Kubernetes Engineによって管理されず、ライフサイクルおよびガバナンスの問題を引き起こす可能性があります。

Allow any-user to manage load-balancers in compartment <compartment-ocid> where all { request.principal.type = 'cluster' }
Allow any-user to manage network-load-balancers in compartment <compartment-ocid> where all { request.principal.type = 'cluster' }

Kubernetes EngineがLoadBalancerタイプのKubernetesサービスに対してOCIロード・バランサをプロビジョニングする場合、セッション永続性(「スティッキー・セッション」)を構成して、同じクライアントからのリクエストが一貫して同じバックエンド・サーバーにルーティングされるようにできます。

セッション永続性は、バックエンド・サーバーでクライアント状態を維持するアプリケーションで役立ちます。

OCIロード・バランサは、次の2種類のCookieベースのセッション永続性をサポートします。

• アプリケーションCookieの永続性: バックエンド・アプリケーションがCookieを設定および管理します。
• ロード・バランサCookieの永続性: ロード・バランサはCookieを設定および管理します。

Cookieベースのセッション永続性のOCIロード・バランサ・サポートの詳細は、ロード・バランサ・セッション永続性を参照してください。

セッション永続性を構成するには、サービス・マニフェストのメタデータ・セクションに2つの永続性注釈の1つを追加します。

次の点に注意してください:

• セッション永続性は、ロード・バランサ(oci.oraclecloud.com/load-balancer-type: "lb")でサポートされています。
• セッション永続性は、ネットワーク・ロード・バランサ(oci.oraclecloud.com/load-balancer-type: "nlb")ではサポートされていません。ネットワーク・ロード・バランサにセッション永続性注釈が指定されている場合、その注釈は無視されます。
• 2つの永続性注釈は相互に排他的です。両方を指定した場合、サービスの調整は失敗します。
• 永続性アノテーションが指定されていない場合、セッション永続性は無効になります。

oci-load-balancer.oraclecloud.com/session-persistence-config: "<json>"

apiVersion: v1
kind: Service
metadata:
  name: my-app-svc
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    oci-load-balancer.oraclecloud.com/session-persistence-config:
      {
        "cookieName": "APPSESS",
        "disableFallback": true
      }
spec:
  type: LoadBalancer
  selector:
    app: my-app
  ports:
    - name: http
      port: 80
      targetPort: 8080

oci-load-balancer.oraclecloud.com/lb-cookie-session-persistence-config: "<json>"

apiVersion: v1
kind: Service
metadata:
  name: my-app-svc
  annotations:
    oci.oraclecloud.com/load-balancer-type: "lb"
    oci-load-balancer.oraclecloud.com/lb-cookie-session-persistence-config:
      {
        "cookieName": "X-Oracle-OCI-Route",
        "disableFallback": true,
        "domain": "example.com",
        "path": "/",
        "maxAgeInSeconds": 120,
        "isSecure": true,
        "isHttpOnly": true
      }
spec:
  type: LoadBalancer
  selector:
    app: my-app
  ports:
    - name: http
      port: 80
      targetPort: 8080