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

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

内部ロードバランサ（ILB）は、組織に割り当てられた内部 IP プールから組織内のサービスを公開します。ILB サービスには、組織外のエンドポイントからアクセスできません。

デフォルトでは、組織内の任意のクラスタから同じプロジェクト内の ILB サービスにアクセスできます。デフォルトのプロジェクトネットワークポリシーでは、プロジェクト外からプロジェクトリソースにアクセスできません。この制限は ILB サービスにも適用されます。プラットフォーム管理者（PA）が、他のプロジェクトからプロジェクトへのアクセスを許可するプロジェクトネットワークポリシーを構成すると、同じ組織内の他のプロジェクトからも ILB サービスにアクセスできるようになります。

始める前に

ILB を構成するには、次のものが必要です。

ロードバランサを構成するプロジェクトを所有している。詳細については、プロジェクトを作成するをご覧ください。
必要な ID とアクセスロール:
- 組織の IAM 管理者に、ロードバランサ管理者（load-balancer-admin）ロールを付与するよう依頼します。
- グローバル ILB の場合は、組織 IAM 管理者にグローバルロードバランサ管理者（global-load-balancer-admin）ロールの付与を依頼してください。詳細については、事前定義ロールの説明をご覧ください。

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

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

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

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

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

ゾーン ILB を作成する

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

gdcloud

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

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

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

ILB のエンドポイントを定義する 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: 定義されたセレクタのスコープが制限されるクラスタ。このフィールドが指定されていない場合、指定されたラベルを持つすべてのエンドポイントが選択されます。このフィールドは省略可能です。
この ILB が Pod ワークロード用である場合は、この手順をスキップします。VM ワークロード用に ILB を構成する場合は、ILB のヘルスチェックを定義します。
```
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: この ILB を作成するゾーン。
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_PORTS: このバックエンドサービスが変換するターゲットポートのカンマ区切りリスト。各ターゲットポートは、プロトコル、転送ルールのポート、バックエンドインスタンスのポートを指定します。複数のターゲットポートを指定できます。このフィールドは protocol:port:targetport 形式（TCP:80:8080 など）にする必要があります。このフィールドは省略可能です。
- HEALTH_CHECK_NAME: ヘルスチェックリソースの名前。このフィールドは省略可能です。このフィールドは、VM ワークロードの ILB を構成する場合にのみ含めます。

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

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

サービスが使用可能な VIP を定義する内部 ForwardingRule リソースを作成します。
```
gdcloud compute forwarding-rules create FORWARDING_RULE_INTERNAL_NAME \
  --backend-service=BACKEND_SERVICE_NAME \
  --cidr=CIDR \
  --ip-protocol-port=PROTOCOL_PORT \
  --load-balancing-scheme=INTERNAL \
  --zone=ZONE \
  --project=PROJECT_NAME
```
次のように置き換えます。
- BACKEND_SERVICE_NAME: バックエンドサービスの名前。
- FORWARDING_RULE_INTERNAL_NAME は、転送ルールに選択した名前に置き換えます。
- CIDR: このフィールドは省略可能です。指定しない場合、IPv4/32 CIDR がゾーン IP プールから自動的に予約されます。この転送ルールと同じ Namespace にある Subnet リソースの名前を指定します。Subnet リソースは、ゾーンサブネットのリクエストと割り当て情報を表します。Subnet リソースの詳細については、カスタムリソースの例をご覧ください。
- PROTOCOL_PORT: 転送ルールで公開するプロトコルとポート。このフィールドは ip-protocol=TCP:80 の形式にする必要があります。公開されるポートは、実際のアプリケーションがコンテナ内で公開しているポートと同じである必要があります。
構成された ILB を検証するには、作成された各オブジェクトの Ready 条件を確認します。VIP への curl リクエストでトラフィックを確認します。
1. 割り当てられた VIP を取得するには、転送ルールを説明します。
```
gdcloud compute forwarding-rules describe FORWARDING_RULE_INTERNAL_NAME
```
2. 転送ルールの PROTOCOL_PORT フィールドで指定されたポートの VIP への curl リクエストでトラフィックを確認します。
```
curl http://FORWARDING_RULE_VIP:PORT
```
  次のように置き換えます。
  - FORWARDING_RULE_VIP: 転送ルールの VIP。
  - PORT: 転送ルールの PROTOCOL_PORT フィールドのポート番号。

API

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

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

Backend リソースを作成して、ILB のエンドポイントを定義します。ワークロードが配置されているゾーンごとに 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 フィールドが含まれていない場合、指定されたラベルはプロジェクト内のすべてのワークロードに適用されます。
各ゾーンに同じ Backend リソースを使用することも、各ゾーンに異なるラベルセットを持つ Backend リソースを作成することもできます。
この ILB が Pod ワークロード用である場合は、この手順をスキップします。VM ワークロード用に ILB を構成する場合は、ILB のヘルスチェックを定義します。
```
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 ワークロード用に ILB を構成する場合は、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 ワークロードの ILB を構成する場合は、このフィールドを含めないでください。
サービスが利用可能な VIP を定義する内部 ForwardingRule リソースを作成します。
```
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ForwardingRuleInternal
metadata:
  namespace: PROJECT_NAME
  Name: FORWARDING_RULE_INTERNAL_NAME
spec:
  cidrRef: CIDR
  ports:
  - port: PORT
    Protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF
```
次のように置き換えます。
- FORWARDING_RULE_INTERNAL_NAME: ForwardingRuleInternal リソースに選択した名前。
- CIDR: このフィールドは省略可能です。指定しない場合、IPv4/32 CIDR がゾーン IP プールから自動的に予約されます。この転送ルールと同じ Namespace にある Subnet リソースの名前を指定します。Subnet リソースは、ゾーンサブネットのリクエストと割り当て情報を表します。Subnet リソースの詳細については、カスタムリソースの例をご覧ください。
- PORT: ports フィールドを使用して、この転送ルールで構成されたバックエンドにパケットが転送される L4 ポートの配列を指定します。少なくとも 1 つのポートを指定する必要があります。port フィールドを使用して、ポート番号を指定します。公開されるポートは、実際のアプリケーションがコンテナ内で公開しているポートと同じである必要があります。
- PROTOCOL: 転送ルールに使用するプロトコル（TCP など）。ports 配列のエントリは次のようになります。
```
ports:
- port: 80
  protocol: TCP
```
構成された ILB を検証するには、作成された各オブジェクトの Ready 条件を確認します。VIP への curl リクエストでトラフィックを確認します。
1. VIP を取得するには、kubectl get を使用します。
```
kubectl get forwardingruleinternal -n PROJECT_NAME
```
  出力は次のようになります。
```
NAME           BACKENDSERVICE                               CIDR              READY
ilb-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 で ILB を作成するには、Kubernetes クラスタでタイプ LoadBalancer の Kubernetes Service オブジェクトを作成します。この ILB は、Service オブジェクトが作成されたクラスタ内のワークロードのみをターゲットにします。

Service オブジェクトを使用して ILB を作成する手順は次のとおりです。

タイプ LoadBalancer の Service 定義の YAML ファイルを作成します。networking.gke.io/load-balancer-type: internal アノテーションを使用して、ILB サービスを内部として設計する必要があります。

注: internal の値は、大文字と小文字が区別され、小文字にする必要があります。
次の Service オブジェクトは、ILB サービスの例です。
```
apiVersion: v1
kind: Service
metadata:
  annotations:
    networking.gke.io/load-balancer-type: internal
  name: ILB_SERVICE_NAME
  namespace: PROJECT_NAME
spec:
  ports:
  - port: 1234
    protocol: TCP
    targetPort: 1234
  selector:
    k8s-app: my-app
  type: LoadBalancer
```
次のように置き換えます。
- ILB_SERVICE_NAME: ILB サービスの名前。
- PROJECT_NAME: バックエンドワークロードを含むプロジェクトの Namespace。
port フィールドは、VIP アドレスで公開するフロントエンドポートを構成します。targetPort フィールドは、バックエンドワークロードのトラフィックを転送するバックエンドポートを構成します。ロードバランサはネットワークアドレス変換（NAT）をサポートしています。フロントエンドポートとバックエンドポートは異なる場合があります。
Service 定義の selector フィールドで、バックエンドワークロードとして Pod または仮想マシンを指定します。

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

サービス選択の詳細については、https://kubernetes.io/docs/concepts/services-networking/service/ をご覧ください。
Service 定義ファイルをバックエンドワークロードと同じプロジェクトに保存します。ILB サービスは、Service 定義と同じクラスタ内のワークロードのみを選択できます。
Service 定義ファイルをクラスタに適用します。
```
kubectl apply -f ILB_FILE
```
ILB_FILE は、ILB サービスの Service 定義ファイルの名前に置き換えます。

ILB サービスを作成すると、サービスに IP アドレスが割り当てられます。ILB サービスの IP アドレスは、サービスステータスを表示することで取得できます。
```
kubectl -n PROJECT_NAME get svc ILB_SERVICE_NAME
```
次のように置き換えます。
- PROJECT_NAME: バックエンドワークロードを含むプロジェクトの Namespace。
- ILB_SERVICE_NAME: ILB サービスの名前。
次の例のような出力を取得する必要があります。
```
NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
ilb-service             LoadBalancer   10.0.0.1      10.0.0.1        1234:31930/TCP   22h
```
CLUSTER-IP フィールドと EXTERNAL-IP フィールドには、ILB サービスの IP アドレスと同じ値が表示されている必要があります。この IP アドレスは、プロジェクトが持つプロジェクトネットワークポリシーに従って、組織内の他のクラスタからアクセスできるようになりました。

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

GDC は、サービスのドメインネームシステム（DNS）名をサポートしています。ただし、これらの名前は ILB サービスと同じクラスタでのみ機能します。他のクラスタから ILB サービスにアクセスするには、IP アドレスを使用する必要があります。

重要: CLUSTER-IP と EXTERNAL-IP の値が同じでない場合は、サービスを外部ロードバランサ（ELB）サービスとして構成しています。Service 定義で networking.gke.io/load-balancer-type: internal アノテーションが正しいことを確認します。アノテーションのキーと値では大文字と小文字が区別されます。

グローバル ILB を作成する

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