このページでは、GKE の既知の問題について説明します。このページは、基盤となる技術インフラストラクチャのライフサイクルを管理し、サービスレベル目標（SLO）が達成されていない場合やアプリケーションで障害が発生した場合にアラートやページに対応する管理者、アーキテクトを対象としています。
このページでは、サポートされているすべてのバージョンと、延長サポートの最も古いバージョンの直前の 2 つのマイナー バージョンの既知の問題について説明します。バージョンが拡張サポートの終了を迎えると、N-2 の問題はすべて削除されます。たとえば、バージョン 1.30 の拡張サポートが終了すると、バージョン 1.28 以前に固有の既知の問題は削除されます。
Google Developer Program に参加している場合は、このページを保存して、このページに関連するリリースノートが公開されたときに通知を受け取るようにしてください。詳細については、保存したページをご覧ください。
既知の問題をプロダクト バージョンまたはカテゴリでフィルタするには、次のプルダウン メニューからフィルタを選択します。
GKE バージョンを選択します。
問題のカテゴリを選択:
または、問題を検索します。
| カテゴリ | 該当するバージョン | 解決済みのバージョン | 問題と回避策 |
|---|---|---|---|
| オペレーション | 1.33.4-gke.1036000 より前の 1.33 バージョン | 1.33.4-gke.1036000 以降 |
動的にプロビジョニングされた Lustre インスタンスのパフォーマンス ティアが正しくないLustre インスタンスを動的にプロビジョニングすると、API リクエストで指定された perUnitStorageThroughput 値に関係なく、PerUnitStorageThroughput の 回避策: GKE クラスタをバージョン 1.33.4-gke.1036000 以降にアップグレードします。安定版チャンネルを使用している場合、新しいバージョンがまだ利用できない可能性があります。この場合は、修正を含む Regular チャンネルまたは Rapid チャンネルのバージョンを手動で選択できます。 |
| オペレーション |
|
1.33.3-gke.1266000 以降 |
Cloud Storage FUSE CSI ドライバを使用してファイルの名前変更または移動を行う際に入出力エラーが発生する影響を受けるバージョンの Cloud Storage FUSE CSI ドライバを使用している場合、Cloud Storage バケット内のファイルの名前変更または移動が I/O エラーで失敗することがあります。 回避策: 特定のサイドカー イメージ定義を Pod マニフェストに一時的に追加します。Pod マニフェストの # Add the following block to use the fixed sidecar image - name: gke-gcsfuse-sidecar image: gcr.io/gke-release/gcs-fuse-csi-driver-sidecar-mounter:v1.8.9-gke.2 詳細については、サイドカー コンテナのプライベート イメージを構成するの Pod マニフェストをご覧ください。 クラスタを修正済みの GKE バージョン以降にアップグレードしたら、マニフェストから |
| ロギングとモニタリング | すべてのバージョン | 未定 |
|
| アップグレード | 1.33 | 1.33.2-gke.1043000 |
containerd 2.0 で開いているファイルの制限が引き下げられたcontainerd 2.0 を使用する GKE バージョン 1.33 を実行するノードプールの場合、コンテナのオープン ファイル（ これは containerd 自体の変更（containerd PR #8924 を参照）で、ベスト プラクティスとして デフォルトのソフト上限が高いことを想定しているワークロード（以前のデフォルトが高いことを暗黙的に前提としているワークロードなど）では、 解決策: 以前の 1.33 パッチ バージョンから 1.33.2-gke.1043000 以降にアップグレードします。 回避策: 次のいずれかの方法で、ワークロードのオープン ファイルの上限を引き上げます。
|
| アップグレード | 1.31.5-gke.1169000、1.32.1-gke.1376000 | 1.31.7-gke.1164000、1.32.3-gke.1512000 |
マネージド CRD の CRD ステータス storedVersions が無効一部の GKE 管理の CRD に無効な この問題は、次の両方に該当するクラスタに影響します。
回避策: 推奨される回避策は、問題が解決するまでクラスタのアップグレードを遅らせることです。 また、クラスタにサポートされていないバージョンの CRD オブジェクトが含まれていることがわかっている場合は、 |
| 運用、ロギング、モニタリング | 1.32.2-gke.1652000、1.31.6-gke.1221000、1.30.10-gke.1227000 |
|
指標が見つからない、またはワークロード オートスケーラーがスケーリングしないクラスタサイズが 5 つ以上のノードで増加すると、影響を受けるバージョンで指標データにギャップが生じることがあります。この問題は、自動スケーリング オペレーションにも影響する可能性があります。 この問題は、影響を受けるバージョンにアップグレードされたクラスタにのみ影響します。新しく作成されたクラスタは想定どおりに動作します。 回避策: 影響を受ける場合は、1 つのパッチ バージョンをダウングレードするか、新しい修正済みバージョンにアップグレードできます。 |
| オペレーション |
Google Cloud Hyperdisk のサイズとアタッチメントの上限通常、ノードのボリューム アタッチメントの上限が原因でスケジュールできない Pod は、新しいノードの自動プロビジョニングをトリガーします。Hyperdisk プロダクトを使用するワークロードが C3 VM を実行するノードにスケジュールされると、ノードの自動プロビジョニングは行われず、Pod はすでに満杯のノードにスケジュールされます。 使用可能なディスク アタッチメントがないにもかかわらず、ワークロードがノードにスケジュールされます。ワークロードも、次のようなエラーで起動に失敗します。 AttachVolume.Attach failed for volume "[VOLUME NAME]" : rpc error: code = InvalidArgument desc = Failed to Attach: failed when waiting for zonal op: rpc error: code = InvalidArgument desc = operation operation-[OPERATION NUMBERS] failed (UNSUPPORTED_OPERATION): Maximum hyperdisk-balanced disks count should be less than or equal to [16], Requested : [17] この問題は、C3 マシンのすべての Hyperdisk プロダクトで発生します。 Hyperdisk のアタッチメントの上限は、VM の vCPU 数と Hyperdisk プロダクトによって異なります。詳細については、Hyperdisk のパフォーマンスの上限をご覧ください。 回避策: Hyperdisk プロダクトは、他の VM シェイプで自動プロビジョニングをトリガーします。Hyperdisk のみをサポートするシェイプをおすすめします。 |
||
| オペレーション | 1.32.3-gke.1927000、1.32.3-gke.1785000、1.32.3-gke.1717000、1.32.3-gke.1440000、1.32.3-gke.1170000、1.32.3-gke.1250000、1.32.3-gke.1671000、1.32.3-gke.1596000、1.32.3-gke.1298000 |
TPU/GPU ノードで gke-metadata-server が OOMKilled されるGKE TPU ノード（ 回避策: TPU ノードまたは GPU ノードで |
|
| オペレーション |
|
|
PVC の NodePendingResize ステータスが残っているため、ボリュームのサイズ変更が停止することがあります。バージョン 1.31 以前のノードがあるバージョン 1.32 のクラスタでは、サイズ変更中に PersistentVolumeClaim ステータスの更新が失敗します。このステータスが正しくないため、後続のサイズ変更オペレーションが開始されず、サイズ変更が効果的に防止されます。 この状態の PVC には、 クラスタが影響を受けるバージョンで PVC が作成された場合、クラスタを既知の修正バージョンにアップグレードした後も、この問題が解決しないことがあります。このシナリオでは、PVC をパッチ適用して、1 回限りの回避策で 回避策: ステータスがぶら下がっているために PVC がスタックしている場合は、そのステータスを削除するようにパッチを適用できます。次のようなパッチ コマンドを使用して、dangling ステータスを削除できます。 kubectl patch pvc $PVC_NAME --subresource='status' --type='merge' -p '{"status":{"allocatedResourceStatuses":null}}'kubectl patch pvc $PVC_NAME --subresource='status' --type='merge' -p '{"status":{"allocatedResources":null}}' |
| オペレーション |
|
|
PDCSI ドライバが過剰にロギングする可能性がある1.32 の特定のバージョンの GKE クラスタでは、PDCSI ドライバから過剰なログメッセージが出力されることがあります。この過剰なロギングは、Cloud Logging Write API の割り当てを消費します。 回避策: この過剰なロギングを減らすには、除外フィルタを追加します。ログメッセージが Cloud Logging に取り込まれないようにするには、次のクエリを使用します。
resource.type="k8s_container"
resource.labels.container_name="gce-pd-driver"
(sourceLocation.file="cache.go" OR "Cannot process volume group")
|
| 運用 |
|
|
以前に読み取り専用（RO）マウントがあった COS ノードに NFS 永続ボリュームをマウントしようとする Pod は、RO モードでのみマウントされますGKE バージョン 1.27 以降では、Kubernetes in-tree CSI ドライバを使用する NFS ボリュームは、同じノードで以前に RO マウントを行った後にのみ、RO モードで永続ボリュームをマウントできます。 回避策: 影響を受けるバージョンより前のバージョンにノードプールをダウングレードします。 |
| 運用 |
|
|
Ubuntu ノードで NFS 永続ボリュームをマウントしようとする Pod は実行できません。GKE バージョン 1.32 以降では、Kubernetes in-tree CSI ドライバを使用する NFS ボリュームは、Ubuntu ノードに永続ボリュームをマウントできません。この場合、次のエラー メッセージが表示されることがあります。 "MountVolume.SetUp failed for volume 'nfs-storage' : mount failed: exit status 1" Output: Mount failed: mount failed: exit status 127 "Output: chroot: failed to run command 'mount': No such file or directory failed to run command mount on Ubuntu nodes" 回避策: ノードプールをダウングレードしてバージョン 1.31 にします。 |
| オペレーション | >= 1.28.15-gke.1436000、< 1.28.15-gke.1668000、>= 1.29.12-gke.1040000、< 1.29.13-gke.1028000、>= 1.30.8-gke.1053000、< 1.30.8-gke.1287000、>= 1.31.4-gke.1057000、< 1.31.6-gke.1020000、>= 1.32.0-gke.1281000、< 1.32.1-gke.1302000 |
|
io_uring 関連の syscall を使用する Pod が Terminating 状態のままになることがある
Linux カーネルのバグにより、io_uring 関連の syscall を使用する Pod が D（ディスク スリープ）状態（TASK_UNINTERRUPTIBLE とも呼ばれます）になることがあります。D 状態のプロセスは、
この既知の問題の影響を受ける Pod では、コンテナが正常に終了しないことがあります。containerd ログに、次のようなメッセージが繰り返し表示されることがあります。
または
これらの症状は、コンテナ内のプロセスが割り込み不可スリープ（D 状態）で停止し、Pod の適切な終了を妨げていることを示しています。
io_uring を直接使用するワークロード、または NodeJS などの言語ランタイムを介して io_uring を間接的に使用するワークロードは、この既知の問題の影響を受ける可能性があります。影響を受けるワークロードでは、 回避策: クラスタノードを修正バージョン以降にアップグレードします。 |
| オペレーション | 1.28、1.29、1.30、1.31 |
|
イメージ ストリーミングを使用するワークロードが認証エラーで失敗するイメージ ストリーミング機能のバグにより、コンテナがファイルを読み取っているときに特定の条件が満たされると、ワークロードが失敗することがあります。認証エラーに関連するエラー メッセージが gcfsd ログに表示されることがあります。
影響を受けているかどうかを確認するには、次の検索クエリでログを検索します。
これらのエラーが存在する場合は、ノードが影響を受けていることを示します。 この問題の影響を受けている場合は、パッチが適用された GKE バージョンに ノードプールをアップグレードできます。 |
| オペレーション |
|
|
GKE バージョン 1.30 と 1.31 で Pod のエビクション率が増加した
COS 113 と COS 117 をそれぞれ使用する GKE 1.30 と GKE 1.31 の一部のバージョンには、オプション
構成オプション この問題はワークロードのメモリ使用パターンに依存するため、異常な Pod の削除率が常に表示されるとは限りません。resources フィールドでメモリ上限を設定していないワークロードの場合、kubelet が Pod を強制排除するリスクが高くなります。これは、ワークロードが kubelet が使用可能と報告したメモリよりも多くのメモリをリクエストする可能性があるためです。 他の変更を行わずに上記の GKE バージョンにアップグレードした後、アプリケーションのメモリ使用量が増加した場合は、カーネル オプションの影響を受けている可能性があります。
異常な Pod の強制排除率があるかどうかを確認するには、Metrics Explorer で次の指標を分析します。
次の PromQL クエリを使用できます。
max by (pod_name)(max_over_time(kubernetes_io:container_memory_used_bytes{monitored_resource="k8s_container",memory_type="non-evictable",cluster_name="REPLACE_cluster_name",namespace_name="REPLACE_namespace",metadata_system_top_level_controller_type="REPLACE_controller_type",metadata_system_top_level_controller_name="REPLACE_controller_name"}[${__interval}]))
sum by (pod_name)(avg_over_time(kubernetes_io:container_memory_request_bytes{monitored_resource="k8s_container",cluster_name="REPLACE_cluster_name",namespace_name="REPLACE_namespace",metadata_system_top_level_controller_type="REPLACE_controller_type",metadata_system_top_level_controller_name="REPLACE_controller_name"}[${__interval}]))
メモリ使用量がリクエストされたメモリを超えて異常に急増している場合は、ワークロードが頻繁に強制排除されている可能性があります。 回避策修正バージョンにアップグレードできない場合、特権 Pod をデプロイできる GKE 環境で実行している場合は、DaemonSet を使用して Multi-Gen LRU オプションを無効にできます。
選択したすべてのノードプールで DaemonSet が実行されると、変更は直ちに有効になり、kubelet のメモリ使用量の計算が正常に戻ります。 |
| オペレーション | 1.28、1.29、1.30、1.31 |
|
Pod が Terminating ステータスで停止するコンテナ ランタイム（containerd）のバグにより、Pod とコンテナが Terminating 状態のままになり、次のようなエラーが発生する可能性があります。 OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown
この問題の影響を受ける場合は、containerd の修正バージョンを含む GKE バージョンに ノードをアップグレードできます。 |
| オペレーション | 1.28、1.29 |
|
シンボリック リンクが原因で画像ストリーミングが失敗するイメージ ストリーミング機能のバグにより、コンテナが起動しないことがあります。 特定の GKE バージョンでイメージ ストリーミングが有効になっているノードで実行されているコンテナが、次のエラーで作成に失敗することがあります。 "CreateContainer in sandbox from runtime service failed" err="rpc error: code = Unknown desc = failed to create containerd container: failed to mount [PATH]: too many levels of symbolic links"
この問題の影響を受ける場合は、 空のレイヤまたは重複するレイヤを確認できます。空のレイヤまたは重複するレイヤを削除できない場合は、イメージ ストリーミングを無効にします。 |
| オペレーション | 1.27、1.28、1.29 |
|
ファイルが欠落しているため、イメージ ストリーミングが失敗するイメージ ストリーミング機能のバグにより、ファイルが欠落しているためにコンテナが失敗することがあります。 次のバージョンでイメージ ストリーミングが有効になっているノードで実行されているコンテナは、起動に失敗したり、特定のファイルが存在しないことを示すエラーで実行されたりする可能性があります。このようなエラーの例を次に示します。
この問題の影響を受ける場合は、イメージ ストリーミングを無効にすることができます。 |
| ネットワーキング、アップグレード、更新 | 1.28 |
Gateway TLS 構成エラーGKE バージョン 1.28.4-gke.1083000 を実行しているクラスタの Gateway で TLS を構成する際に問題が確認されています。これは、SSLCertificate または CertificateMap のいずれかを使用する TLS 構成に影響します。既存の Gateway を使用してクラスタをアップグレードすると、Gateway に対する更新は失敗します。新しい Gateway の場合、ロードバランサはプロビジョニングされません。この問題は、今後の GKE 1.28 パッチ バージョンで修正される予定です。 |
|
| アップグレードと更新 | 1.27 | 1.27.8 以降 |
GPU デバイス プラグインの問題
GPU を実行していて、1.26 から 1.27.8 より前の 1.27 パッチ バージョンにアップグレードされたクラスタでは、ノードの GPU デバイス プラグイン（
|
| オペレーション | 1.27、1.28 |
|
すべてのワークロードの自動スケーリングが停止する
HorizontalPodAutoscaler（HPA）と VerticalPodAutoscaler（VPA）には、構成が誤った 回避策:
|
| オペレーション | 1.28、1.29 |
|
Container Threat Detection のデプロイが失敗する次の GKE バージョンを実行している Autopilot クラスタでは、Container Threat Detection のデプロイが失敗する可能性があります。
|
| ネットワーキング、アップグレード | 1.27、1.28、1.29、1.30 |
|
コントロール プレーンのアップグレード後の
|
| ネットワーキング | 1.31、1.32 |
|
同じノードで実行されている Pod 間の UDP トラフィックが中断されるノード内の可視化が有効になっているクラスタでは、同じノードで実行されている Pod 間の UDP トラフィックが中断されることがあります。 この問題は、GKE クラスタノードが次のいずれかの GKE バージョンにアップグレードされた場合、または次のいずれかの GKE バージョンで作成された場合に発生します。
影響を受けるパスは、Hostport または Service を介した同じノード上の Pod 間 UDP トラフィックです。 解決策 クラスタを次のいずれかの修正バージョンにアップグレードします。
|
| オペレーション | 1.29、1.30、1.31 |
|
Ray Operator と Cloud KMS データベースの暗号化の互換性がない一部の Ray Operator バージョンは、Cloud KMS データベースの暗号化と互換性がありません。 回避策 クラスタ コントロール プレーンを修正バージョン以降にアップグレードします。 |
| アップグレードと更新 | 1.30、1.31 |
|
GPU メンテナンス ハンドラ Pod が CrashLoopBackOff 状態のままになるこの問題では、gpu-maintenance-handler Pod がそれぞれのノードで `CrashLoopBackOff` 状態のままになります。この状態では、GKE ノードに `upcoming maintenance` ラベルが適用されません。これにより、ワークロードのノードドレインと Pod の強制排除の両方のプロセスに影響する可能性があります。
"Node upcoming maintenance label not applied due to error: Node "gke-yyy-yyy" is invalid: metadata.labels: Invalid value: "-62135596800": a valid label must be an empty string or consist of alphanumeric characters, '-','' or '.', and must start and end with an alphanumeric character (e.g.'MyValue', or 'my_value', or '12345', regex used for validation is '(([A-Za-z0-9][-A-Za-z0-9.]*)?[A-Za-z0-9])?')"
この問題の影響を受けている場合は、修正を含む GKE バージョンにコントロール プレーンをアップグレードすることで解決できます。 |
| オペレーション | 1.33.1-gke.1522000 以降 | 1.33.4-gke.1142000 以降 |
イメージ ストリーミングが有効になっているノードで Pod が起動しない
イメージ ストリーミングが有効になっているノードでは、ワークロードが次のエラー シグネチャで起動に失敗することがあります。
影響を受けるノードのシリアルポート ログにも、次のエラー シグネチャが含まれています。
これらの 2 つのエラー シグネチャが存在する場合、イメージ ストリーミング コンポーネントのいずれかでデッドロックが発生していることを示します。このデッドロックにより、Pod が正常に起動しなくなります。 解決策 ノードを再起動して、迅速に緩和します。再起動したノードでデッドロックが再び発生する可能性があります。より堅牢な緩和策として、次のコマンドを実行してノードプールでイメージ ストリーミングを無効にします。 gcloud container node-pools update NODE_POOL_NAME --cluster CLUSTER_NAME --no-enable-image-streaming |
次のステップ
このドキュメントで問題を解決できない場合は、サポートを受けるで、次のトピックに関するアドバイスなど、詳細なヘルプをご覧ください。
- Cloud カスタマーケアに問い合わせて、サポートケースを登録する。
- StackOverflow で質問する、
google-kubernetes-engineタグを使用して類似の問題を検索するなどして、コミュニティからサポートを受ける。#kubernetes-engineSlack チャネルに参加して、コミュニティ サポートを利用することもできます。 - 公開バグトラッカーを使用して、バグの報告や機能リクエストの登録を行う。