VPC クラスタでの IP アドレス管理のトラブルシューティング

このセクションでは、VPC ネイティブ クラスタに関連する問題を解決するためのガイダンスを示します。GKE IP アドレスの使用率の分析情報を表示することもできます。

デフォルトのネットワーク リソースの準備ができていない

現象

次のようなエラー メッセージが表示されます。

projects/[PROJECT_NAME]/regions/XXX/subnetworks/default
考えられる原因

同じサブネット上に並列オペレーションがあります。たとえば、別の VPC ネイティブ クラスタが作成されている、サブネット上でセカンダリ範囲の追加または削除が行われている、などです。

解決策

コマンドを再試行します。

IPCidrRange が無効な値である

現象

次のようなエラー メッセージが表示されます。

resource.secondaryIpRanges[1].ipCidrRange': 'XXX'. Invalid IPCidrRange: XXX conflicts with existing subnetwork 'default' in region 'XXX'
考えられる原因

別の VPC ネイティブ クラスタが同時に作成されていて、同じ VPC ネットワークの同じ範囲を割り振ろうとしています。

同じセカンダリ範囲が同じ VPC ネットワークのサブネットワークに追加されようとしています。

解決策

セカンダリ範囲がまだ指定されていない状態でクラスタ作成コマンドを実行して、このエラーが返された場合は、しばらくしてからクラスタの作成コマンドを再試行してください。

Pod 用の空き IP アドレス空間が不足している

現象

クラスタが長い時間プロビジョニング状態で停止しています。

クラスタの作成時にマネージド インスタンス グループ（MIG）エラーが返されます。

1 つ以上のノードをクラスタに追加すると、次のエラーが表示されます。

[IP_SPACE_EXHAUSTED] Instance 'INSTANCE_NAME' creation failed: IP space of 'projects/PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME-SECONDARY_RANGE_NAME' is exhausted.
考えられる原因

ノードの IP アドレスの枯渇: クラスタに割り当てられたサブネットのプライマリ IP アドレス範囲で使用可能な IP アドレスが不足しています。これは通常、ノードプールのスケーリング時や大規模なクラスタの作成時に発生します。

Pod IP アドレスの枯渇: クラスタに割り当てられた Pod CIDR 範囲がいっぱいです。これは、Pod の数が Pod CIDR の容量を超えた場合に発生します。特に、ノードあたりの Pod 密度が高い場合や、大規模なデプロイの場合に発生します。

サブネットの特定の命名規則: エラー メッセージ内のサブネットの命名方法は、問題がノード IP アドレス範囲（ノード自体が IP アドレスを取得する場所）に関するものであるか、Pod IP アドレス範囲（Pod 内のコンテナが IP アドレスを取得する場所）に関するものであるかを確認するのに役立ちます。

セカンダリ範囲の枯渇（Autopilot）: Autopilot クラスタでは、Pod IP アドレスに割り当てられたセカンダリ範囲が、スケーリングまたは高密度の Pod が原因で枯渇します。

解決策

クラスタの名前、コントロール プレーンのバージョン、オペレーション モード、関連付けられた VPC 名、サブネット名、CIDR などの情報を収集します。また、デフォルトおよび追加のクラスタ Pod の IPv4 範囲（名前と CIDR を含む）、VPC ネイティブ トラフィック ルーティングが有効になっているかどうか、クラスタレベルとノードプール レベルの両方で設定されているノードあたりの Pod の最大数（該当する場合）を確認します。影響を受けるノードプールと、それらの特定の IPv4 Pod の IP アドレス範囲とノードあたりの Pod の最大構成（クラスタ全体の設定と異なる場合）を確認します。また、ノードプール構成で、ノードあたりの最大 Pod 数のデフォルト構成とカスタム構成（存在する場合）を記録します。

IP アドレスの枯渇に関する問題を確認する

  • Network Intelligence Center: GKE クラスタの Network Intelligence Center で Pod の IP アドレス範囲の IP アドレス割り振り率が高いかどうかを確認します。

    Network Intelligence Center 内の Pod 範囲で IP アドレスの割り振り率が高い場合は、Pod の IP アドレス範囲が枯渇しています。

    Pod の IP アドレス範囲に通常の割り振り率が表示されているにもかかわらず、IP アドレスの枯渇が引き続き発生している場合は、ノードの IP アドレス範囲が枯渇している可能性があります。

  • 監査ログ: IP_SPACE_EXHAUSTED エントリの resourceName フィールドを調べて、サブネット名またはセカンダリ Pod の IP アドレス範囲名と比較します。

  • 枯渇した IP アドレス範囲がノードの IP アドレス範囲か Pod の IP アドレス範囲かを確認します。

    枯渇した IP アドレス範囲がノードの IP アドレス範囲か Pod の IP アドレス範囲かを確認するには、IP_SPACE_EXHAUSTED ログエントリの ipSpaceExhausted 部分にある resourceName の値が、影響を受ける GKE クラスタで使用されている Pod のサブネット名またはセカンダリ IPv4 アドレス範囲の名前と関連付けられているかどうかを確認します。

    resourceName の値が「[Subnet_name]」形式の場合、ノードの IP アドレス範囲が枯渇しています。resourceName の値が「[Subnet_name]-[Name_of_Secondary_IPv4_range_for_pods]-[HASH_8BYTES]」形式の場合、Pod の IP アドレス範囲が枯渇しています。

Pod の IP アドレスの枯渇を解決します。

  • 既存の Pod CIDR のサイズを変更する: 現在の Pod の IP アドレス範囲のサイズを増やします。連続していないマルチ Pod CIDR を使用して、Pod IP 範囲をクラスタに追加できます。
  • 追加のサブネットを作成する: 専用の Pod CIDR を持つサブネットをクラスタに追加します。

IP アドレスを解放するために、ノードあたりの Pod 数を減らします。

ノードの IP アドレスの枯渇を解決します。

  • IP アドレスの計画を確認する: ノードの IP アドレス範囲がスケーリング要件と一致していることを確認します。
  • 新しいクラスタを作成する（必要な場合）: ノードの IP アドレス範囲が厳しく制約されている場合は、適切な IP アドレス範囲のサイズを持つ代替クラスタを作成します。VPC ネイティブ クラスタの IP 範囲と IP 範囲の計画をご覧ください。

gcpdiag を使用して IP アドレスの枯渇に関する問題をデバッグする

gcpdiag はオープンソース ツールです。正式にサポートされている Google Cloud プロダクトではありません。gcpdiag ツールを使用すると、Google Cloud プロジェクトの問題を特定して修正できます。詳細については、GitHub の gcpdiag プロジェクトをご覧ください。

Autopilot クラスタと Standard GKE クラスタで IP アドレスの枯渇が発生する原因を調べるには、次の点に注意してください。
  • クラスタのステータス: IP アドレスの枯渇が報告された場合、クラスタのステータスを確認します。
  • ネットワーク アナライザ: ネットワーク アナライザのログに対して Stackdriver ログにクエリを実行し、Pod またはノードの IP アドレスが枯渇していないかどうかを確認します。
  • クラスタタイプ: クラスタタイプを確認し、クラスタタイプに基づいて関連する推奨事項を提供します。

Google Cloud コンソール

  1. 次のコマンドを入力してコピーします。
    2. GOOGLE_AUTH_TOKEN=GOOGLE_AUTH_TOKEN \
  gcpdiag runbook gke/ip-exhaustion \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=ZONE|REGION \
    --parameter start_time=yyyy-mm-ddThh:mm:ssZ \
    --parameter end_time=yyyy-mm-ddThh:mm:ssZ \ \
    --auto --reason=REASON
  2. Google Cloud コンソールを開き、Cloud Shell をアクティブにします。
    3. Cloud コンソールを開く
  3. コピーしたコマンドを貼り付けます。
  4. gcpdiag コマンドを実行します。gcpdiag Docker イメージがダウンロードされ、診断チェックが実行されます。必要に応じて、出力の指示に沿って、失敗したチェックを修正します。

Docker

Docker コンテナで gcpdiag を起動するラッパーを使用して gcpdiag を実行できます。Docker または Podman がインストールされている必要があります。

  1. ローカル ワークステーションで次のコマンドをコピーして実行します。 
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. gcpdiag コマンドを実行します。 
    ./gcpdiag runbook gke/ip-exhaustion \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=ZONE|REGION \
    --parameter start_time=yyyy-mm-ddThh:mm:ssZ \
    --parameter end_time=yyyy-mm-ddThh:mm:ssZ \

このランブックで使用可能なパラメータを表示します。

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

  • PROJECT_ID: リソースを含むプロジェクトの ID。
  • CLUSTER_NAME: プロジェクト内のターゲット GKE クラスタの名前。
  • LOCATION: クラスタが配置されているゾーンまたはリージョン。
  • start_time: 問題が発生した時刻。
  • end_time: 問題が終了した時刻。問題が継続している場合は、現在の時刻を設定します。

有用なフラグ:

gcpdiag ツールのフラグの一覧と説明については、gcpdiag の使用手順をご覧ください。

デフォルトの SNAT が無効になっているかどうか確認する

デフォルトの SNAT のステータスを確認するには、次のコマンドを使用します。

gcloud container clusters describe CLUSTER_NAME

CLUSTER_NAME は、使用するクラスタの名前に置き換えます。

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

networkConfig:
  disableDefaultSnat: true
  network: ...

--enable-ip-alias なしで --disable-default-snat は使用できない

このエラー メッセージと must disable default sNAT (--disable-default-snat) before using public IP address privately in the cluster が表示された場合、限定公開クラスタでパブリック IP アドレスが使用されているため、クラスタの作成時に --disable-default-snat フラグを明示的に設定する必要があります。

cannot disable default sNAT ... などのエラー メッセージが表示された場合、クラスタでデフォルトの SNAT を無効にすることはできません。この問題を解決するには、クラスタの構成を確認します。

デフォルトの SNAT を無効にして Cloud NAT をデバッグする

--disable-default-snat フラグを使用して限定公開クラスタを作成し、インターネット アクセスに Cloud NAT を設定しているときに、Pod からインターフェースに向かうトラフィックが表示されない場合は、Cloud NAT 構成に Pod の範囲が含まれていることを確認します。

Pod 間の通信に問題がある場合は、ノードの iptables ルールを調べて、Pod 範囲が iptables ルールによってマスカレードされていないことを確認します。

詳細については、GKE IP マスカレードのドキュメントをご覧ください。

クラスタに IP マスカレード エージェントが構成されていない場合、GKE は Pod 間の通信が自動的にマスカレードされないようにします。IP マスカレード エージェントが構成されている場合は、デフォルトの IP マスカレード ルールがオーバーライドされます。Pod 範囲のマスカレードを無視するように、IP マスカレード エージェントで追加のルールが構成されていることを確認します。

デュアルスタック クラスタのネットワーク通信が想定どおりに機能していない

考えられる原因
GKE クラスタによって作成されたファイアウォール ルールに、割り振られた IPv6 アドレスが含まれていません。
解決策
次の手順でファイアウォール ルールを検証できます。

  1. ファイアウォール ルールの内容を確認します。

    gcloud compute firewall-rules describe FIREWALL_RULE_NAME

    FIREWALL_RULE_NAME の部分は、ファイアウォール ルールの名前に置き換えます。

    各デュアルスタック クラスタは、ノードと Pod が相互に通信できるようにするファイアウォール ルールを作成します。ファイアウォール ルールの内容は、次のようになります。

    allowed:
- IPProtocol: esp
- IPProtocol: ah
- IPProtocol: sctp
- IPProtocol: tcp
- IPProtocol: udp
- IPProtocol: '58'
creationTimestamp: '2021-08-16T22:20:14.747-07:00'
description: ''
direction: INGRESS
disabled: false
enableLogging: false
id: '7326842601032055265'
kind: compute#firewall
logConfig:
  enable: false
name: gke-ipv6-4-3d8e9c78-ipv6-all
network: https://www.googleapis.com/compute/alpha/projects/my-project/global/networks/alphanet
priority: 1000
selfLink: https://www.googleapis.com/compute/alpha/projects/my-project/global/firewalls/gke-ipv6-4-3d8e9c78-ipv6-all
selfLinkWithId: https://www.googleapis.com/compute/alpha/projects/my-project/global/firewalls/7326842601032055265
sourceRanges:
- 2600:1900:4120:fabf::/64
targetTags:
- gke-ipv6-4-3d8e9c78-node

    sourceRanges 値は subnetIpv6CidrBlock と同じである必要があります。targetTags 値は GKE ノードのタグと同じである必要があります。この問題を解決するには、クラスタの ipAllocationPolicy ブロックの情報を使用して、ファイアウォール ルールを更新します。

次のステップ

  • Kubernetes DNS の問題の診断に関する一般的な情報については、DNS 解決のデバッグをご覧ください。