Kubernetes 在调度新节点上的吊舱之前，请等待canal吊舱

在为kubernetes创建/添加节点时，我们还必须创建运河吊舱

目前，kubernetes没有等到Canal吊舱准备就绪后再尝试调度吊舱，导致失败（错误如下）

一旦运河吊舱启动并运行，只需删除故障吊舱即可解决问题

我的问题是：告诉kubernetes等待网络pod准备就绪再尝试在节点上调度pod的正确方式是什么

• 我是否应该污染节点，使其仅允许运河，并在其准备就绪后取消着色
• 运河准备就绪后，我是否应该编写删除失败吊舱的脚本
• 是否有一种配置或方法可以消除该问题

---

这是一个常见的问题，所以我将发布答案
这种行为是正常的，尤其是在自托管k8s集群中。在自托管环境中，包括控制平面元素（例如kube apiserver、canal）在内的所有部署都将同时计划
一旦控制飞机运行，故障吊舱最终应能正常启动。k8s将继续重新启动失败的吊舱，直到它正常启动

---

为了使Canal首先启动，清单可以与其他控制平面清单（例如kube apiserver、kube controller manager）一起部署在k8s节点中。它通常出现在

/etc/kubernetes/manifests

中，但路径完全是任意的。但是，如果Canal的准备时间过长，则会出现相同的错误。
您能否描述导致此错误的更多步骤？可能是实际的

kubectl

命令，或者至少是工作流，以及为什么需要执行该工作流？运河不是在部署其他吊舱之前部署到所有集群的东西吗？>运河不是在部署其他吊舱之前部署到所有集群的东西吗？我也这么认为，但在你的评论之后，我已经更新到了Canal的最新版本，而不是1.6.6。问题解决了。现在发生的情况如下：1：创建新pod 2：k8s尝试调度新pod，失败3：创建新节点4：k8s尝试调度新节点上的新pod，失败原因是通道未准备就绪5：通道已准备就绪6:？？尝试在新节点上调度新pod，它是有效的。在我看来，这种失败在这种情况下是正常的。设计用于重试和失败，而不是声明显式依赖项。

Error syncing pod, skipping: failed to "CreatePodSandbox" for "nginx-2883150634-fh5s2_default(385d61d6-6662-11e7-8989-000d3af349de)" with CreatePodSandboxError: "CreatePodSandbox for pod \"nginx-2883150634-fh5s2_default(385d61d6-6662-11e7-8989-000d3af349de)\" failed: rpc error: code = 2 desc = NetworkPlugin cni failed to set up pod \"nginx-2883150634-fh5s2_default\" network: failed to find plugin \"loopback\" in path [/opt/loopback/bin /opt/cni/bin]"