我已经使用 kubeadm 在单节点服务器上安装了 kubernetes。我发现，通过按特定顺序执行安装，一切都可以正常运行。这包括首先启动并运行的主要 kube 系统组件（api 服务器、代理、调度程序、etcd 等）（coredns 除外），然后使用 helm 安装 cilium CNI 插件进行联网（导致 coredns 正常工作）。
安装完成后，我可以成功安装和使用其他服务，例如 NVIDIA 的 GPU 操作员和 kubeflow。但是，在执行重新启动后，我发现不同的组件进入崩溃循环退避状态。
我认为这与初始化不同资源的顺序以及各种不同超时的长度有关。有没有办法设置启动时不同组件的启动顺序？或者可能配置适当的默认超时或 Pod 崩溃行为？
很可能这里发生了多米诺骨牌效应，一个组件崩溃会导致另一个组件崩溃，从而导致退避时间不断增加，最终导致集群无响应。
为便于理解，我保留了 iptables 规则，以便在启动时应用它们。此外，通常所有主要组件都会进入运行状态，但 kube 调度程序除外，它处于崩溃循环退避状态。然后其他组件也开始崩溃，这似乎是多米诺骨牌效应。
到目前为止，我主要尝试更新 /etc/kubernetes/manifests/ 下的清单文件，以便为 kubernetes 系统 pod 使用各种不同的超时和失败阈值，但这似乎并没有解决问题。我可以通过首先停止 kubelet 服务并销毁所有正在运行的 pod/容器，然后重新启动 kubelet 来复制服务器重启行为。
答案1
事实证明，这个问题与 GitHub 中描述的问题非常相似问题。本质上没有SystemdCgroup = true为我的 containerd CRI 运行时指定选项（这是nvidia容器运行时而不是默认的runc），pod 会莫名其妙地崩溃。这是因为违反了 cgroups 的单写入规则，因为管理 cgroups 的默认驱动程序是 ，cgroupfs它与 不兼容systemd。你可以看到文档了解更多详情。它还包含 CRI 插件配置的完整规范这里。
其他相关的containerd资源包括：