このページは Cloud Translation API によって翻訳されました。

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

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

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

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

始める前に

ELB サービスを構成するには、次のものが必要です。

ロードバランサを構成するプロジェクトを所有している。詳細については、プロジェクトを作成するをご覧ください。
この ELB サービスへのトラフィックを許可するカスタマイズされた ProjectNetworkPolicy（PNP）上り（内向き）ポリシー。詳細については、ELB へのトラフィックを許可するように PNP を構成するをご覧ください。
必要な ID とアクセスロール:
- プロジェクト NetworkPolicy 管理者: プロジェクト Namespace のプロジェクトネットワークポリシーを管理する権限があります。組織 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）を使用し、送信元外部 IP アドレスを保持して、戻りパスでロードバランサをバイパスするため必要です。詳細については、組織外のトラフィック用のグローバル上り（内向き）ファイアウォールルールを作成するをご覧ください。
PORT: ロードバランサの背後にある Pod のバックエンドポート。この値は、Service リソースのマニフェストの .spec.ports[].targetPort フィールドにあります。このフィールドは省略可能です。

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

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

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

gdcloud CLI を使用して、グローバルまたはゾーンの ELB を作成します。
Networking Kubernetes Resource Model（KRM）API を使用して、グローバルまたはゾーンの 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 を作成する手順は次のとおりです。

ELB のエンドポイントを定義する Backend リソースを作成します。
```
gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT_NAME \
  --zone=ZONE \
  --cluster=CLUSTER_NAME
```
次のように置き換えます。
- BACKEND_NAME: バックエンドリソースに選択した名前（my-backend など）。
- LABELS: このバックエンドリソースに使用する Pod と VM 間のエンドポイントを定義するセレクタ。例: app=web
- PROJECT_NAME: プロジェクトの名前。
- ZONE: この呼び出しに使用するゾーン。ゾーンフラグを必要とするすべてのコマンドに対してゾーンフラグをプリセットするには、gdcloud config set core/zone ZONE を実行します。ゾーンフラグは、マルチゾーン環境でのみ使用できます。このフィールドは省略可能です。
- CLUSTER_NAME: 定義されたセレクタのスコープが制限されるクラスタ。このフィールドが指定されていない場合、指定されたラベルを持つすべてのエンドポイントが選択されます。このフィールドは省略可能です。
この 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 \
  --zone=ZONE
```
次のように置き換えます。
- HEALTH_CHECK_NAME: ヘルスチェックリソースに選択した名前（my-health-check など）。
- CHECK_INTERVAL: 1 つのプローブの開始から次のプローブの開始までの時間（秒単位）。デフォルト値は 5 です。このフィールドは省略可能です。
- HEALTHY_THRESHOLD: 失敗を宣言するまでの待機時間。デフォルト値は 5 です。このフィールドは省略可能です。
- TIMEOUT: 失敗を宣言するまでの待機時間（秒）。デフォルト値は 5 です。このフィールドは省略可能です。
- UNHEALTHY_THRESHOLD: エンドポイントが異常とみなされるために連続して失敗しなければならないプローブの数。デフォルト値は 2 です。このフィールドは省略可能です。
- PORT: ヘルスチェックが実行されるポート。デフォルト値は 80 です。このフィールドは省略可能です。
- ZONE: この ELB を作成するゾーン。
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 を構成する場合にのみ使用します。

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

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

省略可: 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 リソースのセッションアフィニティが有効になります。
サービスが利用可能な 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 の形式にする必要があります。公開されるポートは、実際のアプリケーションがコンテナ内で公開しているポートと同じである必要があります。
構成された ELB を検証するには、作成された各オブジェクトの Ready 条件を確認します。ロードバランサに割り当てられた IP アドレスを取得するには、転送ルールを記述します。
```
gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME
```
構成された 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 を作成する手順は次のとおりです。

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 フィールドが含まれていない場合、指定されたラベルはプロジェクト内のすべてのワークロードに適用されます。
この 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: 失敗を宣言するまでの待機時間（秒）。デフォルト値は 5 です。
- CHECK_INTERVAL: 1 つのプローブの開始から次のプローブの開始までの時間（秒単位）。デフォルト値は 5 です。
- HEALTHY_THRESHOLD: エンドポイントが正常とみなされるために連続して成功しなければならないプローブの数。デフォルト値は 2 です。
- UNHEALTHY_THRESHOLD: エンドポイントが異常とみなされるために連続して失敗しなければならないプローブの数。デフォルト値は 2 です。
前に作成した 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 を構成する場合は、このフィールドを含めないでください。
省略可: 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 リソースのセッションアフィニティが有効になります。
サービスが利用可能な 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: CIDR
  ports:
  - port: PORT
    Protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF
```
次のように置き換えます。
- BACKEND_SERVICE_NAME: BackendService リソースの名前。
- FORWARDING_RULE_EXTERNAL_NAME: ForwardingRuleExternal リソースに選択した名前。
- CIDR: このフィールドは省略可能です。指定しない場合、IPv4/32 CIDR はゾーン IP プールから自動的に予約されます。この転送ルールと同じ Namespace 内の Subnet リソースの名前を指定します。Subnet リソースは、ゾーンサブネットのリクエストと割り当て情報を表します。Subnet リソースの詳細については、カスタムリソースの例をご覧ください。
- PORT: ports フィールドを使用して、この転送ルールで構成されたバックエンドにパケットが転送される L4 ポートの配列を指定します。少なくとも 1 つのポートを指定する必要があります。port フィールドを使用して、ポート番号を指定します。公開されるポートは、実際のアプリケーションがコンテナ内で公開しているポートと同じである必要があります。
- PROTOCOL: 転送ルールに使用するプロトコル（TCP など）。ports 配列のエントリは次のようになります。
```
ports:
- port: 80
  protocol: TCP
```
構成された 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 サービスを作成するには、次の操作を行います。

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

注: 内部ロードバランサのプロセスとは異なり、ファイルにアノテーションを追加しないでください。internal アノテーションを指定しない場合、サービスはデフォルトで外部に公開されます。
次の Service オブジェクトは、ELB サービスの例です。
```
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: バックエンドワークロードを含むプロジェクトの Namespace。
port フィールドは、VIP アドレスで公開するフロントエンドポートを構成します。targetPort フィールドは、バックエンドワークロードのトラフィックを転送するバックエンドポートを構成します。ロードバランサはネットワークアドレス変換（NAT）をサポートしています。フロントエンドポートとバックエンドポートは異なる場合があります。
Service 定義の selector フィールドで、バックエンドワークロードとして Pod または仮想マシンを指定します。

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

サービス選択の詳細については、https://kubernetes.io/docs/concepts/services-networking/service/ をご覧ください。
Service 定義ファイルをバックエンドワークロードと同じプロジェクトに保存します。
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: バックエンドワークロードを含むプロジェクトの Namespace。
- 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 は、組織外からアクセスできるサービスの IP アドレスです。

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

グローバル ELB を作成する

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