このページでは、Google Kubernetes Engine(GKE)で内部アプリケーション ロードバランサ用の Ingress を設定して使用する方法を説明します。Ingress は、GKE Ingress コントローラを介して内部ロード バランシングに対する組み込みサポートを提供します。
内部アプリケーション ロードバランサ用の Ingress でサポートされる機能の詳細については、Ingress の機能をご覧ください。内部アプリケーション ロードバランサ用の Ingress の仕組みについては、内部アプリケーション ロードバランサ用の Ingress をご覧ください。
始める前に
作業を始める前に、次のことを確認してください。
- Google Kubernetes Engine API を有効にする。 Google Kubernetes Engine API の有効化
- このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、
gcloud components update
を実行して最新のバージョンを取得する。
要件
内部アプリケーション ロードバランサ用の Ingress には、次の要件があります。
- クラスタで 1.16.5-gke.10 より後のバージョンの GKE を使用している必要があります。
- クラスタが VPC ネイティブである必要があります。
- クラスタで
HttpLoadBalancing
アドオンが有効になっている必要があります。このアドオンはデフォルトで有効になっています。無効にしないでください。 - ネットワーク エンドポイント グループ(NEG)を Service のバックエンドとして使用する必要があります。
内部アプリケーション ロードバランサ用の Ingress のデプロイ
以下の演習で、内部アプリケーション ロードバランサ用の Ingress をデプロイする方法を説明します。
環境を準備する
Kubernetes Ingress API を使用してロードバランサ リソースをデプロイする前に、所定のリージョンにロードバランサ プロキシをデプロイできるよう、ネットワーク環境を準備する必要があります。
プロキシ専用サブネットを作成します。
gcloud compute networks subnets create proxy-only-subnet \
--purpose=REGIONAL_MANAGED_PROXY \
--role=ACTIVE \
--region=COMPUTE_REGION \
--network=NETWORK_NAME \
--range=10.129.0.0/23
次のように置き換えます。
COMPUTE_REGION
: Compute Engine のリージョン。NETWORK_NAME
: サブネットのネットワークの名前。
詳細については、プロキシ専用サブネットの構成をご覧ください。
ファイアウォール ルールを作成する
プロキシ サブネット内のロードバランサ プロキシからの接続を許可するファイアウォール ルールは、Ingress コントローラでは作成されません。このファイアウォール ルールは、手動で作成する必要があります。ただし、Google Cloud ヘルスチェックの上り(内向き)トラフィックを許可するファイアウォール ルールは、Ingress コントローラによって作成されます。
プロキシ専用サブネット内のロードバランサ プロキシから Pod リスニング ポートへの接続を許可するファイアウォール ルールを作成します。
gcloud compute firewall-rules create allow-proxy-connection \
--allow=TCP:CONTAINER_PORT \
--source-ranges=10.129.0.0/23 \
--network=NETWORK_NAME
CONTAINER_PORT
は、Pod がリッスンしているポートの値(9376
など)に置き換えます。
クラスタを作成する
このセクションでは、内部アプリケーション ロードバランサ用の Ingress で使用できる VPC ネイティブ クラスタを作成します。このクラスタは、Google Cloud CLI または Google Cloud コンソールを使用して作成できます。
gcloud
プロキシ専用サブネットと同じネットワークにクラスタを作成します。
gcloud container clusters create-auto CLUSTER_NAME \
--location=COMPUTE_LOCATION \
--network=NETWORK_NAME
次のように置き換えます。
CLUSTER_NAME
: クラスタの名前。COMPUTE_LOCATION
: クラスタの Compute Engine のロケーション。前のセクションで作成したプロキシ サブネットと同じロケーションを使用する必要があります。
コンソール
Google Cloud コンソールで [Google Kubernetes Engine] ページに移動します。
[add_box 作成] をクリックします。
[Autopilot] セクションで、[構成] をクリックします。
[クラスタの基本] セクションで、次の操作を行います。
- クラスタの名前を [名前] に入力します。
- [ロケーション タイプ] で、クラスタの Compute Engine リージョンを選択します。前のセクションで作成したプロキシ サブネットと同じリージョンを使用する必要があります。
ナビゲーション パネルで [ネットワーキング] をクリックします。
[ネットワーク] リストで、クラスタを作成するネットワークを選択します。このネットワークは、プロキシ サブネットと同じ VPC ネットワーク内のものにする必要があります。
[ノードのサブネット] リストで、作成したプロキシ サブネットを選択します。
[作成] をクリックします。
ウェブ アプリケーションをデプロイする
このセクションでは、Deployment を作成します。
Deployment を作成する方法は次のとおりです。
次のサンプル マニフェストを
web-deployment.yaml
として保存します。apiVersion: apps/v1 kind: Deployment metadata: labels: app: hostname name: hostname-server spec: selector: matchLabels: app: hostname minReadySeconds: 60 replicas: 3 template: metadata: labels: app: hostname spec: containers: - image: registry.k8s.io/serve_hostname:v1.4 name: hostname-server ports: - containerPort: 9376 protocol: TCP terminationGracePeriodSeconds: 90
このマニフェストには、ポート 9376 で HTTPS サーバーでリッスンする Deployment が記述されています。この Deployment ではアプリケーションの Pod も管理されます。各 Pod は、HTTPS サーバーに接続して 1 つのアプリケーション コンテナを実行します。このサーバーは、レスポンスとしてアプリケーション サーバーのホスト名を返します。Pod の名前が Pod のデフォルトのホスト名になります。また、このコンテナでは正常な終了処理も行われます。
マニフェストをクラスタに適用します。
kubectl apply -f web-deployment.yaml
ネットワーク エンドポイント グループ(NEG)として Service をデプロイする
このセクションでは、Service リソースを作成します。この Service はラベルを基準にバックエンド コンテナを選択します。これにより、Ingress コントローラは、選択されたこれらのコンテナをバックエンド エンドポイントとしてプログラムできます。内部アプリケーション ロードバランサ用の Ingress では、バックエンドとして NEG を使用する必要があります。この機能ではインスタンス グループをバックエンドとして使用できません。NEG バックエンドが必要になることから、Ingress を介して公開される Service をデプロイするときには、次の NEG アノテーションを使用する必要があります。
annotations:
cloud.google.com/neg: '{"ingress": true}'
以下のすべての条件が満たされると、Service に自動的に cloud.google.com/neg: '{"ingress": true}'
アノテーションが付けられます。
- VPC ネイティブ クラスタを使用している。
- 共有 VPC を使用していない。
- GKE ネットワーク ポリシーを使用していない。
アノテーションは、neg-annotation.config.common-webhooks.networking.gke.io
という名前の MutatingWebhookConfiguration
によって自動的に追加されます。MutatingWebhookConfiguration
が存在するかどうかは、次のコマンドで確認できます。
kubectl get mutatingwebhookconfigurations
NEG を使用すると、Ingress コントローラがコンテナ ネイティブのロード バランシングを実行できます。トラフィックは、ノード IP または kube-proxy ネットワーキングを移動するのではなく、Ingress プロキシから直接 Pod IP に負荷分散されます。また、Kubernetes の readiness / liveness チェックだけでなく、ロードバランサの観点からも Pod の健全性を判断するために、Pod の readiness ゲートが実装されます。Pod の readiness ゲートにより、Pod の起動、Pod やノードの損失などのライフサイクル イベントでトラフィックが破棄されないよう防ぐことができます。
NEG アノテーションを追加しないと、Ingress オブジェクトに対して警告が返され、内部アプリケーション ロードバランサを構成できなくなります。また、NEG アノテーションが含まれていない場合は、Ingress で Kubernetes イベントが生成されます。次のメッセージは、イベント メッセージの例です。
Message
-------
error while evaluating the ingress spec: could not find port "8080" in service "default/no-neg-svc"
Ingress が Service を参照するまでは NEG は作成されません。Ingress とその参照先の Service の両方が存在するようになるまで、NEG は Compute Engine に表示されません。NEG はゾーンリソースです。マルチゾーン クラスタでは、各ゾーンで Service ごとに 1 つの NEG が作成されます。
Service を作成する方法は次のとおりです。
次のサンプル マニフェストを
web-service.yaml
として保存します。apiVersion: v1 kind: Service metadata: name: hostname namespace: default annotations: cloud.google.com/neg: '{"ingress": true}' spec: ports: - name: host1 port: 80 protocol: TCP targetPort: 9376 selector: app: hostname type: ClusterIP
マニフェストをクラスタに適用します。
kubectl apply -f web-service.yaml
Ingress をデプロイする
このセクションでは、Ingress コントローラを介して Compute Engine ロードバランサのデプロイをトリガーする Ingress リソースを作成します。内部アプリケーション ロードバランサ用の Ingress には、次のアノテーションが必要です。
annotations:
kubernetes.io/ingress.class: "gce-internal"
ingressClassName
フィールドを使用して GKE Ingress を指定することはできません。kubernetes.io/ingress.class
アノテーションを使用する必要があります。詳細については、GKE Ingress コントローラの動作をご覧ください。
Ingress を作成する方法は次のとおりです。
次のサンプル マニフェストを
internal-ingress.yaml
として保存します。apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ilb-demo-ingress namespace: default annotations: kubernetes.io/ingress.class: "gce-internal" spec: defaultBackend: service: name: hostname port: number: 80
マニフェストをクラスタに適用します。
kubectl apply -f internal-ingress.yaml
Ingress が正常にデプロイされたことを検証する
このセクションでは、デプロイが成功したかどうかを検証します。
Ingress リソースが完全にプロビジョニングされるまでに数分かかることがあります。この間に、Ingress コントローラは転送ルール、バックエンド サービス、URL マップ、NEG などのアイテムを作成します。
前のセクションで作成した Ingress リソースのステータスを取得するには、次のコマンドを実行します。
kubectl get ingress ilb-demo-ingress
出力は次のようになります。
NAME HOSTS ADDRESS PORTS AGE
ilb-demo-ingress * 10.128.0.58 80 59s
ADDRESS
フィールドに値が入力されると、Ingress は準備完了になります。このフィールドの RFC 1918 アドレスは、VPC 内の内部 IP であることを意味します。
内部アプリケーション ロードバランサはリージョン ロードバランサであるため、仮想 IP(VIP)には同じリージョンの VPC 内のクライアントからのみアクセスできます。ロードバランサの VIP を取得したら、curl
などのツールを使用して、VPC 内から VIP に対して HTTP GET
呼び出しを発行できます。
HTTP GET
呼び出しを発行するには、次の手順を完了します。
VPC 内から Ingress VIP にアクセスするには、クラスタと同じリージョンとネットワークに VM をデプロイします。
gcloud compute instances create l7-ilb-client \ --image-family=debian-10 \ --image-project=debian-cloud \ --network=NETWORK_NAME \ --subnet=SUBNET_NAME \ --zone=COMPUTE_ZONE \ --tags=allow-ssh
次のように置き換えます。
SUBNET_NAME
: ネットワーク内のサブネットの名前。COMPUTE_ZONE
: リージョン内の Compute Engine ゾーン。
インスタンスの作成方法について詳しくは、VM インスタンスの作成と起動をご覧ください。
VM 内から内部 VIP にアクセスするには、
curl
を使用します。前の手順で作成した VM に SSH 接続します。
gcloud compute ssh l7-ilb-client \ --zone=COMPUTE_ZONE
curl
を使用して内部アプリケーション VIP にアクセスします。curl 10.128.0.58 hostname-server-6696cf5fc8-z4788
成功を示す HTTP レスポンスとバックエンド コンテナのホスト名が返された場合、完全な負荷分散パスが正常に機能しています。
Ingress リソースを削除する
Ingress と Service のリソースを削除すると、関連する Compute Engine のロードバランサ リソースも削除されます。リソースのリークを防ぐため、不要になった Ingress リソースを破棄します。また、クラスタを削除する前に、Ingress リソースと Service リソースを削除する必要があります。そうしないと、Compute Engine 負荷分散リソースが孤立します。
Ingress を削除するには、次の手順を行います。
Ingress を削除します。たとえば、このページで作成した Ingress を削除するには、次のコマンドを実行します。
kubectl delete ingress ilb-demo-ingress
Ingress を削除すると、この Ingress リソースに関連付けられた転送ルール、バックエンド サービス、URL マップが削除されます。
Service を削除します。たとえば、このページで作成した Service を削除するには、次のコマンドを実行します。
kubectl delete service hostname
Service を削除すると、Service に関連付けられている NEG が削除されます。
GKE にアプリケーションをデプロイし、ロードバランスされたプライベート IP アドレスでアプリケーションを公開するには、基本的な内部 Ingress をご覧ください。
静的 IP アドレスの指定
内部 Ingress リソースでは、静的 IP アドレスとエフェメラル IP アドレスの両方がサポートされます。IP アドレスが指定されていなければ、GKE ノードのサブネットから使用可能な IP アドレスが自動的に割り振られます。ただし、Ingress リソースはプロキシ専用サブネットから IP アドレスを取得してプロビジョニングすることはしません。このサブネットは、内部プロキシを使用するためだけに利用されるからです。これらのエフェメラル IP アドレスは、内部 Ingress リソースのライフサイクルに対してのみ Ingress に割り振られます。ただし、Ingress を削除して同じマニフェスト ファイルから新しい Ingress を作成しても、同じ外部 IP アドレスが得られる保証はありません。
内部 Ingress リソースのライフサイクルとは独立した永続的な IP アドレスが必要な場合は、リージョン静的内部 IP アドレスを予約する必要があります。そのうえで、Ingress リソースで kubernetes.io/ingress.regional-static-ip-name
アノテーションを使用して静的 IP アドレスを指定できます。
次の例は、このアノテーションを追加する方法を示しています。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
annotations:
kubernetes.io/ingress.regional-static-ip-name: STATIC_IP_NAME
kubernetes.io/ingress.class: "gce-internal"
STATIC_IP_NAME
は、次の条件を満たす静的 IP 名で置き換えます。
- 静的 IP アドレスを作成してから、Ingress をデプロイします。ロードバランサは、静的 IP が作成されるまではデプロイされません。また、存在しない IP アドレス リソースを参照しても、静的 IP は作成されません。エフェメラル IP アドレスではなく静的 IP アドレスを使用するように既存の Ingress を変更すると、GKE がロードバランサの転送ルールを再作成するときに、ロードバランサの IP アドレスが変更されることがあります。
- 静的 IP は、共有 VPC のサービス プロジェクトにデプロイされた Ingress のサービス プロジェクトで予約されます。
- Google Cloud IP アドレス リソースは、その IP アドレスではなく名前で参照するようにします。
- この IP アドレスは、GKE クラスタと同じリージョン内のサブネットからのものである必要があります。リージョン(プロキシ専用サブネットを除く)内で使用可能なプライベート サブネットを使用できます。Ingress リソースごとに異なるサブネットから取得したアドレスを設定することもできます。
クライアントとロードバランサ間の HTTPS
内部負荷分散用の Ingress は、クライアントへの TLS 証明書の配信をサポートします。TLS 証明書は、Kubernetes Secret または Google Cloud の事前共有リージョン SSL 証明書を通じて提供できます。Ingress リソースごとに複数の証明書を指定することもできます。GKE 1.25 以降では、HTTPS と HTTP の同時使用がサポートされています。この機能を有効にするには、PURPOSE=SHARED_LOADBALANCER_VIP を使用して静的 IP アドレスを作成し、Ingress で構成する必要があります。静的 IP アドレスが指定されていない場合は、HTTPS トラフィックのみが許可されます。HTTP の無効化に関するドキュメントの説明に従ってください。
以下では、Google Cloud で証明書を作成し、Ingress を介して HTTPS および HTTP トラフィックの内部クライアントに配布する方法を説明します。
リージョン証明書を作成します。
gcloud compute ssl-certificates create CERT_NAME \ --certificate CERT_FILE_PATH \ --private-key KEY_FILE_PATH \ --region COMPUTE_REGION
次のように置き換えます。
CERT_NAME
: 選択した証明書の名前。CERT_FILE_PATH
: セルフマネージド証明書を作成するためのローカル証明書ファイルへのパス。証明書は PEM 形式にする必要があります。KEY_FILE_PATH
: ローカル秘密鍵ファイルへのパス。秘密鍵は PEM 形式にして、RSA または ECDSA 暗号化を使用する必要があります。COMPUTE_REGION
: 証明書の Compute Engine リージョン。
静的 IP アドレスの指定の説明に従って、静的 IP アドレスを予約して適用します。
次のサンプル マニフェストを
ingress-pre-shared-cert.yaml
として保存します。apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ilb-demo-ing namespace: default annotations: ingress.gcp.kubernetes.io/pre-shared-cert: "CERT_NAME" kubernetes.io/ingress.regional-static-ip-name: STATIC_IP_NAME kubernetes.io/ingress.class: "gce-internal" spec: rules: - host: DOMAIN http: paths: - pathType: ImplementationSpecific backend: service: name: SERVICE_NAME port: number: 80
次のように置き換えます。
DOMAIN
: ご利用のドメイン。CERT_NAME
: 前のセクションで作成した証明書の名前。SERVICE_NAME
: Service の名前。
マニフェストをクラスタに適用します。
kubectl apply -f ingress-pre-shared-cert.yaml
ロードバランサとアプリケーション間の HTTPS
アプリケーションが GKE Pod で実行され、HTTPS リクエストを受信できる場合は、ロードバランサがリクエストをアプリケーションに転送する際に HTTPS を使用するようにロードバランサを構成できます。詳しくは、ロードバランサとアプリケーション間の HTTPS(TLS)をご覧ください。
共有 VPC
NEG アノテーションを手動で追加する
Ingress リソースをデプロイする GKE が共有 VPC サービス プロジェクトにある場合、サービスへのアノテーションの追加を担当する MutatingWebhookConfiguration
がインストールされていないため、サービスにはアノテーション cloud.google.com/neg: '{"ingress": true}'
が自動的に付与されません。
内部アプリケーション ロードバランサ用の Ingress で公開される Service のマニフェストに NEG アノテーションを追加する必要があります。
VPC ファイアウォール ルール
Ingress リソースをデプロイする GKE クラスタが共有 VPC サービス プロジェクトにあり、GKE コントロール プレーンでホスト プロジェクトのファイアウォール リソースを管理する場合は、共有 VPC を使用したクラスタのファイアウォール リソースの管理で説明されているとおり、サービス プロジェクトの GKE サービス アカウントに、ホスト プロジェクトでの適切な IAM 権限が付与されている必要があります。これにより、Ingress コントローラは Google Cloud ヘルスチェックの上り(内向き)トラフィックを許可するファイアウォール ルールを作成できます。
以下に、Ingress リソースログに存在する可能性があるイベントの例を示します。このエラーは、権限が正しく構成されていないときに、Ingress コントローラが Google Cloud ヘルスチェックの上り(内向き)トラフィックを許可するファイアウォール ルールを作成できない場合に発生します。
Firewall change required by security admin: `gcloud compute firewall-rules update <RULE_NAME> --description "GCE L7 firewall rule" --allow tcp:<PORT> --source-ranges 130.211.0.0/22,35.191.0.0/16 --target-tags <TARGET_TAG> --project <HOST_PROJECT>
ホスト プロジェクトからファイアウォール ルールを手動でプロビジョニングする場合は、Ingress リソースに networking.gke.io/suppress-firewall-xpn-error: "true"
アノテーションを追加することで firewallXPNError
イベントをミュートできます。
内部 Ingress アノテーションの概要
次の表は、内部アプリケーション ロードバランサ用の Ingress に Ingress リソースと Service リソースを作成するときに追加できるアノテーションを示しています。
Ingress アノテーション
アノテーション | 説明 |
---|---|
kubernetes.io/ingress.class |
内部 Ingress には "gce-internal" として設定できます。クラスが指定されていない場合、Ingress リソースはデフォルトで外部 Ingress として解釈されます。詳細については、GKE Ingress コントローラの動作をご覧ください。 |
kubernetes.io/ingress.allow-http |
クライアントと HTTP(S) ロードバランサ間の HTTP トラフィックを許可できます。有効な値は true と false です。デフォルト値は true です。詳しくは、HTTP の無効化をご覧ください。 |
ingress.gcp.kubernetes.io/pre-shared-cert |
証明書と鍵を Google Cloud プロジェクトにアップロードできます。このアノテーションを使用して証明書と鍵を参照します。詳細については、外部アプリケーション ロードバランサでの複数の SSL 証明書の使用をご覧ください。 |
networking.gke.io/suppress-firewall-xpn-error |
GLBC 1.4 以降では、
|
kubernetes.io/ingress.regional-static-ip-name |
静的 IP アドレスを指定して、内部 Ingress リソースをプロビジョニングできます。詳細については、静的 IP アドレスの指定をご覧ください。 |
Ingress に関連する Service アノテーション
アノテーション | 説明 |
---|---|
cloud.google.com/backend-config |
このアノテーションを使用して、servicePort に関連付けられるバックエンド サービスを構成します。詳細については、Ingress の構成をご覧ください。 |
cloud.google.com/neg |
このアノテーションを使用して、ロードバランサがネットワーク エンドポイント グループを使用するように指定します。詳しくは、コンテナ ネイティブの負荷分散を使用するをご覧ください。 |
トラブルシューティング
通常、Ingress の状態を把握および監視するには、Ingress に関連付けられているリソースの検査が必要になります。よく発生する問題としては、負荷分散リソースが適切に作成されない、トラフィックがバックエンドに到達しない、バックエンドが正常な状態でないといった問題が挙げられます。
一般的なトラブルシューティングの手順は次のとおりです。
- クライアント トラフィックがロードバランサと同じリージョンおよび VPC 内から送信されていることを確認します。
- Pod とバックエンドが正常な状態であることを確認します。
- VIP へのトラフィック パスを確認します。Compute Engine ヘルスチェックの場合は、そのパスがファイアウォール ルールでブロックされていないことを確認します。
- Ingress リソース イベントのエラーを確認します。
- Ingress リソースの説明を参照して、Compute Engine リソースとのマッピングを確認します。
- Compute Engine 負荷分散リソースが存在し、正しく構成されていて、エラーが報告されていないことを確認します。
Ingress イベントのフィルタリング
次のクエリを実行すると、クラスタ内のすべての Ingress イベントを対象にエラーをフィルタリングできます。
kubectl get events --all-namespaces --field-selector involvedObject.kind=Ingress
オブジェクトまたはオブジェクト名を基準にフィルタリングすることもできます。
kubectl get events --field-selector involvedObject.kind=Ingress,involvedObject.name=hostname-internal-ingress
次のエラーは、Ingress によって参照されている Service が存在しないことを示しています。
LAST SEEN TYPE REASON OBJECT MESSAGE
0s Warning Translate ingress/hostname-internal-ingress error while evaluating the ingress spec: could not find service "default/hostname-invalid"
Compute Engine ロードバランサ リソースの検査
次のコマンドを実行すると、Ingress リソースの完全な出力が表示されます。これにより、Ingress コントローラによって作成された Compute Engine リソースへのマッピングを確認できます。
kubectl get ing INGRESS_FILENAME -o yaml
INGRESS_FILENAME
を Ingress リソースのファイル名に置き換えます。
出力は次のようになります。
apiVersion: v1
items:
- apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
ingress.kubernetes.io/backends: '{"k8s1-241a2b5c-default-hostname-80-29269aa5":"HEALTHY"}'
ingress.kubernetes.io/forwarding-rule: k8s-fw-default-ilb-demo-ingress--241a2b5c94b353ec
ingress.kubernetes.io/target-proxy: k8s-tp-default-ilb-demo-ingress--241a2b5c94b353ec
ingress.kubernetes.io/url-map: k8s-um-default-ilb-demo-ingress--241a2b5c94b353ec
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"networking.k8s.io/v1","kind":"Ingress","metadata":{"annotations":{"kubernetes.io/ingress.class":"gce-internal"},"name":"ilb-demo-ingress","namespace":"default"},"spec":{"defaultBackend":{"service":{"name":"hostname"},"port":{"number":80}}}}
kubernetes.io/ingress.class: gce-internal
creationTimestamp: "2019-10-15T02:16:18Z"
finalizers:
- networking.gke.io/ingress-finalizer
generation: 1
name: ilb-demo-ingress
namespace: default
resourceVersion: "1538072"
selfLink: /apis/networking.k8s.io/v1/namespaces/default/ingresses/ilb-demo-ingress
uid: 0ef024fe-6aea-4ee0-85f6-c2578f554975
spec:
defaultBackend:
service:
name: hostname
port:
number: 80
status:
loadBalancer:
ingress:
- ip: 10.128.0.127
kind: List
metadata:
resourceVersion: ""
selfLink: ""
ingress.kubernetes.io/backends
アノテーションには、バックエンドとそのステータスの一覧が表示されています。バックエンドが HEALTHY
になっていることを確認します。
Ingress で作成された Compute Engine リソースの場合は、直接クエリを送信してステータスと構成を確認できます。トラブルシューティングでも、これらのクエリを実行すると役立ちます。
Compute Engine 転送ルールの一覧を取得するには:
gcloud compute forwarding-rules list
出力は次のようになります。
NAME REGION IP_ADDRESS IP_PROTOCOL TARGET
k8s-fw-default-hostname-internal-ingress--42084f6a534c335b REGION_NAME 10.128.15.225 TCP REGION_NAME/targetHttpProxies/k8s-tp-default-hostname-internal-ingress--42084f6a534c335b
バックエンド サービスの状態を一覧表示するには、まずバックエンド サービスを一覧表示し、検査するバックエンド サービスの名前をコピーします。
gcloud compute backend-services list
出力は次のようになります。
NAME BACKENDS PROTOCOL
k8s1-42084f6a-default-hostname-80-98cbc1c1 REGION_NAME/networkEndpointGroups/k8s1-42084f6a-default-hostname-80-98cbc1c1 HTTP
これで、バックエンド サービス名を使用してヘルスチェックのクエリを実行できます。
gcloud compute backend-services get-health k8s1-42084f6a-default-hostname-80-98cbc1c1 \
--region COMPUTE_REGION
COMPUTE_REGION
は、バックエンド サービスの Compute Engine リージョンに置き換えます。
出力は次のようになります。
backend: https://www.googleapis.com/compute/v1/projects/user1-243723/zones/ZONE_NAME/networkEndpointGroups/k8s1-42084f6a-default-hostname-80-98cbc1c1
status:
healthStatus:
- healthState: HEALTHY
次のステップ
外部アプリケーション ロードバランサ用の GKE Ingress について学習する。
GKE における Service のコンセプトの概要を確認する。
GKE で内部パススルー ネットワーク ロードバランサを作成する方法を学習する。
基本的な内部 Ingress を実装する。