今日、何らかの理由で、デプロイメントの1つに新しいバージョンをロールアウトしたときに、ポッドがContainerCreatingでスタックし、次のエラーイベントが発生しました。
1h 1m 37 some-api-2275263275-01pq7 Pod Warning FailedMount {kubelet gke-cluster-1-default-pool-4399eaa3-os4v} Unable to mount volumes for pod "some-api-2275263275-01pq7_default(afc5ae68-5b5e-11e6-afbb-42010a800105)": timeout expired waiting for volumes to attach/mount for pod "some-api-2275263275-01pq7"/"default". list of unattached/unmounted volumes=[default-token-880jy]
1h 1m 37 some-api-2275263275-01pq7 Pod Warning FailedSync {kubelet gke-cluster-1-default-pool-4399eaa3-os4v} Error syncing pod, skipping: timeout expired waiting for volumes to attach/mount for pod "some-api-2275263275-01pq7"/"default". list of unattached/unmounted volumes=[default-token-880jy]
次に、クラスターをスケーリングしようとしましたが、以前に実行されていたポッドの75%以上がContainerCreatingに切り替わり、そこでスタックしました。 これにより、システムで広範囲にわたる障害が発生し、新しいクラスターをすばやく作成する必要がありました。
Google Cloud Platformのコンテナエンジンを使用しており、クラスタのバージョンは1.3.2です。
@montanaflynn v1.3.2では、v1.3.4で修正されたストレージ関連の問題がいくつか
スタックされたデプロイメントを持つノードからの完全な/var/log/kubelet log
を共有する場合、それが既知の問題であるかどうかを調べて確認できます。 マスターログを取得するには、GKEプロジェクト名/クラスター名/ゾーンも必要です。 公に共有したくない場合は、遠慮なく私にメールしてください。
v1.3.3でも同様の問題が発生しましたが、私の場合、根本的な原因ははるかに歩行者でした。 デプロイメントにはシークレットボリュームが必要であり、新しいデプロイメントを実行しようとしたクラスターに関連付けられたシークレットを作成するのを忘れていました。 kubectl describe
またはkubectl logs
を使用してもエラーは発生しませんContainerCreating
状態(ログの失敗なし)のままであることに最終的に気付きました。
この問題は古くなっています。 閉鎖。
最も参考になるコメント
v1.3.3でも同様の問題が発生しましたが、私の場合、根本的な原因ははるかに歩行者でした。 デプロイメントにはシークレットボリュームが必要であり、新しいデプロイメントを実行しようとしたクラスターに関連付けられたシークレットを作成するのを忘れていました。
kubectl describe
またはkubectl logs
を使用してもエラーは発生しませんContainerCreating
状態(ログの失敗なし)のままであることに最終的に気付きました。