このページでは、GKE の既知の問題について説明します。このページは、基盤となる技術インフラストラクチャのライフサイクルを管理し、サービスレベル目標（SLO）が達成されていない場合やアプリケーションで障害が発生した場合にアラートやページに対応する管理者、アーキテクトを対象としています。
このページでは、サポートされているすべてのバージョンと、延長サポートの最も古いバージョンの直前の 2 つのマイナー バージョンの既知の問題について説明します。バージョンが延長サポートの終了を迎えると、N-2 の問題はすべて削除されます。たとえば、バージョン 1.30 が延長サポートの終了に達すると、バージョン 1.28 以前に固有の既知の問題が削除されます。
Google Developer Program に参加している場合は、このページを保存して、このページに関連するリリースノートが公開されたときに通知を受け取るようにしてください。詳細については、保存したページをご覧ください。
既知の問題をプロダクト バージョンまたはカテゴリでフィルタするには、次のプルダウン メニューからフィルタを選択します。
GKE バージョンを選択します。
問題のカテゴリを選択:
または、問題を検索します。
| カテゴリ | 該当するバージョン | 解決済みのバージョン | 問題と回避策 |
|---|---|---|---|
| オペレーション | すべてのバージョン | 未定 |
ノードの自動修復中にGoogle Cloud コンソール UI が編集できなくなるGKE ノードで自動修復が行われている場合、オペレーションが進行中のため、 Google Cloud コンソールからノードプールを編集できなくなります。 回避策: gcloud CLI コマンドを使用して、ノードプールの構成を編集することはできます。 |
| オペレーション | 1.33.4-gke.1036000 より前の 1.33 バージョン | 1.33.4-gke.1036000 以降 |
動的にプロビジョニングされた Lustre インスタンスのパフォーマンス階層が正しくないLustre インスタンスを動的にプロビジョニングすると、API リクエストで指定された perUnitStorageThroughput の値に関係なく、PerUnitStorageThroughput の 回避策: GKE クラスタをバージョン 1.33.4-gke.1036000 以降にアップグレードします。Stable チャンネルを使用している場合、新しいバージョンはまだ利用できない可能性があります。この場合は、修正を含む 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 がスタックしている場合は、そのステータスを削除するようにパッチを適用できます。次のようなパッチコマンドを使用して、残っているステータスを削除できます。 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 状態のままになることがある
io_uring 関連の syscall を使用する Pod は、Linux カーネルのバグにより 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 ノードに「今後のメンテナンス」ラベルが適用されません。これにより、ワークロードのノードドレインと 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 チャネルに参加して、コミュニティ サポートを利用することもできます。 - 公開バグトラッカーを使用して、バグの報告や機能リクエストの登録を行う。