我已經使用 kubeadm 在單節點伺服器上安裝了 kubernetes。我發現透過按特定順序執行安裝，一切都會正常運作。這包括主要的 kube 系統元件（api 伺服器、代理程式、調度程序、etcd 等），它們首先啟動並運行（coredns 除外），然後使用 helm 安裝 cilium CNI 插件進行網路連接（導致 coredns 工作）。
安裝完成後，我就可以成功安裝和使用其他服務，例如 NVIDIA 的 GPU Operator 和 kubeflow。然而，在執行重新啟動後，我發現不同的元件進入崩潰循環退避狀態。
我認為這與不同資源的初始化順序以及各種不同超時的長度有關。有沒有辦法設定不同元件在啟動時啟動的順序？或可能配置適當的預設逾時或 pod 崩潰行為？
這裡可能會發生骨牌效應，其中一個組件崩潰導致另一個組件崩潰，然後導致回退時間不斷增加，最終導致群集無響應。
有關更多信息，我保留了 iptables 規則，以便在啟動時應用它們。此外，通常所有主要元件都會進入運行狀態，除了 kube 調度程式處於崩潰循環退避狀態。然後其他組件也開始崩潰，這似乎是多米諾骨牌效應。
到目前為止，我主要嘗試更新 /etc/kubernetes/manifests/ 下的清單文件，以對 kubernetes 系統 Pod 使用各種不同的超時和 failureThresholds，但是，這似乎並沒有解決問題。我可以透過先停止 kubelet 服務並銷毀所有正在運行的 pod/容器，然後重新啟動 kubelet 來複製伺服器重新啟動行為。
答案1
事實證明這個問題和這個GitHub中描述的問題非常相似問題。基本上沒有為我的containerd CRI運行時指定SystemdCgroup = true選項（這是nvidia容器運作時而不是預設的runc)，pod 會不斷莫名其妙地崩潰。發生這種情況是由於違反了 cgroup 的單寫入器規則，因為管理 cgroup 的預設驅動程式cgroupfs不能與systemd.您可以看到文件了解更多詳情。它還包括 CRI 插件配置的完整規範這裡。
其他相關的容器資源有：