Kubernetes: ポッドがContainerCreatingステータスでスタックしている

作成日 2016年08月06日  ·  3コメント  ·  ソース: kubernetes/kubernetes

今日、何らかの理由で、デプロイメントの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です。

arekubectl kinbug sistorage

最も参考になるコメント

v1.3.3でも同様の問題が発生しましたが、私の場合、根本的な原因ははるかに歩行者でした。 デプロイメントにはシークレットボリュームが必要であり、新しいデプロイメントを実行しようとしたクラスターに関連付けられたシークレットを作成するのを忘れていました。 kubectl describeまたはkubectl logsを使用してもエラーは発生しませんContainerCreating状態(ログの失敗なし)のままであることに最終的に気付きました。

全てのコメント3件

@montanaflynn v1.3.2では、v1.3.4で修正されたストレージ関連の問題がいくつか

スタックされたデプロイメントを持つノードからの完全な/var/log/kubelet logを共有する場合、それが既知の問題であるかどうかを調べて確認できます。 マスターログを取得するには、GKEプロジェクト名/クラスター名/ゾーンも必要です。 公に共有したくない場合は、遠慮なく私にメールしてください。

v1.3.3でも同様の問題が発生しましたが、私の場合、根本的な原因ははるかに歩行者でした。 デプロイメントにはシークレットボリュームが必要であり、新しいデプロイメントを実行しようとしたクラスターに関連付けられたシークレットを作成するのを忘れていました。 kubectl describeまたはkubectl logsを使用してもエラーは発生しませんContainerCreating状態(ログの失敗なし)のままであることに最終的に気付きました。

この問題は古くなっています。 閉鎖。

このページは役に立ちましたか?
0 / 5 - 0 評価