kubeadm を使用して、単一ノード サーバーに kubernetes をインストールしました。特定の順序でインストールを実行すると、すべてが正常に起動して実行されることがわかりました。これには、最初にスピンアップして実行された (coredns を除く) メインの kube システム コンポーネント (api サーバー、プロキシ、スケジューラ、etcd など) が含まれ、その後、ネットワーク用に helm を使用して cilium CNI プラグインがインストールされました (その結果、coredns が動作します)。
このインストールの後、NVIDIA の GPU オペレーターや kubeflow などの他のサービスを正常にインストールして使用できるようになりました。ただし、再起動を実行すると、さまざまなコンポーネントがクラッシュ ループ バックオフ状態になることがわかりました。
これは、さまざまなリソースが初期化される順序と、さまざまなタイムアウトの長さに関係していると思います。起動時にさまざまなコンポーネントが開始する順序を設定する方法はありますか? または、適切なデフォルトのタイムアウトまたはポッドのクラッシュ動作を構成することはできますか?
ここではドミノ効果が起こっている可能性があり、1 つのコンポーネントがクラッシュすると別のコンポーネントもクラッシュし、その結果バックオフ時間がますます長くなり、最終的にはクラスターが応答しなくなります。
追加情報として、iptables ルールを永続化して、起動時に適用されるようにしました。また、通常、クラッシュ ループ バックオフのままである kube スケジューラを除くすべての主要コンポーネントが実行状態になります。その後、ドミノ効果のように他のコンポーネントもクラッシュし始めます。
これまで、主に /etc/kubernetes/manifests/ の下にあるマニフェスト ファイルを更新して、Kubernetes システム ポッドにさまざまなタイムアウトと failureThresholds を使用するように試みてきましたが、これでは問題は解決しなかったようです。まず kubelet サービスを停止し、実行中のすべてのポッド/コンテナーを破棄してから kubelet を再起動することで、サーバーの再起動動作を再現できました。
答え1
この問題は、このGitHubで説明されている問題と非常によく似ていることが判明しました。問題基本的に、SystemdCgroup = true私のコンテナCRIランタイム（これはnvidiaコンテナランタイムデフォルトの ではなく を使用するとrunc、ポッドは不可解なクラッシュを繰り返していました。これは、cgroup を管理するためのデフォルトのドライバーが であり、cgroupfsと相互運用できないため、 cgroup のシングルライタールールに違反したために発生していましたsystemd。ドキュメンテーション詳細については、CRIプラグイン構成の完全な仕様も含まれています。ここ。
その他の関連する containerd リソースは次のとおりです。