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

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

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

Container Engine for 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プロパティを設定した場合、Container Engine for Kubernetesが作成するOracle Cloud Infrastructureパブリック・ロード・バランサまたはネットワーク・ロード・バランサのIPアドレスを後で直接変更することはできません。IPアドレスを変更する場合は、LoadBalancerサービスを削除し、マニフェスト・ファイルで別の予約済パブリックIPアドレスを指定して、LoadBalancerサービスを再度デプロイします。
• LoadBalancerサービスのloadBalancerIPプロパティを設定しない場合、Container Engine for 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を使用して、Container Engine for 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 (クラスタ・コントロール・プレーン上で実行)が、セキュリティ・ルールの一部またはすべてを管理することを指定することもできます。Container Engine for Kubernetesでは、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ロード・バランサおよびネットワーク・ロード・バランサは、ヘルス・チェック・ポリシーを適用してバックエンド・サーバーを継続的に監視します。ヘルス・チェックは、バックエンド・サーバーの可用性を確認するためのテストで、リクエストまたは接続の試行である場合があります。サーバーがヘルス・チェックに失敗すると、ロード・バランサまたはネットワーク・ロード・バランサは一時的にそのサーバーをローテーションから除外します。その後、サーバーがヘルス・チェックに合格すると、ロード・バランサまたはネットワーク・ロード・バランサはそれをローテーションに戻します。

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

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

ただし、特定のロード・バランサまたはネットワーク・ロード・バランサのバックエンド・セットに含めるクラスタ内のワーカー・ノードのサブセットのみを選択するオプションがあります。異なるロード・バランサおよびネットワーク・ロード・バランサのバックエンド・セットにクラスタのワーカー・ノードのサブセットを含めることで、単一の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ラベル・セレクタ表記の例を示しています。

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

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

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

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

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

Container Engine for 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 

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

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