GKE ネットワークの一般的な問題とトラブルシューティング

※この投稿は米国時間 2024 年 7 月 4 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Kubernetes Engine（GKE）は、コンテナ化されたアプリケーションをオーケストレートするための、パワフルでスケーラブルな手法です。しかし、他の分散システムと同様に、ネットワークが複雑になるにつれ、接続性の問題が生じる可能性があります。このブログ投稿では、GKE ネットワークの一般的な問題を掘り下げ、問題に対処するための詳細なトラブルシューティングの手順について説明します。

以下は、GKE 接続に関してよく見られる一般的な問題です。

GKE クラスタのコントロール プレーンへの接続に関する問題

GKE クラスタ内の Pod やノードが、おそらくネットワーク問題が原因となり、コントロール プレーンのエンドポイントにアクセスできない。  

内部の GKE 通信

• Pod が、同じ VPC 内の他の Pod またはサービスにアクセスできません。GKE クラスタ内の各 Pod は、一意の IP アドレスを取得します。クラスタ内の Pod 間の接続が中断され、アプリケーションの機能に影響を与える可能性があります。

• ノードが Pod にアクセスできません（またはその逆）。1 つのノードは複数の Pod をホストでき、1 つの GKE クラスタは複数のノードを持つことができます。これによってアプリケーションのワークロードを分散し、スケーラビリティと信頼性を確立します。ネットワークの問題により、自身がホストしている Pod にノードが通信できなくなることがあります。

外部通信に関する問題

• Pod がインターネット上のサービスにアクセスできません。インターネット接続の問題により、Pod が外部の API、データベース、またはその他のリソースにアクセスできないことがあります。

• 外部サービスが Pod にアクセスできません。GKE ロードバランサを介して公開されたサービスが、クラスタの外部からアクセスできない場合があります。

クラスタ VPC を超えた通信

• Pod が他の VPC 内のリソースにアクセスできません。Pod が別の VPC 内のサービスにアクセスしようとする場合（同じプロジェクト内、または VPC ピアリングを介して）、接続に関する問題が発生することがあります。

• Pods がオンプレミスのリソースにアクセスできません。GKE クラスタが自社のデータセンターのシステムと通信する必要がある場合（VPN 経由の接続やハイブリッド接続など）、問題が発生することがあります。

トラブルシューティング手順

Google Kubernetes Engine（GKE）環境内で接続性の問題が発生した場合、状況を修正するために実施できる特定の手段があります。推奨される問題解決プロセスの包括的な概要については、以下のトラブルシューティング ツリーを参照してください。

ステップ 1: 接続テストの実行

接続テストは、ネットワーク エンドポイント間の接続を確認できる診断ツールです。構成を分析し、場合によってはエンドポイント間でライブ データプレーン分析を行います。このテストは、ネットワーク パスが正しいかどうか、接続の妨げとなっているファイアウォール ルールやルートがないかどうかを確認するのに役立ちます。接続テストの詳細な実行方法については、以下の動画をご覧ください。

ステップ 2: 問題の特定

• GKE クラスタと同じサブネットに GCE VM を作成します。この VM から外部エンドポイントへの接続をテストします。

• VM からの接続が正常である場合、GKE 構成に問題がある可能性が高いことになります。接続が正しく機能していない場合は、VPC ネットワークに焦点を当てます。

ステップ 3: GKE 構成のトラブルシューティング

GKE ノードからの接続をテストします。ノードからの接続は機能するが、Pod からは接続できない場合は、以下の領域を調査します。

• IP マスカレード: IP マスカレードが有効になっているか、実行されているか、ip-masq-agent configmap がネットワーク設定と一致しているかを確認します。なお、configmap yaml の「nonMasqueradeCIDRs」で定義された宛先へのトラフィックは、送信元がノードの IP アドレスではなく、Pod の IP アドレスとして送信されることに注意してください。このため、Pod の IP 範囲からのトラフィックもエンドポイントの宛先で受け入れられる必要があります。ip-masq-agent の configmap がなく、ip-masq-agent デーモンセットのみが実行されている場合、デフォルトのマスカレード以外のすべての宛先へのトラフィックは、Pod の IP アドレス経由で送信されます。Autopilot クラスタの場合、これは Egress NAT ポリシーを使用して構成されます。

• ネットワーク ポリシー: 上り（内向き） / 下り（外向き）ルールに障害の可能性がないか確認します。Dataplane V2 を使用している場合は、ロギングを有効にします。

• IPtables: 機能しているノードと機能していないノードのルールを比較します。特定のノードで「sudo iptables-save」を実行すれば、その出力を確認できます。

• サービス メッシュ: 使用環境で Cloud Service Mesh または Istio を実行している場合は、名前空間のテスト Pod でistio プロキシの挿入を無効にしてテストし、問題がまだ存在するかどうか確認することを検討します。サイドカーの挿入を無効にして接続できた場合は、問題はサービス メッシュの設定にある可能性が高くなります。

メモ: GKE ノードからの接続のテストや GKE ノードからの IP テーブルのチェックなど、一部の手順は GKE Autopilot クラスタでは動作せず、標準クラスタにのみ適用されます。

ステップ 4: ノード固有の問題の特定

特定のノードからの接続に失敗した場合:

• 構成を比較: 機能しているノードと構成が一致しているかどうかを確認します。

• リソースの使用率を確認: CPU やメモリ、または conntrack テーブルに関する問題の有無を確認します。

• エラーの生じたノードから sosreport を収集します。このレポートは、RCA の実行に役立ちます。

• 問題が GKE ノードに特定される場合は、後述するログフィルタが有効です。特定のタイムスタンプに絞り込んで、一般的なエラーを探します。接続タイムアウト、OOM kill（oom_watcher）、「Kubelet is unhealthy」、NetworkPluginNotReady などのログは、トラブルシューティングの正しい方向性を見極めるうえで役立つはずです。その他の類似クエリについては、GKE ノードレベルのクエリを確認してください。

resource.type="k8s_node"

resource.labels.cluster_name="GKE_CLUSTER_NAME"

resource.labels.node_name="NODE_NAME"

ステップ 5: 外部通信への対処

限定公開 GKE クラスタでの外部接続の問題については、Pod とノードの両方の CIDR に対して Cloud NAT が有効になっていることを確認します。

ステップ 6: コントロール プレーン接続問題への対処

• ノードから GKE クラスタのコントロール プレーン（GKE マスター エンドポイント）への接続は、GKE クラスタのタイプ（限定公開 / 一般公開 / PSC ベースのクラスタ）によって異なります。

• コントロール プレーンの接続性を確認する手順のほとんどは、前述のような、接続に関する一般的な問題に対するトラブルシューティング手順と同様です。たとえば、GKE クラスタの限定公開または一般公開コントロール プレーン エンドポイントに対して、接続テストを実行します。

• 上記に加えて、送信元が GKE クラスタと異なるリージョンにある場合は、送信元がコントロール プレーンの承認済みネットワークで許可されていること、および GKE クラスタのコントロール プレーンのグローバル アクセスが有効になっていることを確認します。

• GKE 外部からのトラフィックが、プライベート エンドポイント上のコントロール プレーンのみにアクセスするようにルーティングする必要がある場合は、クラスタの作成時に--enable-private-endpoint を有効にしてください。このフィールドは、クラスタの管理に、コントロール プレーンの API エンドポイントのプライベート IP アドレスが使用されることを示します。同じクラスタ内の Pod およびノードは、パブリック エンドポイントの設定に関係なく、常にプライベート エンドポイントのみで GKE マスターに接続しようとすることに注意してください。

• パブリック エンドポイントが有効になっている GKE クラスタ A のコントロール プレーンに、別の限定公開 GKE クラスタ B（Cloud Composer など）からアクセスすると、クラスタ B の Pod は常に、クラスタ A のパブリック エンドポイントへの接続を試みます。したがって、限定公開クラスタ B が外部アクセス用に Cloud NAT を有効にしていること、Cloud NAT の IP 範囲が、クラスタ A においてコントロール プレーンの承認済みネットワークで許可リストに登録されていることを確認する必要があります。

まとめ

上記の手順は、接続に関する一般的な問題に対処し、初期のトラブルシューティングの枠組みを提供します。問題が複雑であったり、断続的であったりする場合は、より深い分析が必要となります。これには、問題の発生時に影響を受けたノード（標準クラスタにのみ適用）または Pod（Autopilot クラスタと標準クラスタの両方に適用）のパケット キャプチャを収集して、包括的な根本原因を分析することなどが必要です。このような問題についてさらにサポートが必要な場合は、Cloud サポートにお問い合わせください。

ー Google、ネットワーキング担当スタッフ テクニカル ソリューション エンジニアAnkita Ojha

ー Google、ネットワーキング担当 Cloud テクニカル ソリューション スペシャリストAmbika Sharma