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

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エンジンが作成するOracle Cloud Infrastructureパブリック・ロード・バランサまたはネットワーク・ロード・バランサに同じパブリックIPアドレス・デプロイメントを含める場合は、予約済パブリックIPアドレスのプールから予約済パブリックIPアドレスを割り当てることができます。予約済パブリックIPアドレスの作成および表示の詳細は、パブリックIPアドレスに関する項を参照してください。

Kubernetesエンジンが作成するOracle Cloud Infrastructureパブリック・ロード・バランサまたはネットワーク・ロード・バランサに予約済パブリックIPアドレスを割り当てるには、LoadBalancerタイプのサービスを定義するマニフェスト・ファイルのspecセクションにLoadBalancerIPプロパティを追加し、予約済パブリックIPアドレスを指定します。

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

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

• LoadBalancerサービスのloadBalancerIPプロパティを設定した場合、Kubernetesエンジンが作成するOracle Cloud Infrastructureパブリック・ロード・バランサまたはネットワーク・ロード・バランサのIPアドレスを後で直接変更することはできません。IPアドレスを変更する場合は、LoadBalancerサービスを削除し、マニフェスト・ファイルで別の予約済パブリックIPアドレスを指定して、LoadBalancerサービスを再度デプロイします。
• LoadBalancerサービスのloadBalancerIPプロパティを設定しない場合、Kubernetesエンジンによって作成されるOracle Cloud Infrastructureパブリック・ロード・バランサまたはネットワーク・ロード・バランサのIPアドレスを、一時的IPアドレスから予約済パブリックIPアドレスに後で直接切り替えることはできません。一時的なIPアドレスを予約済パブリックIPアドレスに切り替える場合は、LoadBalancerタイプのサービスを削除し、loadBalancerIPプロパティをマニフェスト・ファイルの予約済パブリックIPアドレスに設定して、LoadBalancerタイプのサービスを再度デプロイします。
• LoadBalancerタイプのサービスを削除し、他の用途のために予約済パブリックIPアドレスを解放できます(たとえば、LoadBalancerタイプの別のサービスに割り当てることができます)。
• 同じIPアドレスが別のリソース(コンピュート・インスタンスやLoadBalancerタイプの別のサービスなど)にすでに割り当てられている場合、LoadBalancerタイプのサービスの予約済パブリックIPアドレスは指定できません。
• 内部ロード・バランサ・サービスのマニフェスト・ファイル(つまり、service.beta.kubernetes.io/oci-load-balancer-internal: "true"またはoci-network-load-balancer.oraclecloud.com/internal: "true"注釈を含むマニフェスト・ファイル)にloadBalancerIPプロパティを追加することはできません。

• デフォルトでは、マニフェスト・ファイル内でタイプLoadBalancerのサービスのloadBalancerIPプロパティとして指定した予約済パブリックIPアドレスは、クラスタと同じコンパートメントのリソースであることが想定されます。別のコンパートメントに予約済パブリックIPアドレスを指定する場合:

  • パブリック・ロード・バランサの場合、テナンシに次のポリシーを追加します:

    ALLOW any-user to read public-ips in tenancy where request.principal.type = 'cluster'
    ALLOW any-user to manage floating-ips in tenancy where request.principal.type = 'cluster'

  • ネットワーク・ロード・バランサの場合、テナンシに次のポリシーを追加します:

    ALLOW any-user to use private-ips in TENANCY where ALL {request.principal.type = 'cluster', request.principal.compartment.id = 'target.compartment.id'}
    ALLOW any-user to manage public-ips in TENANCY where ALL {request.principal.type = 'cluster', request.principal.compartment.id = 'target.compartment.id'}

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

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

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 Engineが、タイプLoadBalancerのKubernetesサービス用にOracle Cloud Infrastructureロード・バランサまたはネットワーク・ロード・バランサをプロビジョニングする場合、ポッド・レディネス・ゲートを使用して、トラフィックがバックエンド・セットに正常に追加され、トラフィックの受信準備が整ったポッドにのみルーティングされるようにできます。仮想ノードで実行されているポッドにはポッド準備ゲートを指定できますが、管理対象ノードで実行されているポッドには指定できません。管理対象ノードで実行されているポッドのポッド準備ゲートを定義しないでください。

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

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

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

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

Kubernetesエンジンが、特定のネームスペースで作成されたすべてのポッドのポッド仕様にポッド準備ゲートを注入することを指定するには、次のように入力して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に設定されています。
• ネットワーク・ロード・バランサはプライベートです。

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

Kubernetesエンジンがプロビジョニングするロード・バランサまたはネットワーク・ロード・バランサに、タイプが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>"