外部ロードバランサを構成する

外部ロードバランサ（ELB）は、より大きなインスタンス外部 IP プールから組織に割り当てられたプールの IP アドレスから、組織外からアクセスするサービスを公開します。

ELB 仮想 IP（VIP）アドレスは組織間で競合せず、すべての組織で一意です。このため、ELB サービスは、組織外のクライアントがアクセスする必要があるサービスにのみ使用する必要があります。

組織内で実行されているワークロードは、ワークロードが組織外にアクセスできるように設定されている限り、ELB サービスにアクセスできます。このトラフィック パターンでは、内部サービスに戻る前に、組織からのアウトバウンド トラフィックが必要になります。

共有クラスタと標準クラスタの ELB を設定する手順は異なります。

共有クラスタの外部ロードバランサを作成する

グローバル ELB またはゾーン ELB を作成できます。グローバル ELB のスコープは GDC ユニバース全体に及びます。ゾーン ELB のスコープは、作成時に指定したゾーンに限定されます。詳細については、グローバル ロードバランサとゾーン ロードバランサをご覧ください。

始める前に

ELB サービスを構成するには、次の操作を行う必要があります。

  • ロードバランサを構成するプロジェクトを所有している。詳細については、プロジェクトを作成するをご覧ください。
  • この ELB サービスへのトラフィックを許可するようにカスタマイズされた ProjectNetworkPolicy（PNP）上り（内向き）ポリシーがある。詳細については、ELB へのトラフィックを許可するように PNP を構成するをご覧ください。

  • 必要な Identity and Access のロールを付与されている。

    • プロジェクト NetworkPolicy 管理者: プロジェクトの名前空間でプロジェクト ネットワーク ポリシーを管理するためのアクセス権があります。IAM 組織管理者に、プロジェクト NetworkPolicy 管理者（project-networkpolicy-admin）ロールを付与するよう依頼します。
    • ロードバランサ管理者: IAM 組織管理者に、ロードバランサ管理者（load-balancer-admin）ロールを付与するよう依頼します。
    • グローバル ロードバランサ管理者: グローバル ELB の場合は、IAM 組織管理者にグローバル ロードバランサ管理者（global-load-balancer-admin）ロールを付与するよう依頼します。詳細については、事前定義ロールの説明をご覧ください。

ELB へのトラフィックを許可するように PNP を構成する

ELB サービスが機能するには、独自のカスタマイズされた ProjectNetworkPolicy 上り（内向き）ポリシーを構成して適用し、この ELB サービスのワークロードへのトラフィックを許可する必要があります。ネットワーク ポリシーは、ロードバランサ自体ではなく、ワークロードへのアクセスを制御します。ELB はワークロードを顧客ネットワークに公開するため、ワークロード ポート（8080 など）への外部トラフィックを許可する明示的なネットワーク ポリシーが必要です。

この ELB のワークロードへのトラフィックを許可する外部 CIDR アドレスを指定します。

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: allow-inbound-traffic-from-external
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - ipBlock:
        cidr: CIDR
    ports:
    - protocol: TCP
      port: PORT
EOF

次のように置き換えます。

  • MANAGEMENT_API_SERVER: Management API サーバーの kubeconfig パス。対象ゾーンの API サーバーの kubeconfig ファイルをまだ生成していない場合は、ログインで詳細をご覧ください。
  • PROJECT: GDC プロジェクトの名前。
  • CIDR: ELB がアクセスする必要がある外部 CIDR。このポリシーは、外部ロードバランサが Direct Server Return（DSR）を使用するために必要です。DSR は、送信元外部 IP アドレスを保持し、逆方向パスでロードバランサをバイパスします。詳細については、組織外のトラフィック用のグローバル上り（内向き）ファイアウォール ルールを作成するをご覧ください。
  • PORT: ロードバランサの背後にある Pod のバックエンド ポート。この値は、Service リソースのマニフェストの .spec.ports[].targetPort フィールドにあります。このフィールドは省略可能です。

GDC で 3 つの異なる方法を使用して ELB を作成します。

  • gdcloud CLI を使用して、グローバル ELB またはゾーン ELB を作成します。
  • Networking Kubernetes Resource Model（KRM）API を使用して、グローバル ELB またはゾーン ELB を作成します。
  • Kubernetes クラスタで Kubernetes Service を直接使用する。この方法は、ゾーン ELB でのみ使用できます。

KRM API と gdcloud CLI を使用して、Pod または VM ワークロードをターゲットに設定できます。Kubernetes クラスタで Kubernetes Service を直接使用する場合、Service オブジェクトが作成されたクラスタ内のワークロードのみをターゲットにできます。

ゾーン ELB を作成する

gdcloud CLI、KRM API、または Kubernetes クラスタの Kubernetes Service を使用して、ゾーン ELB を作成します。

gdcloud

gdcloud CLI を使用して、Pod または VM ワークロードをターゲットとする ELB を作成します。

この ELB は、Backend オブジェクトで定義されたラベルに一致するプロジェクト内のすべてのワークロードをターゲットにします。

gdcloud CLI を使用して ELB を作成する手順は次のとおりです。

  1. Backend リソースを作成して、ELB のエンドポイントを定義します。

    gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT_NAME \
  --zone=ZONE \
  --cluster-name=CLUSTER_NAME

    次のように置き換えます。

    • BACKEND_NAME: バックエンド リソースに選択した名前（my-backend など）。
    • LABELS: このバックエンド リソースに使用する Pod と VM 間のエンドポイントを定義するセレクタ。例: app=web
    • PROJECT_NAME: プロジェクトの名前。
    • ZONE: この呼び出しに使用するゾーン。ゾーンフラグを必要とするすべてのコマンドにゾーンフラグを事前に設定するには、gdcloud config set core/zone ZONE を実行します。zone フラグは、マルチゾーン環境でのみ使用できます。このフィールドは省略可能です。
    • CLUSTER_NAME: 定義されたセレクタのスコープが制限されるクラスタ。このフィールドが指定されていない場合、指定されたラベルを持つすべてのエンドポイントが選択されます。このフィールドは省略可能です。

  2. この ELB が Pod ワークロード用である場合は、この手順をスキップします。VM ワークロード用に ELB を構成する場合は、ELB のヘルスチェックのタイプを定義します。たとえば、TCP ヘルスチェックを作成するには、次のように定義します。

    gdcloud compute health-checks create tcp HEALTH_CHECK_NAME \
  --check-interval=CHECK_INTERVAL \
  --healthy-threshold=HEALTHY_THRESHOLD \
  --timeout=TIMEOUT \
  --unhealthy-threshold=UNHEALTHY_THRESHOLD \
  --port=PORT \
  --zone=ZONE

    次のように置き換えます。

    • HEALTH_CHECK_NAME: ヘルスチェック リソースに選択した名前（my-health-check など）。
    • CHECK_INTERVAL: 1 つのプローブの開始から次のプローブの開始までの時間（秒単位）。省略するか 0 に設定した場合のデフォルトは 5 です。timeout を checkInterval より長く設定することはおすすめしません。
    • HEALTHY_THRESHOLD: エンドポイントが正常と見なされるために、連続して成功する必要があるプローブの数。省略するか 0 に設定した場合のデフォルトは 5 です。
    • TIMEOUT: 失敗を宣言するまでの待機時間（秒単位）。省略するか 0 に設定した場合のデフォルトは 5 です。timeout を checkInterval より長く設定することはおすすめしません。
    • UNHEALTHY_THRESHOLD: エンドポイントが異常とみなされるために連続して失敗する必要があるプローブの数。省略するか 0 に設定した場合のデフォルトは 2 です。
    • PORT: ヘルスチェックが実行されるポート。デフォルト値は 80 です。このフィールドは省略可能です。
    • ZONE: この ELB を作成するゾーン。

  3. BackendService リソースを作成し、以前に作成した Backend リソースを追加します。

    gdcloud compute backend-services create BACKEND_SERVICE_NAME \
  --project=PROJECT_NAME \
  --target-ports=TARGET_PORTS \
  --zone=ZONE \
  --health-check=HEALTH_CHECK_NAME

    次のように置き換えます。

    • BACKEND_SERVICE_NAME: このバックエンド サービスに選択した名前。
    • TARGET_PORT: このバックエンド サービスが変換するターゲット ポートのカンマ区切りのリスト。各ターゲット ポートは、プロトコル、転送ルールのポート、バックエンド インスタンスのポートを指定します。複数のターゲット ポートを指定できます。このフィールドは、protocol:port:targetport の形式（TCP:80:8080 など）にする必要があります。このフィールドは省略可能です。
    • HEALTH_CHECK_NAME: ヘルスチェック リソースの名前。このフィールドは省略可能です。このフィールドは、VM ワークロード用に ELB を構成する場合にのみ指定します。

  4. 以前に作成した Backend リソースに BackendService リソースを追加します。

    gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --backend=BACKEND_NAME \
  --project=PROJECT_NAME \
  --zone=ZONE

  5. 省略可: ELB にセッション アフィニティを使用して、同じクライアントからのリクエストが常に同じバックエンドにルーティングされるようにします。ロードバランサのセッション アフィニティを有効にするには、gdcloud compute load-balancer-policy create コマンドを使用してバックエンド サービス ポリシーを作成します。

     gdcloud compute load-balancer-policy create POLICY_NAME
 --session-affinity=MODE
 --selectors=RESOURCE_LABEL

    次のように置き換えます。

    • POLICY_NAME: バックエンド サービス ポリシーに選択した名前。

    • MODE: セッション アフィニティ モード。次の 2 つのモードがサポートされています。

      • NONE: セッション アフィニティは無効になっています。リクエストは、使用可能なバックエンドにルーティングされます。これがデフォルトのモードです。
      • CLIENT_IP_DST_PORT_PROTO: 同じ 4 タプル（送信元 IP アドレス、宛先 IP アドレス、宛先ポート、プロトコル）からのリクエストは、同じバックエンドにルーティングされます。

    • RESOURCE_LABEL: プロジェクトの名前空間で BackendServicePolicy リソースを適用するバックエンド サービスを選択するラベルセレクタ。複数の BackendServicePolicy リソースが同じバックエンド サービスに一致し、これらのポリシーの少なくとも 1 つでセッション アフィニティが有効になっている場合、この BackendService リソースのセッション アフィニティが有効になります。

  6. サービスが利用可能な VIP を定義する外部 ForwardingRule リソースを作成します。

    gdcloud compute forwarding-rules create FORWARDING_RULE_EXTERNAL_NAME \
  --backend-service=BACKEND_SERVICE_NAME \
  --cidr=CIDR \
  --ip-protocol-port=PROTOCOL_PORT \
  --load-balancing-scheme=EXTERNAL \
  --zone=ZONE \
  --project=PROJECT_NAME

    次のように置き換えます。

    • BACKEND_SERVICE_NAME: バックエンド サービスの名前。
    • FORWARDING_RULE_EXTERNAL_NAME: 転送ルールに選択した名前。
    • CIDR: このフィールドは省略可能です。指定しない場合、IPv4/32 CIDR はゾーン IP プールから自動的に予約されます。この転送ルールと同じ Namespace にある Subnet リソースの名前を指定します。Subnet リソースは、ゾーン サブネットのリクエスト情報と割り当て情報を表します。Subnet リソースの詳細については、カスタム リソースの例をご覧ください。
    • PROTOCOL_PORT: 転送ルールで公開するプロトコルとポート。このフィールドは ip-protocol=TCP:80 の形式にする必要があります。公開ポートは、実際のアプリケーションがコンテナ内で公開しているポートと同じである必要があります。

  7. 構成された ELB を確認するには、作成された各オブジェクトの Ready 条件を確認します。ロードバランサに割り当てられた IP アドレスを取得するには、転送ルールを記述します。

    gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME

  8. 構成された ELB を検証するには、作成された各オブジェクトの Ready 条件を確認します。VIP への curl リクエストでトラフィックを確認します。

    1. 割り当てられた VIP を取得するには、転送ルールの説明を取得します。

      gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME

    2. 転送ルールの PROTOCOL_PORT フィールドで指定されたポートの VIP に curl リクエストを送信して、トラフィックを確認します。

      curl http://FORWARDING_RULE_VIP:PORT

      次のように置き換えます。

      • FORWARDING_RULE_VIP: 転送ルールの VIP。
      • PORT: 転送ルールの PROTOCOL_PORT フィールドのポート番号。

API

KRM API を使用して、Pod または VM ワークロードをターゲットとする ELB を作成します。この ELB は、Backend オブジェクトで定義されたラベルに一致するプロジェクト内のすべてのワークロードをターゲットにします。

KRM API を使用してゾーン ELB を作成する手順は次のとおりです。

  1. Backend リソースを作成して、ELB のエンドポイントを定義します。ワークロードが配置されているゾーンごとに Backend リソースを作成します。

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: Backend
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_NAME
spec:
  clusterName: CLUSTER_NAME
  endpointsLabels:
    matchLabels:
      app: server
EOF

    次のように置き換えます。

    • MANAGEMENT_API_SERVER: ゾーン Management API サーバーの kubeconfig パス。詳細については、ゾーン コンテキストに切り替えるをご覧ください。
    • PROJECT_NAME: プロジェクトの名前。
    • BACKEND_NAME: Backend リソースの名前。
    • CLUSTER_NAME: これは省略可能なフィールドです。このフィールドでは、定義されたセレクタのスコープを制限するクラスタを指定します。このフィールドは VM ワークロードには適用されません。Backend リソースに clusterName フィールドが含まれていない場合、指定されたラベルはプロジェクト内のすべてのワークロードに適用されます。

  2. この ELB が Pod ワークロード用である場合は、この手順をスキップします。VM ワークロードに ELB を構成する場合は、ELB のヘルスチェックを定義します。

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: HealthCheck
metadata:
  namespace: PROJECT_NAME
  name: HEALTH_CHECK_NAME
spec:
  tcpHealthCheck:
    port: PORT
  timeoutSec: TIMEOUT
  checkIntervalSec: CHECK_INTERVAL
  healthyThreshold: HEALTHY_THRESHOLD
  unhealthyThreshold: UNHEALTHY_THRESHOLD
EOF

    次のように置き換えます。

    • HEALTH_CHECK_NAME: ヘルスチェック リソースに選択した名前（my-health-check など）。
    • PORT: ヘルスチェックが実行されるポート。デフォルト値は 80 です。
    • TIMEOUT: 失敗を宣言するまでの待機時間（秒単位）。省略するか 0 に設定した場合のデフォルトは 5 です。timeout を checkInterval より長く設定することはおすすめしません。
    • CHECK_INTERVAL: 1 つのプローブの開始から次のプローブの開始までの時間（秒単位）。省略するか 0 に設定した場合のデフォルトは 5 です。timeout を checkInterval より長く設定することはおすすめしません。
    • HEALTHY_THRESHOLD: エンドポイントが正常と見なされるために合格する必要がある連続プローブの数。省略するか 0 に設定した場合のデフォルトは 2 です。
    • UNHEALTHY_THRESHOLD: エンドポイントが異常とみなされるために連続して失敗する必要があるプローブの数。省略するか 0 に設定した場合のデフォルトは 2 です。

  3. 以前に作成した Backend リソースを使用して BackendService オブジェクトを作成します。VM ワークロード用に ELB を構成する場合は、HealthCheck リソースを含めます。

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: BackendService
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_SERVICE_NAME
spec:
  backendRefs:
  - name: BACKEND_NAME
  healthCheckName: HEALTH_CHECK_NAME
EOF

    次のように置き換えます。

    • BACKEND_SERVICE_NAME: BackendService リソースに選択した名前。
    • HEALTH_CHECK_NAME: 以前に作成した HealthCheck リソースの名前。Pod ワークロードに ELB を構成する場合は、このフィールドを含めないでください。

  4. 省略可: ELB にセッション アフィニティを使用して、同じクライアントからのリクエストが常に同じバックエンドにルーティングされるようにします。ロードバランサのセッション アフィニティを有効にするには、BackendServicePolicy リソースを作成します。このリソースは、セッション アフィニティの設定を定義し、BackendServicePolicy リソースを BackendService リソースに適用します。BackendServicePolicy リソースを作成して適用します。

     kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
 apiVersion: networking.global.gdc.goog/v1
 kind: BackendServicePolicy
 metadata:
     namespace: PROJECT_NAME
     name: POLICY_NAME
 spec:
     sessionAffinity: MODE
     selector:
         matchLabels:
           RESOURCE_LABEL

    次のように置き換えます。

    • POLICY_NAME: バックエンド サービス ポリシーに選択した名前。

    • MODE: セッション アフィニティ モード。次の 2 つのモードがサポートされています。

      • NONE: セッション アフィニティは無効になっています。リクエストは、使用可能なバックエンドにルーティングされます。これがデフォルトのモードです。
      • CLIENT_IP_DST_PORT_PROTO: 同じ 4 タプル（送信元 IP アドレス、宛先 IP アドレス、宛先ポート、プロトコル）からのリクエストは、同じバックエンドにルーティングされます。

    • RESOURCE_LABEL: プロジェクトの名前空間で BackendServicePolicy リソースを適用するバックエンド サービスを選択するラベルセレクタ。複数の BackendServicePolicy リソースが同じバックエンド サービスに一致し、これらのポリシーの少なくとも 1 つでセッション アフィニティが有効になっている場合、この BackendService リソースのセッション アフィニティが有効になります。

  5. サービスが利用可能な VIP を定義する外部 ForwardingRule リソースを作成します。

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ForwardingRuleExternal
metadata:
  namespace: PROJECT_NAME
  name: FORWARDING_RULE_EXTERNAL_NAME
spec:
  cidrRef:
    name: CIDR_NAME
  ports:
  - port: PORT
    protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF

    次のように置き換えます。

    • BACKEND_SERVICE_NAME: BackendService リソースの名前。
    • FORWARDING_RULE_EXTERNAL_NAME: ForwardingRuleExternal リソースに選択した名前。
    • CIDR_NAME: cidrRef フィールドは省略可能です。指定しない場合、IPv4/32 CIDR はゾーン IP プールから自動的に予約されます。この転送ルールと同じ Namespace にある Subnet リソースの名前を指定します。Subnet リソースは、ゾーン サブネットのリクエスト情報と割り当て情報を表します。Subnet リソースの詳細については、カスタム リソースの例をご覧ください。
    • PORT: ports フィールドを使用して、この転送ルールで構成されたバックエンドにパケットが転送される L4 ポートの配列を指定します。少なくとも 1 つのポートを指定する必要があります。port フィールドを使用してポート番号を指定します。公開ポートは、実際のアプリケーションがコンテナ内で公開しているポートと同じである必要があります。

    • PROTOCOL: 転送ルールに使用するプロトコル（TCP など）。ports 配列のエントリは次のようになります。

      ports:
- port: 80
  protocol: TCP

  6. 構成された ELB を検証するには、作成された各オブジェクトの Ready 条件を確認します。VIP への curl リクエストでトラフィックを確認します。

    1. VIP を取得するには、kubectl get を使用します。

      kubectl get forwardingruleexternal -n PROJECT_NAME

      出力は次のようになります。

      NAME           BACKENDSERVICE                               CIDR              READY
elb-name       BACKEND_SERVICE_NAME        10.200.32.59/32   True

    2. 転送ルールの PORT フィールドで指定されたポートの VIP に curl リクエストを送信して、トラフィックを確認します。

      curl http://FORWARDING_RULE_VIP:PORT

      FORWARDING_RULE_VIP は、転送ルールの VIP に置き換えます。

Kubernetes Service

GDC で ELB を作成するには、Kubernetes クラスタに LoadBalancer タイプの Kubernetes Service を作成します。

ELB サービスを作成するには、次の操作を行います。

  1. タイプ LoadBalancer の Service 定義の YAML ファイルを作成します。

    次の Service オブジェクトは、ELB Service の例です。

    apiVersion: v1
kind: Service
metadata:
  name: ELB_SERVICE_NAME
  namespace: PROJECT_NAME
spec:
  ports:
  - port: 1235
    protocol: TCP
    targetPort: 1235
  selector:
    k8s-app: my-app
  type: LoadBalancer

    次のように置き換えます。

    • ELB_SERVICE_NAME: ELB サービスの名前。
    • PROJECT_NAME: バックエンド ワークロードを含むプロジェクトの名前空間。

    port フィールドは、VIP アドレスで公開するフロントエンド ポートを構成します。targetPort フィールドは、バックエンド ワークロードのトラフィックを転送するバックエンド ポートを構成します。ロードバランサは、ネットワーク アドレス変換（NAT）をサポートしています。フロントエンド ポートとバックエンド ポートは異なる場合があります。

  2. Service 定義の selector フィールドで、バックエンド ワークロードとして Pod または仮想マシンを指定します。

    セレクタは、指定したラベルとワークロードのラベルを照合して、このサービスのバックエンド ワークロードとして使用するワークロードを定義します。Service は、Service を定義したプロジェクトと同じプロジェクト、同じクラスタ内のバックエンド ワークロードのみを選択できます。

    サービス選択の詳細については、https://kubernetes.io/docs/concepts/services-networking/service/ をご覧ください。

  3. Service 定義ファイルをバックエンド ワークロードと同じプロジェクトに保存します。

  4. Service 定義ファイルをクラスタに適用します。

    kubectl apply -f ELB_FILE

    ELB_FILE は、ELB サービスの Service 定義ファイルの名前に置き換えます。

    ELB を作成すると、サービスは 2 つの IP アドレスを取得します。1 つは、同じクラスタ内からのみアクセス可能な内部 IP アドレスです。もう 1 つは外部 IP アドレスで、組織の内外からアクセスできます。ELB サービスの IP アドレスは、サービス ステータスを表示することで取得できます。

    kubectl -n PROJECT_NAME get svc ELB_SERVICE_NAME

    次のように置き換えます。

    • PROJECT_NAME: バックエンド ワークロードを含むプロジェクトの名前空間。
    • ELB_SERVICE_NAME: ELB サービスの名前。

    出力は次の例のようになります。

    NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
elb-service             LoadBalancer   10.0.0.1      20.12.1.11      1235:31931/TCP   22h

    EXTERNAL-IP は、組織外からアクセスできる Service の IP アドレスです。

    出力が得られない場合は、ELB サービスが正常に作成されていることを確認します。

グローバル ELB を作成する

gdcloud CLI または KRM API を使用して、グローバル ELB を作成します。

gdcloud

gdcloud CLI を使用して、Pod または VM ワークロードをターゲットとする ELB を作成します。

この ELB は、Backend オブジェクトで定義されたラベルに一致するプロジェクト内のすべてのワークロードをターゲットにします。Backend カスタム リソースはゾーンにスコープ設定する必要があります。

gdcloud CLI を使用して ELB を作成する手順は次のとおりです。

  1. Backend リソースを作成して、ELB のエンドポイントを定義します。

    gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT_NAME \
  --cluster-name=CLUSTER_NAME \
  --zone=ZONE

    次のように置き換えます。

    • BACKEND_NAME: バックエンド リソースに選択した名前（my-backend など）。
    • LABELS: このバックエンド リソースに使用する Pod と VM 間のエンドポイントを定義するセレクタ。例: app=web
    • PROJECT_NAME: プロジェクトの名前。
    • CLUSTER_NAME: 定義されたセレクタのスコープが制限されるクラスタ。このフィールドが指定されていない場合、指定されたラベルを持つすべてのエンドポイントが選択されます。このフィールドは省略可能です。
    • ZONE: この呼び出しに使用するゾーン。ゾーンフラグを必要とするすべてのコマンドにゾーンフラグを事前に設定するには、gdcloud config set core/zone ZONE を実行します。zone フラグは、マルチゾーン環境でのみ使用できます。このフィールドは省略可能です。

  2. この ELB が Pod ワークロード用である場合は、この手順をスキップします。VM ワークロードに ELB を構成する場合は、ELB のヘルスチェックを定義します。

    gdcloud compute health-checks create tcp HEALTH_CHECK_NAME \
  --check-interval=CHECK_INTERVAL \
  --healthy-threshold=HEALTHY_THRESHOLD \
  --timeout=TIMEOUT \
  --unhealthy-threshold=UNHEALTHY_THRESHOLD \
  --port=PORT \
  --global

    次のように置き換えます。

    • HEALTH_CHECK_NAME: ヘルスチェック リソースに選択した名前（my-health-check など）。
    • CHECK_INTERVAL: 1 つのプローブの開始から次のプローブの開始までの時間（秒単位）。省略するか 0 に設定した場合のデフォルトは 5 です。timeout を checkInterval より長く設定することはおすすめしません。
    • HEALTHY_THRESHOLD: 失敗を宣言するまでの待機時間。省略するか 0 に設定した場合のデフォルトは 5 です。
    • TIMEOUT: 失敗を宣言するまでの待機時間（秒単位）。省略するか 0 に設定した場合のデフォルトは 5 です。timeout を checkInterval より長く設定することはおすすめしません。
    • UNHEALTHY_THRESHOLD: エンドポイントが異常とみなされるために連続して失敗する必要があるプローブの数。省略するか 0 に設定した場合のデフォルトは 2 です。
    • PORT: ヘルスチェックが実行されるポート。デフォルト値は 80 です。このフィールドは省略可能です。

  3. BackendService リソースを作成し、以前に作成した Backend リソースを追加します。

    gdcloud compute backend-services create BACKEND_SERVICE_NAME \
  --project=PROJECT_NAME \
  --target-ports=TARGET_PORTS \
  --health-check=HEALTH_CHECK_NAME \
  --global

    次のように置き換えます。

    • BACKEND_SERVICE_NAME: このバックエンド サービスに選択した名前。
    • TARGET_PORTS: このバックエンド サービスが変換するターゲット ポートのカンマ区切りのリスト。各ターゲット ポートは、プロトコル、転送ルールのポート、バックエンド インスタンスのポートを指定します。複数のターゲット ポートを指定できます。このフィールドは、protocol:port:targetport の形式（TCP:80:8080 など）にする必要があります。このフィールドは省略可能です。
    • HEALTH_CHECK_NAME: ヘルスチェック リソースの名前。このフィールドは省略可能です。このフィールドは、VM ワークロード用に ELB を構成する場合にのみ指定します。

  4. 以前に作成した Backend リソースに BackendService リソースを追加します。

    gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --backend=BACKEND_NAME \
  --backend-zone BACKEND_ZONE \
  --project=PROJECT_NAME \
  --global

  5. 省略可: ELB にセッション アフィニティを使用して、同じクライアントからのリクエストが常に同じバックエンドにルーティングされるようにします。ロードバランサのセッション アフィニティを有効にするには、gdcloud compute load-balancer-policy create コマンドを使用してバックエンド サービス ポリシーを作成します。

     gdcloud compute load-balancer-policy create POLICY_NAME
 --session-affinity=MODE
 --selectors=RESOURCE_LABEL

    次のように置き換えます。

    • POLICY_NAME: バックエンド サービス ポリシーに選択した名前。

    • MODE: セッション アフィニティ モード。次の 2 つのモードがサポートされています。

      • NONE: セッション アフィニティは無効になっています。リクエストは、使用可能なバックエンドにルーティングされます。これがデフォルトのモードです。
      • CLIENT_IP_DST_PORT_PROTO: 同じ 4 タプル（送信元 IP アドレス、宛先 IP アドレス、宛先ポート、プロトコル）からのリクエストは、同じバックエンドにルーティングされます。

    • RESOURCE_LABEL: プロジェクトの名前空間で BackendServicePolicy リソースを適用するバックエンド サービスを選択するラベルセレクタ。複数の BackendServicePolicy リソースが同じバックエンド サービスに一致し、これらのポリシーの少なくとも 1 つでセッション アフィニティが有効になっている場合、この BackendService リソースのセッション アフィニティが有効になります。

  6. サービスが利用可能な VIP を定義する外部 ForwardingRule リソースを作成します。

    gdcloud compute forwarding-rules create FORWARDING_RULE_EXTERNAL_NAME \
  --backend-service=BACKEND_SERVICE_NAME \
  --cidr=CIDR \
  --ip-protocol-port=PROTOCOL_PORT \
  --load-balancing-scheme=EXTERNAL \
  --project=PROJECT_NAME \
  --global

    次のように置き換えます。

    • BACKEND_SERVICE_NAME: バックエンド サービスの名前。
    • FORWARDING_RULE_EXTERNAL_NAME: 転送ルールに選択した名前。
    • CIDR: このフィールドは省略可能です。指定しない場合、IPv4/32 CIDR はグローバル IP プールから自動的に予約されます。この転送ルールと同じ名前空間にある Subnet リソースの名前を指定します。Subnet リソースは、グローバル サブネットのリクエスト情報と割り当て情報を表します。Subnet リソースの詳細については、カスタム リソースの例をご覧ください。
    • PROTOCOL_PORT: 転送ルールで公開するプロトコルとポート。このフィールドは ip-protocol=TCP:80 の形式にする必要があります。公開ポートは、実際のアプリケーションがコンテナ内で公開しているポートと同じである必要があります。

  7. 構成された ELB を確認するには、作成された各オブジェクトの Ready 条件を確認します。ロードバランサに割り当てられた IP アドレスを取得するには、転送ルールを記述します。

    gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME

  8. 構成された ELB を検証するには、作成された各オブジェクトの Ready 条件を確認します。VIP への curl リクエストでトラフィックを確認します。

    1. 割り当てられた VIP を取得するには、転送ルールの説明を取得します。

      gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME --global

    2. 転送ルールの PROTOCOL_PORT フィールドで指定されたポートの VIP に curl リクエストを送信して、トラフィックを確認します。

      curl http://FORWARDING_RULE_VIP:PORT

      次のように置き換えます。

      • FORWARDING_RULE_VIP: 転送ルールの VIP。
      • PORT: 転送ルールの PROTOCOL_PORT フィールドのポート番号。

API

KRM API を使用して、Pod または VM ワークロードをターゲットとする ELB を作成します。この ELB は、Backend オブジェクトで定義されたラベルに一致するプロジェクト内のすべてのワークロードをターゲットにします。KRM API を使用してゾーン ELB を作成する手順は次のとおりです。

  1. Backend リソースを作成して、ELB のエンドポイントを定義します。ワークロードが配置されているゾーンごとに Backend リソースを作成します。

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: Backend
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_NAME
spec:
  clusterName: CLUSTER_NAME
  endpointsLabels:
    matchLabels:
      app: server
EOF

    次のように置き換えます。

    • MANAGEMENT_API_SERVER: グローバル Management API サーバーの kubeconfig パス。詳細については、グローバル コンテキストに切り替えるをご覧ください。
    • PROJECT_NAME: プロジェクトの名前。
    • BACKEND_NAME: Backend リソースの名前。
    • CLUSTER_NAME: これは省略可能なフィールドです。このフィールドでは、定義されたセレクタのスコープを制限するクラスタを指定します。このフィールドは VM ワークロードには適用されません。Backend リソースに clusterName フィールドが含まれていない場合、指定されたラベルはプロジェクト内のすべてのワークロードに適用されます。

  2. この ELB が Pod ワークロード用である場合は、この手順をスキップします。VM ワークロードに ELB を構成する場合は、ELB のヘルスチェックを定義します。

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: HealthCheck
metadata:
  namespace: PROJECT_NAME
  name: HEALTH_CHECK_NAME
spec:
  tcpHealthCheck:
    port: PORT
  timeoutSec: TIMEOUT
  checkIntervalSec: CHECK_INTERVAL
  healthyThreshold: HEALTHY_THRESHOLD
  unhealthyThreshold: UNHEALTHY_THRESHOLD
EOF

    次のように置き換えます。

    • HEALTH_CHECK_NAME: ヘルスチェック リソースに選択した名前（my-health-check など）。
    • PORT: ヘルスチェックが実行されるポート。デフォルト値は 80 です。
    • TIMEOUT: 失敗を宣言するまでの待機時間（秒単位）。省略するか 0 に設定した場合のデフォルトは 5 です。timeout を checkInterval より長く設定することはおすすめしません。
    • CHECK_INTERVAL: 1 つのプローブの開始から次のプローブの開始までの時間（秒単位）。省略するか 0 に設定した場合のデフォルトは 5 です。timeout を checkInterval より長く設定することはおすすめしません。
    • HEALTHY_THRESHOLD: エンドポイントが正常と見なされるために合格する必要がある連続プローブの数。省略するか 0 に設定した場合のデフォルトは 2 です。
    • UNHEALTHY_THRESHOLD: エンドポイントが異常とみなされるために連続して失敗する必要があるプローブの数。省略するか 0 に設定した場合のデフォルトは 2 です。

    これはグローバル ELB であるため、グローバル API でヘルスチェックを作成します。

  3. 以前に作成した Backend リソースを使用して BackendService オブジェクトを作成します。VM ワークロード用に ELB を構成する場合は、HealthCheck リソースを含めます。

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: BackendService
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_SERVICE_NAME
spec:
  backendRefs:
  - name: BACKEND_NAME
    zone: ZONE
  healthCheckName: HEALTH_CHECK_NAME
  targetPorts:
  - port: PORT
    protocol: PROTOCOL
    targetPort: TARGET_PORT
EOF

    次のように置き換えます。

    • BACKEND_SERVICE_NAME: BackendService リソースに選択した名前。
    • HEALTH_CHECK_NAME: 以前に作成した HealthCheck リソースの名前。Pod ワークロードに ELB を構成する場合は、このフィールドを含めないでください。

    • ZONE: Backend リソースが作成されるゾーン。backendRefs フィールドには複数のバックエンドを指定できます。次に例を示します。

      - name: my-be
  zone: Zone-A
- name: my-be
  zone: Zone-B

    • targetPorts フィールドは省略可能です。このリソースには、この BackendService リソースが変換するポートが一覧表示されます。このオブジェクトを使用する場合は、次の値を指定します。

      • PORT: サービスによって公開されるポート。
      • PROTOCOL: トラフィックが一致する必要があるレイヤ 4 プロトコル。TCP と UDP のみがサポートされています。

      • TARGET_PORT: PORT 値の変換先のポート（8080 など）。TARGET_PORT の値を特定のオブジェクトで繰り返すことはできません。targetPorts の例を次に示します。

        targetPorts:
- port: 80
  protocol: TCP
  targetPort: 8080

  4. 省略可: ELB にセッション アフィニティを使用して、同じクライアントからのリクエストが常に同じバックエンドにルーティングされるようにします。ロードバランサのセッション アフィニティを有効にするには、BackendServicePolicy リソースを作成します。このリソースは、セッション アフィニティの設定を定義し、BackendServicePolicy リソースを BackendService リソースに適用します。BackendServicePolicy リソースを作成して適用します。

     kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
 apiVersion: networking.global.gdc.goog/v1
 kind: BackendServicePolicy
 metadata:
     namespace: PROJECT_NAME
     name: POLICY_NAME
 spec:
     sessionAffinity: MODE
     selector:
         matchLabels:
           RESOURCE_LABEL

    次のように置き換えます。

    • POLICY_NAME: バックエンド サービス ポリシーに選択した名前。

    • MODE: セッション アフィニティ モード。次の 2 つのモードがサポートされています。

      • NONE: セッション アフィニティは無効になっています。リクエストは、使用可能なバックエンドにルーティングされます。これがデフォルトのモードです。
      • CLIENT_IP_DST_PORT_PROTO: 同じ 4 タプル（送信元 IP アドレス、宛先 IP アドレス、宛先ポート、プロトコル）からのリクエストは、同じバックエンドにルーティングされます。

    • RESOURCE_LABEL: プロジェクトの名前空間で BackendServicePolicy リソースを適用するバックエンド サービスを選択するラベルセレクタ。複数の BackendServicePolicy リソースが同じバックエンド サービスに一致し、これらのポリシーの少なくとも 1 つでセッション アフィニティが有効になっている場合、この BackendService リソースのセッション アフィニティが有効になります。

  5. サービスが利用可能な VIP を定義する外部 ForwardingRule リソースを作成します。

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ForwardingRuleExternal
metadata:
  namespace: PROJECT_NAME
  name: FORWARDING_RULE_EXTERNAL_NAME
spec:
  cidrRef:
    name: CIDR_NAME
  ports:
  - port: PORT
    protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF

    次のように置き換えます。

    • FORWARDING_RULE_EXTERNAL_NAME: ForwardingRuleExternal リソースに選択した名前。
    • CIDR_NAME: cidrRef フィールドは省略可能です。指定しない場合、IPv4/32 CIDR はグローバル IP プールから自動的に予約されます。この転送ルールと同じ名前空間にある Subnet リソースの名前を指定します。Subnet リソースは、グローバル サブネットのリクエスト情報と割り当て情報を表します。Subnet リソースの詳細については、カスタム リソースの例をご覧ください。
    • PORT: ports フィールドを使用して、この転送ルールで構成されたバックエンドにパケットが転送される L4 ポートの配列を指定します。少なくとも 1 つのポートを指定する必要があります。port フィールドを使用してポート番号を指定します。公開ポートは、実際のアプリケーションがコンテナ内で公開しているポートと同じである必要があります。

    • PROTOCOL: 転送ルールに使用するプロトコル（TCP など）。ports 配列のエントリは次のようになります。

      ports:
- port: 80
  protocol: TCP

  6. 構成された ELB を検証するには、作成された各オブジェクトの Ready 条件を確認します。VIP への curl リクエストでトラフィックを確認します。

    1. VIP を取得するには、kubectl get を使用します。

      kubectl get forwardingruleexternal -n PROJECT_NAME

      出力は次のようになります。

      NAME           BACKENDSERVICE                               CIDR              READY
elb-name       BACKEND_SERVICE_NAME        10.200.32.59/32   True

    2. 転送ルールの PORT フィールドで指定されたポートの VIP に curl リクエストを送信して、トラフィックを確認します。

      curl http://FORWARDING_RULE_VIP:PORT

      FORWARDING_RULE_VIP は、転送ルールの VIP に置き換えます。

Standard クラスタの外部ロードバランサを作成する

アプリケーション オーナー（AO）は、LoadBalancer タイプの Kubernetes Service を作成して、サービスを外部に公開できます。このサービスは、サービスが作成された標準クラスタ内のバックエンドのみを選択できます。これは、ゾーンクラスタ スコープの ELB と同等です。標準クラスタでは、グローバル ELB はサポートされていません。詳細については、グローバル ロードバランサとゾーン ロードバランサをご覧ください。

始める前に

ELB サービスを構成するには、次の操作を行う必要があります。

  • ロードバランサを構成するプロジェクトを所有している。詳細については、プロジェクトを作成するをご覧ください。
  • この ELB サービスへのトラフィックを許可するようにカスタマイズされた ProjectNetworkPolicy（PNP）上り（内向き）ポリシーがある。詳細については、Standard クラスタの ELB へのトラフィックを許可するように PNP を構成するをご覧ください。

  • 必要な Identity and Access のロールを付与されている。

    • プロジェクト NetworkPolicy 管理者: プロジェクトの名前空間でプロジェクト ネットワーク ポリシーを管理するためのアクセス権があります。IAM 組織管理者に、プロジェクト NetworkPolicy 管理者（project-networkpolicy-admin）ロールの付与を依頼してください。
    • ロードバランサ管理者: IAM 組織管理者に、ロードバランサ管理者（load-balancer-admin）ロールを付与するよう依頼します。

Standard クラスタの ELB へのトラフィックを許可するように PNP を構成する

ELB サービスが機能するには、独自のカスタマイズされた ProjectNetworkPolicy 上り（内向き）ポリシーを構成して適用し、この ELB サービスのワークロードへのトラフィックを許可する必要があります。ネットワーク ポリシーは、ロードバランサ自体ではなく、ワークロードへのアクセスを制御します。ELB はワークロードを顧客ネットワークに公開するため、ワークロード ポート（8080 など）への外部トラフィックを許可する明示的なネットワーク ポリシーが必要です。

次のプロジェクト ネットワーク ポリシーの YAML ファイルの例では、別のプロジェクトのワークロードからのトラフィックが ELB を介して現在のプロジェクトのワークロードにアクセスできるようにします。

apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  name: allow-ingress-from-client-to-server
  namespace: ${VANILLA_CLUSTER_PROJECT}
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        clusters:
          matchLabels:
            kubernetes.io/metadata.name: my-sc-1
        namespaces:
          matchLabels:
            kubernetes.io/metadata.name: my-app-ns
        workloads:
          matchLabels:
            app: my-internal-app
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - "$PROJECT_2"
        workloadSelector:
          labelSelector:
            workloads:
              matchLabels:
                app: my-client
    ports:
    - protocol: TCP
      port: 8080

Standard クラスタのゾーン ELB を作成する

GDC で ELB を作成するには、標準の Kubernetes クラスタに LoadBalancer タイプの Kubernetes Service を作成します。

ELB サービスを作成するには、次の操作を行います。

  1. タイプ LoadBalancer の Service 定義の YAML ファイルを作成します。

    次の Service オブジェクトは、ELB Service の例です。

    apiVersion: v1
kind: Service
metadata:
  name: ELB_SERVICE_NAME
  namespace: ELB_SERVICE_NAMESPACE
spec:
  ports:
  - port: PORT
    protocol: TCP
    targetPort: TARGET_PORT
  selector:
    k8s-app: my-app # Example selector, replace with your workload's labels
  type: LoadBalancer

    次のように置き換えます。

    • ELB_SERVICE_NAME: ELB サービスの名前。
    • ELB_SERVICE_NAMESPACE: バックエンド ワークロードを含む標準クラスタ内の Namespace。
    • PORT: Kubernetes Service 自体によって公開されるポート。クラスタ内の他のサービスまたは外部クライアントは、Service の IP アドレスのこのポートに接続します。
    • TARGET_PORT: アプリケーションがアクティブに実行され、受信接続をリッスンしている Pod のコンテナ内のポート。これは、Pod のコンテナ仕様で定義された数値ポートまたは名前付きポートです。

    port フィールドは、VIP アドレスで公開するフロントエンド ポートを構成します。targetPort フィールドは、バックエンド ワークロードのトラフィックを転送するバックエンド ポートを構成します。ロードバランサは、ネットワーク アドレス変換（NAT）をサポートしています。フロントエンド ポートとバックエンド ポートは異なる場合があります。

  2. Service 定義の selector フィールドで、バックエンド ワークロードと一致する Key-Value ペアを指定します。標準クラスタの場合、ワークロードとしてサポートされるのは Pod のみです。

    定義したセレクタ。指定したラベルとワークロードのラベルの一致に基づきます。Service は、Service を定義した同じプロジェクトと同じクラスタ内のバックエンド ワークロードのみを選択できます。

    サービス選択の詳細については、https://kubernetes.io/docs/concepts/services-networking/service/ をご覧ください。

  3. Service 仕様を YAML ファイルに保存します。次のコマンドで、ELB_FILE をファイル名に置き換えます。

  4. Service 定義ファイルをクラスタに適用します。

    export KUBECONFIG=KUBECONFIG_PATH
kubectl apply -f ELB_FILE

    次のように置き換えます。

    • ELB_FILE:ELB サービスの Service 定義ファイルの名前。
    • KUBECONFIG_PATH: 標準クラスタの kubeconfig ファイルのパス。

    ELB サービスの IP アドレスを取得するには、サービス ステータスを表示します。

    kubectl -n ELB_SERVICE_NAMESPACE get svc ELB_SERVICE_NAME

    次のように置き換えます。

    • ELB_SERVICE_NAMESPACE: バックエンド ワークロードを含む Namespace。
    • ELB_SERVICE_NAME: ELB サービスの名前。

    出力は次の例のようになります。

    NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
elb-service             LoadBalancer   10.0.0.1      203.0.1.11      1235:31931/TCP   22h

    EXTERNAL-IP は、組織外からアクセスできる Service の IP アドレスです。

ロードバランサのバックエンドとして VM を選択する

VM をロードバランサにリンクするには:

  1. VM に、ロードバランサの構成で使用されているラベルセレクタと一致するラベルがあることを確認します。

    たとえば、VM に適切なラベルがない場合は、対応するゾーンのバックエンド オブジェクトから指定されたラベルを VM に追加できます。

    kubectl --kubeconfig MANAGEMENT_API_SERVER label virtualmachine VM_NAME -n PROJECT_NAMELABEL

    次のように置き換えます。

    • LABEL: ロードバランサ構成の LabelSelector と一致するラベル（app=server など）。
    • VM_NAME: リンクする仮想マシンの名前。
    • PROJECT_NAME: プロジェクトの名前。

  2. サーバーが HealthCheck オブジェクトで指定されたポートと同じポートでリッスンしていることを確認します。