このページでは、GKE ネットワーキングの既知の問題について説明します。このページは、基盤となる技術インフラストラクチャのライフサイクルを管理し、サービスレベル目標（SLO）が達成されていない場合やアプリケーションで障害が発生した場合にアラートやページに対応する管理者、アーキテクトを対象としています。
既知の問題をプロダクト バージョンでフィルタするには、次のプルダウン メニューからフィルタを選択します。
GKE バージョンを選択します。
または、問題を検索します。
| 該当するバージョン | 解決済みのバージョン | 問題と回避策 |
|---|---|---|
| 1.36 | 修正中 |
レイヤ 4 ロードバランサを使用する Windows ノードでの接続障害とクラッシュ ループ システム Podバージョン 1.36 を実行している Windows Server ノードプールがある GKE クラスタでは、次のいずれかの問題が発生する可能性があります。
この問題は、クラスタが GKE サブセット化のないレイヤ 4 内部ロードバランサを使用している場合、または古いターゲット プールまたはインスタンス グループを使用している外部パススルー ネットワーク ロードバランサを使用している場合に発生します。GKE 1.36 では、Compute Engine ゲスト エージェントは Windows Server で 回避策: この問題を軽減するには、次のいずれかの方法を使用します。
|
| InferencePool Helm チャート v1.1.0 |
InferencePool の targetPortNumber フラグが無視される
回避策: インストール後にポートを確認します。 kubectl get inferencepool POOL_NAME -o jsonpath='{.spec.targetPorts}' \ --context=CLUSTER_CONTEXT ポートが正しくない場合は、エクスポートする前に kubectl patch inferencepool POOL_NAME --type=merge \ -p '{"spec":{"targetPorts":[{"number":TARGET_PORT}]}}' \ --context=CLUSTER_CONTEXT |
|
| 1.33、1.34、1.35 |
|
|
| 1.29、1.30、1.31、1.32、1.33 | 1.34 |
FQDN ネットワーク ポリシーを削除すると、anetd Pod 内の
|
| 1.28、1.29、1.30、1.31、1.32、1.33 |
GKE Dataplane V2 を使用するノードでの Pod IP アドレスのリーククラスタで GKE Dataplane V2 が有効になっていると、ノードで Pod IP アドレスが使い果たされる可能性があります。この問題は、Pod の作成中に一時的な CNI エラーが発生したときに、コンテナ ランタイムのバグ（割り当てられた IP アドレスがリークする可能性）が原因で発生します。 この問題は、GKE クラスタノードが次のいずれかの GKE バージョンにアップグレードされた場合、または次のいずれかの GKE バージョンで作成された場合に発生します。
この問題が発生すると、影響を受けるノードでスケジュールされた新しい Pod が起動に失敗し���エラー メッセージ 回避策: この問題を回避するには、緩和策の DaemonSet をクラスタに適用して、リークした IP リソースをクリーンアップします。 apiVersion: apps/v1 kind: DaemonSet metadata: name: cleanup-ipam-dir namespace: kube-system spec: selector: matchLabels: name: cleanup-ipam template: metadata: labels: name: cleanup-ipam spec: hostNetwork: true securityContext: runAsUser: 0 runAsGroup: 0 seccompProfile: type: RuntimeDefault automountServiceAccountToken: false containers: - name: cleanup-ipam image: gcr.io/gke-networking-test-images/ubuntu-test:2022@sha256:6cfbdf42ccaa85ec93146263b6e4c60ebae78951bd732469bca303e7ebddd85e command: - /bin/bash - -c - | while true; do for hash in $(find /hostipam -iregex '/hostipam/[0-9].*' -mmin +10 -exec head -n1 {} \; ); do hash="${hash%%[[:space:]]}" if [ -z $(ctr -n k8s.io c ls | grep $hash | awk '{print $1}') ]; then grep -ilr $hash /hostipam fi done | xargs -r rm echo "Done cleaning up /var/lib/cni/networks/gke-pod-network at $(date)" sleep 120s done volumeMounts: - name: host-ipam mountPath: /hostipam - name: host-ctr mountPath: /run/containerd securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL volumes: - name: host-ipam hostPath: path: /var/lib/cni/networks/gke-pod-network - name: host-ctr hostPath: path: /run/containerd |
|
| 1.31、1.32、1.33 |
|
以前のネットワークを使用するクラスタでの上り（内向き）ロードバランサと Service のロードバランサの停止以前のネットワークとの互換性がないた���、上り（内向き）または Service を使用してデプロイされた GKE マネジドのロードバランサのバックエンドが切り離されます。これにより、ロードバランサにアクティブなバックエンドがなくなり、これらのロードバランサへのすべての受信リクエストがドロップされます。 この問題は、以前のネットワークを使用し、バージョン 1.31 以降の GKE クラスタに影響します。 以前のネットワークを使用している GKE クラスタを特定するには、次のコマンドを実行します。 gcloud container clusters describe CLUSTER_NAME --location=LOCATION --format="value(subnetwork)" 以前のネットワークを使用するクラスタの場合、このコマンドの出力は空になります。 回避策: 以前のネットワークはしばらく前に非推奨になったため、推奨される解決策はレガシー ネットワークを VPC ネットワークに移行することです。これを行うには、GKE クラスタを含む以前のネットワークを変換します。現時点でこの移行を実行できない場合は、Cloud カスタマーケアにお問い合わせください。 |
| 1.30、1.31、1.32 |
|
新しく作成されたノードがレイヤ 4 内部ロードバランサに追加されない内部 LoadBalancer Service 用に作成された Google Cloud ロードバランサで、バックエンド インスタンス グループに新しく作成されたノードが欠落する場合があります。 この問題は、ノード数が 0 にスケーリングされ、その後 1 つ以上のノードにスケーリング バックされたクラスタで最も顕著になります。 回避策
|
| 1.31、1.32 |
|
CRD ステータスから storedVersions が削除されたことが原因で発生する Gateway API の問題
GKE の Kube-Addon-Manager が、 次のすべての条件を満たす場合、クラスタがリスクにさらされる可能性があります。
回避策: 推奨される回避策は、問題が解決するまでクラスタのアップグレードを遅らせることです。
また、クラスタのバージョンをアップグレードする必要がある場合は、影響を受けるすべての Gateway API CRD のストレージ バージョンを
|
| 1.32 |
|
ContainerCreating で新しい Pod の初期化が失敗する
新しい Pod を作成できず、 Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "[sandbox-ID]": plugin type="cilium-cni" failed (add): unable to create endpoint: Cilium API client timeout exceeded この問題は、GKE バージョン 1.31 または 1.32 で作成された、1.32～1.32.3-gke.1170000 より前のバージョンの GKE クラスタに影響します。根本原因は、割り当てられた Cilium ID のコレクションを保持するインメモリ データ構造が、Kubernetes API サーバーの状態と正しく同期されていないことです。
クラスタの作成に使用された GKE のバージョンを確認するには、次のコマンドを使用して gcloud container clusters describe [cluster_name] --location [location] --format='value(initialClusterVersion)'
GKE クラスタでロギングが有効になっている場合、 resource.type="k8s_container" resource.labels.container_name="cilium-agent" 回避策: 一時的な回避策は、コントロール プレーンの再起動です。これを行うには、すでに実行中のバージョンにコントロール プレーンをアップグレードします。 gcloud container clusters upgrade [cluster_name] --location [location] --cluster-version=[version] --master |
| 1.27、1.28、1.29、1.30、1.31 |
Service からポートが削除されると NEG コントローラがエンドポイントの管理を停止するService の スタンドアロン NEG を作成するように NEG コントローラが構成されており、構成されたポートの 1 つが後で Service から削除されると、NEG コントローラは最終的に NEG のエンドポイントの管理を停止します。ユーザーがスタンドアロン NEG アノテーションを作成する Service に加えて、GKE Gateway、MCI、GKE Multi Cluster Gateway によって参照される Service にも影響します。 回避策: スタンドアロン NEG アノテーションを含む Service からポートを削除する場合は、問題のポートを削除するようにアノテーションも更新する必要があります。 |
|
| 1.28 |
Gateway TLS 構成エラーGKE バージョン 1.28.4-gke.1083000 を実行しているクラスタの Gateway で TLS を構成する際に問題が確認されています。これは、SSLCertificate または CertificateMap のいずれかを使用する TLS 構成に影響します。既存の Gateway を使用してクラスタをアップグレードすると、Gateway に対する更新は失敗します。新しい Gateway の場合、ロードバランサはプロビジョニングされません。この問題は、今後の GKE 1.28 パッチ バージョンで修正される予定です。 |
|
| 1.27、1.28、1.29 |
|
断続的な接続確立の失敗コントロール プレーン バージョン 1.26.6-gke.1900 以降のクラスタで、接続の確立が断続的に失敗することがあります。 障害が発生する可能性は低く、すべてのクラスタに影響するわけではありません。症状の発症から数日後には、障害は完全に停止します。 |
| 1.27、1.28、1.29 |
|
Container-Optimized OS の DNS 解決に関する問題Container-Optimized OS ベースのノードを使用する GKE クラスタで実行されているワークロードで、DNS 解決の問題が発生する可能性があります。 |
| 1.28 | 1.28.3-gke.1090000 以降 |
接続トラッキング ルックアップが正しくないため、ネットワーク ポリシーによって接続が切断されるGKE Dataplane V2 が有効になっているクラスタで、クライアント Pod が Service または内部パススルー ネットワーク ロードバランサの仮想 IP アドレスを使用して自身に接続する場合、データプレーンでの conntrack ルックアップが正しく行われず、応答パケットが既存の接続の一部として識別されません。つまり、Pod の上り（内向き）トラフィックを制限するネットワーク ポリシーが、誤ってパケットに適用されます。 この問題の影響は、Service に構成された Pod の数によって異なります。たとえば、Service にバックエンド Pod が 1 つある場合、接続は常に失敗します。Service にバックエンド Pod が 2 つある場合、接続は 50% の確率で失敗します。 回避策:
この問題は、Service マニフェストの |
| 1.27、1.28 |
|
ヘアピン接続フローのパケット ドロップGKE Dataplane V2 が有効になっているクラスタで、Pod が Service を使用して自身との TCP 接続を作成し、Pod が接続の送信元と宛先の両方である場合、GKE Dataplane V2 eBPF 接続トラッキングは接続状態を誤って追跡して、conntrack エントリがリークします。 接続タプル（プロトコル、送信元 / 宛先 IP、送信元 / 宛先ポート）がリークすると、同じ接続タプルを使用する新しい接続で、戻りパケットがドロップされる可能性があります。 回避策: 以下のいずれかの回避策を使用します。
|
| 1.31.0-gke.1506000 以前 | 1.31.0-gke.1506000 以降 |
GKE マルチネットワークのデバイスタイプのネットワークが長いネットワーク名で失敗するクラスタの作成が失敗し、次のエラーが表示されます。
回避策: デバイスタイプのネットワーク オブジェクト名の長さを 41 文字以下に制限します。各 UNIX ドメイン ソケットの完全パス（対応するネットワーク名を含む）が構成されます。Linux では、ソケットパスの長さに制限があります（107 バイト以下）。ディレクトリ、ファイル名の接頭辞、 |
| 1.27、1.28、1.29、1.30 |
|
コントロール プレーンのアップグレード後の
|
| 1.31、1.32 |
|
同じノードで実行されている Pod 間の UDP トラフィックが中断されるノード内の可視化が有効になっているクラスタでは、同じノードで実行されている Pod 間の UDP トラフィックが中断されることがあります。 この問題は、GKE クラスタノードが次のいずれかの GKE バージョンにアップグレードされた場合、または次のいずれかの GKE バージョンで作成された場合に発生します。
影響を受けるパスは、Hostport または Service を介した同じノード上の Pod 間 UDP トラフィックです。 解決策 クラスタを次のいずれかの修正バージョンにアップグレードします。
|
| 1.28、1.29、1.30、1.31 |
合計ノード数が 3 未満で vCPU が不足しているクラスタで Calico Pod が正常でない次の条件をすべて満たすクラスタでは、calico-typha Pod と calico-node Pod をス��ジュールできません。ノードの合計数が 3 未満、各ノードに割り当て可能な vCPU が 1 つ以下、ネットワーク ポリシーが有効になっている。これは、CPU リソースが不足していることが原因です。 回避策
|
|
コントロール プレーンのアップグレード中にゾーンクラスタで Multi-Cluster Gateway（MCG）が停止するGKE ゾーンクラスタでマルチクラスタ Gateway（MCG）を使用するデプロイでは、クラスタのアップグレードなど、コントロール プレーンの再起動を引き起こすイベントの発生中に 503 エラーが発生し、停止することがあります。これは、MCG がネットワーク エンドポイント グループ（NEG）検出に以前のメカニズムを使用していることが原因で発生します。このメカニズムでは、コントロール プレーンの再起動中にゾーンクラスタ内のノードが一時的に使用できなくなると、誤ってバックエンドがゼロと報告されます。これにより、ロードバランサがすべてのバックエンドを削除し、トラフィックが失われます。 回避策
|
||
NEG readiness ゲートの競合状態特定の条件下では、Ingress ヘルスチェックが正常な状態を報告する前に、readiness ゲートが準備完了状態の「偽陽性」を返すことがあります。これにより、Ingress オブジェクトに次のようなエラーイベントが生成されます。
この問題により、GKE がデプロイ ワークロードでローリング アップデートを実行している間、ロードバランサがトラフィックに NEG の数と比較して Pod の数が少ない（2 など）と、この競合状態のリスクが高まります。NEG はリージョンごとに作成され、ゾーンごとに 1 つの NEG が作成されます。通常は 3 つの NEG が作成されます。ローリング アップデートの開始前に、Pod の数が比較的多い場合（各 NEG に常に複数の Pod が存在するなど）、この競合状態がトリガーされる可能性は非常に低くなります。 回避策: この競合状態を回避する最善の方法は、ネットワーク エンドポイント グループにバックエンドを増やすことです。少なくとも 1 つの Pod が常に実行されるように、ローリング アップデート戦略が構成されていることを確認します。たとえば、2 つの Pod のみが正常に実行されている場合、構成例は次のようになります。 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 0 maxSurge: 1 上記の例は提案です。レプリカの数など、いくつかの要因に基づいて戦略を更新する必要があります。 |
||
コンテナ ネイティブ ロードバランサのガベージ コレクションが完了しないGKE のガベージ コレクションは、コンテナ ネイティブのロードバランサを 2 分ごとに収集します。ロードバランサが完全に削除される前にクラスタが削除された場合は、ロードバランサの NEG を手動で削除する必要があります。 回避策: 次のコマンドを実行して、プロジェクト内の NEG を表示します。 gcloud compute network-endpoint-groups list コマンド出力で、関連する NEG を探します。 NEG を削除するには、次のコマンドを実行します。 gcloud compute network-endpoint-groups delete <var>NEG_NAME</var> |
||
ワークロードのロールアウトとエンドポイントの伝播を調整するこの問題は、Pod の readiness フィードバックを使用してワークロードのロールアウトを管理するクラスタでは発生しません。ワークロードをクラスタにデプロイするときや、既存のワークロードを更新するときに、コンテナ ネイティブのロードバランサでは、ワークロードのロールアウトの完了に要する時間よりも、新しいエンドポイントの伝播に要する時間のほうが長くなる場合があります。 回避策: ワークロードのロールアウトでサービスが中断しないように、ワークロードの
|
||
Pod readinessProbe の initialDelaySeconds が認識されないコンテナ ネイティブのロードバランサによって Pod の |