Ingress for Anthos のトラブルシューティングとオペレーション

Anthos Ingress コントローラは、Compute Engine リソースを管理します。MultiClusterIngress(MCI)リソースと MultiClusterService(MCS)リソースは別々の Compute Engine リソースにマッピングされるため、これらのリソースの関係を理解するとトラブルシューティングに役立ちます。たとえば、次の MCI リソースを調べます。

apiVersion: extensions/v1beta1
kind: MultiClusterIngress
metadata:
  name: foo-ingress
spec:
  rules:
  - host: store.foo.com
    http:
      paths:
      - backend:
          serviceName: store-foo
          servicePort: 80
  - host: search.foo.com
    http:
      paths:
      - backend:
          serviceName: search-foo
          servicePort: 80

Compute Engine から Ingress for Anthos へのリソース マッピング

次の表には、Kubernetes クラスタと Google Cloud で作成されたリソースへの Environ リソースのマッピングが示されています。

Kubernetes リソース Google Cloud リソース 説明
MultiClusterIngress 転送ルール HTTP(S) ロードバランサの VIP。
ターゲット プロキシ アノテーションと TLS ブロックから取得した HTTP/S 終端設定。
URL マップ ルール セクションからの仮想ホストパス マッピング。
MultiClusterService Kubernetes Service テンプレートから派生したリソース。
バックエンド サービス (Service、ServicePort)ペアごとにバックエンド サービスが作成されます。
ネットワーク エンドポイント グループ Service に参加するバックエンド Pod のセット。

次の図は、2 つのメンバー クラスタにまたがる MCI / MCS ロードバランサ リソースと Compute Engine ロードバランサ リソースの関係を示しています。

MCI / MCS ロードバランサの関係

Compute Engine ロードバランサ リソースの検査

ロードバランサを作成すると、Ingress のステータスには、ロードバランサを構築するために作成されたすべての Compute Engine リソースの名前が含まれます。例:

Name:         shopping-service
Namespace:    prod
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1beta1
Kind:         MultiClusterIngress
Metadata:
  Creation Timestamp:  2019-07-16T17:23:14Z
  Finalizers:
    mci.finalizer.networking.gke.io
Spec:
  Template:
    Spec:
      Backend:
        Service Name:  shopping-service
        Service Port:  80
Status:
  VIP:  34.102.212.68
  CloudResources:
    Firewalls: "mci-l7"
    ForwardingRules: "mci-abcdef-myforwardingrule"
    TargetProxies: "mci-abcdef-mytargetproxy"
    UrlMap: "mci-abcdef-myurlmap"
    HealthChecks: "mci-abcdef-80-myhealthcheck"
    BackendServices: "mci-abcdef-80-mybackendservice"
    NetworkEndpointGroups: "k8s1-neg1", "k8s1-neg2", "k8s1-neg3"

VIP が作成されません

VIP が表示されない場合は、作成中にエラーが発生した可能性があります。エラーが発生したかどうかを確認するには、次のコマンドを実行します。

kubectl describe mci shopping-service

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

Name:         shopping-service
Namespace:    prod
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1beta1
Kind:         MultiClusterIngress
Metadata:
  Creation Timestamp:  2019-07-16T17:23:14Z
  Finalizers:
    mci.finalizer.networking.gke.io
Spec:
  Template:
    Spec:
      Backend:
        Service Name:  shopping-service
        Service Port:  80
Status:
  VIP:  34.102.212.68
Events:
  Type     Reason  Age   From                              Message
  ----     ------  ----  ----                              -------
  Warning  SYNC    29s   multi-cluster-ingress-controller  error translating MCI prod/shopping-service: exceeded 4 retries with final error: error translating MCI prod/shopping-service: multiclusterservice prod/shopping-service does not exist

この例では、ユーザーが MultiClusterIngress によって参照された MultiClusterService リソースを作成しなかったためにエラーが発生しています。

多くの場合、エラー メッセージは根本的な問題を示します。該当しない場合は、gke-mci-feedback@google.com までお問い合わせください。

502 レスポンス

ロードバランサが VIP を取得したが、一貫して 502 レスポンスを送信している場合、ロードバランサのヘルスチェックが失敗している可能性があります。ヘルスチェックが失敗する原因は 2 つあります。

  1. アプリケーションの Pod が正常ではありません(サンプルについては、Cloud Console のデバッグを参照)。
  2. 正しく構成されていないファイアウォールは、Google Health Checker のヘルスチェックをブロックします。

1 の場合、アプリケーションが「/」パスで 200 のレスポンスを実際に送信しているかを確認します。

2 の場合は、「mci-default-l7」という名前のファイアウォールが VPC にあることを確認します。Ingress コントローラは VPC 内にファイアウォールを作成して、Google Health Checker がバックエンドに到達できるようにします。ファイアウォールが存在しない場合は、作成時にこのファイアウォールを削除する外部自動化機能がないことを確認します。

クラスタへのトラフィックの追加、またはクラスタからのトラフィックの削除

新しいメンバーシップを追加するとき、該当する場合は、基盤となるクラスタのバックエンドにトラフィックが届きます。同様に、メンバーシップが削除されても、基盤となるクラスタのバックエンドにトラフィックは届きません。この動作が見られない場合は、MultiClusterIngress リソースと MultiClusterService リソースにエラーがないか確認してください。

このエラーが発生しがちなケースには、VPC ネイティブ モードではない GKE クラスタに新しいメンバーシップを追加した場合や、GKE クラスタにアプリケーションをデプロイしないで新しいメンバーシップを追加した場合が含まれます。

  1. MultiClusterService を記述します。

    kubectl describe mcs zone-svc
    
  2. MultiClusterIngress を記述します。

    kubectl describe mci zone-mci
    

上記のコマンドでエラーが表示されない場合は、gke-mci-feedback@google.com までお問い合わせください。

構成クラスタの移行

移行のユースケースの詳細については、構成クラスタの設計コンセプトをご覧ください。

構成クラスタの移行は、正しく処理されないと中断される可能性があります。構成クラスタを移行する場合は、次のガイドラインに従ってください。

  1. MCI リソースで必ず静的 IP アノテーションを使用してください。そうしないと、移行中にトラフィックが中断されます。エフェメラル IP は構成クラスタの移行時に再作成されます。
  2. MultiClusterIngress リソースと MultiClusterService リソースは、既存の構成クラスタと新しい構成クラスタに対して同じようにデプロイする必要があります。これらに相違があると、新しい構成クラスタでの異なる MCS リソースと MCI リソースが調整されます。
  3. 常に 1 つの構成クラスタのみがアクティブになります。構成クラスタが変更されるまで、新しい構成クラスタ内の MCI リソースと MCS リソースはロードバランサ リソースに影響しません。

構成クラスタを移行するには、次のコマンドを実行します。

  gcloud alpha container hub ingress update \
    --config-membership=projects/project_id/locations/global/memberships/new_config_cluster

機能の状態に目に見えるエラーがないことを確認して、コマンドが機能したことを確認します。

  gcloud alpha container hub ingress describe

コンソールのデバッグ

ほとんどの場合、ロードバランサの正確なステータスを確認すると、問題をデバッグするときに役立ちます。ロードバランサを確認するには、Google Cloud Console で [負荷分散] に移動します。

エラー / 警告コード

Ingress for Anthos では、MCI リソースと MCS リソースに関するエラーコードと警告コード、既知の問題に対する gcloud multiclusteringress の説明フィールドが出力されます。これらのメッセージにはエラーや警告のコードが記載されており、正常に動作しない場合に何を意味するかを理解しやすくなります。各コードは、AVMBR123 という形式のエラー ID で構成されます。123 は、エラーまたは警告に対応する一意の番号と、解決方法の提案です。

AVMBR101: 「アノテーション [NAME] を認識できません」

このエラーは、認識されない MCI / MCS 仕様でアノテーションが指定されている場合に表示されます。アノテーションが認識されない理由はいくつかあります。

  1. アノテーションが Ingress for Anthos ではサポートされていない。これは、Anthos Ingress コントローラによって使用されることが想定されていないリソースにアノテーションを付ける場合が想定されます。

  2. アノテーションはサポートされているものの、スペルが間違っているため認識されない。

どちらの場合も、サポートされているアノテーションとその指定方法を理解するために、ドキュメントをご覧ください。

AVMBR102: 「[RESOURCE_NAME] 見つかりません」

このエラーは、MCI で補助リソースが指定されているものの、構成メンバーシップで見つからない場合に表示されます。たとえば、不明な MCS を MCI で参照している場合や、不明な BackendConfig を MCS で参照している場合に、このエラーがスローされます。リソースが見つからなかった理由はいくつかあります。

  1. 適切な名前空間にない。相互に参照しているリソースがすべて同じ名前空間にあることを確認します。
  2. リソース名のスペルが間違っている。
  3. 適切な名前空間と名前のリソースが存在しない。この場合は、作成してください。

AVMBR103: 「[CLUSTER_SELECTOR] が無効です」

このエラーは、MCS で指定されたクラスタ セレクタが無効な場合に表示されます。このセレクタが無効になる理由はいくつかあります。

  1. 指定された文字列に入力ミスがある。
  2. 指定された文字列が、Environ に存在していないメンバーシップを参照している。

AVMBR104: 「サービスポート [SERVICE_PORT] の NEG が見つかりません」

このエラーは、特定の MultiClusterService とサービスポートのペアに対する NetworkEndpointGroup(NEG)が見つからない場合にスローされます。NEG は、各バックエンド クラスタの Pod エンドポイントが含まれるリソースです。NEG が存在しない主な理由は、バックエンド クラスタで派生 Service を作成または更新する際にエラーが発生したためです。詳細については、MultiClusterService リソースのイベントをご覧ください。

AVMBR105: 「Anthos ライセンスが存在しません」

このエラーは機能の状態の下に表示され、Anthos API(anthos.googleapis.com)が有効になっていないことを示します。

AVMBR106: 「派生サービスが無効です: [REASON]」

このエラーは、MultiClusterService リソースのイベントの下に表示されます。このエラーの一般的な理由の 1 つとして、MultiClusterService から派生した Service リソースの仕様が無効であることが挙げられます。

たとえば、この MultiClusterService では、その仕様で定義されている ServicePort が定義されていません。

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: zone-mcs
  namespace: zoneprinter
spec:
  clusters:
  - link: "us-central1-a/gke-us"
  - link: "europe-west1-c/gke-eu"

このエラーは、機能の状態の下に表示されます。これは、Membership リソースの基礎となる GKE クラスタがないためです。これを検証するには、以下のコマンドを実行します。

gcloud container hub memberships describe membership-name

次に、エンドポイント フィールドの下に GKE クラスタのリソースリンクがないことを確認します。

AVMBR108: 「GKE クラスタ [NAME] が見つかりません」

このエラーは、機能の状態の下に表示されます。メンバーシップの基盤となる GKE クラスタが存在しない場合、スローされます。

AVMBR109: 「[NAME] は VPC ネイティブの GKE クラスタではありません」

このエラーは、機能の状態の下に表示されます。このエラーは、指定した GKE クラスタがルートベース クラスタである場合にスローされます。Ingress for Anthos コントローラは、NEG を使用してコンテナ ネイティブのロードバランサを作成します。コンテナ ネイティブのロードバランサを使用するには、クラスタが VPC ネイティブである必要があります。

詳細については、VPC ネイティブ クラスタの作成をご覧ください。

AVMBR110: 「GKE クラスタ [NAME] に [IAM PERMISSION] 権限がありません」

このエラーは、機能の状態の下に表示されます。このエラーには、以下の 2 つの原因が考えられます。

  1. メンバーシップの基盤となる GKE クラスタが、メンバーシップ自体とは別のプロジェクトに存在する。
  2. 指定された IAM 権限が MultiClusterIngress サービス エージェントから削除された。

AVMBR111: 「構成メンバーシップを取得できませんでした: [REASON]」

このエラーは、機能の状態の下に表示されます。このエラーの主な理由は、この機能が有効になっている間に構成メンバーシップが削除されたためです。

構成メンバーシップを削除する必要はありません。変更する場合は、構成クラスタの移行手順に従ってください。

AVMBR112: 「HTTPLoadBalancing Addon が GKE クラスタ [NAME] で無効になっています」

このエラーは機能の状態の下に表示され、GKE クラスタで HTTPLoadBalancing アドオンが無効になっている場合に発生します。GKE クラスタを更新して HTTPLoadBalancing アドオンを有効にできます。

gcloud container clusters update name --update-addons=HttpLoadBalancing=ENABLED

AVMBR113: 「このリソースは孤立しています」

あるリソースの有用性が、別のリソースからの参照が前提となっている場合があります。このエラーは、Kubernetes リソースが作成されたが、別のリソースから参照されていない場合にスローされます。たとえば、MultiClusterService によって参照されていない BackendConfig リソースを作成すると、このエラーが表示されます。