Kubeadm及在主节点调度Pod的风险（Pod一直处于挂起状态）

Question

Kubeadm及在主节点调度Pod的风险（Pod一直处于挂起状态）

9

在遵循使用kubeadm创建集群的Kubernetes文章时，我遇到了问题，当我尝试安装AddOn pods（Nginx、Tiller、Grafana、InfluxDB、Dashboard）时，它们总是停留在Pending状态。检查kubectl describe pod tiller-deploy-df4fdf55d-jwtcz --namespace=kube-system的消息会得到以下消息：

Type     Reason            Age                From               Message
----     ------            ----               ----               -------
Warning  FailedScheduling  51s (x15 over 3m)  default-scheduler  0/1 nodes are available: 1 node(s) had taints that the pod didn't tolerate.

当我从“主节点隔离”部分运行命令kubectl taint nodes --all node-role.kubernetes.io/master-时，插件将按预期安装。

在这一点上，我只能怀疑（因为它们已经安装在主节点上），原因是我还没有将工作节点连接到集群中，以便调度程序安排Pod。

文档中指出，“出于安全考虑，集群不会在主节点上安排Pod”。我知道这是一个非生产环境，因此在这种情况下几乎没有风险，但是在生产集群中移除该污点的风险是什么？

跟进问题：如果存在风险，如何重新添加该污点，以便然后卸载AddOn Pod并尝试让调度程序将它们安装在工作节点上？

环境详细信息：操作系统 - CentOS 7.4.1708（核心）Kubernetes版本 - 1.10

- Flea

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- mdaniel · Accepted Answer

原因是我还没有将工作节点连接到集群中，以便调度程序对Pod进行调度。

完全正确。如果没有工作节点，"调度工作"的想法就会变得非常奇怪。

但在生产集群中删除这种污点的风险是什么？

我不是 Kubernetes 安全专家，但一个实际的风险是可能导致主节点的 CPU、I/O 或内存耗尽，这将对群集的健康产生非常严重的影响。几乎没有什么理由在主节点上运行任何工作负载，而几乎完全增加了风险，因此“不要这样做”的建议是有根据的。

那我如何重新添加这个 tainted 以便卸载 AddOn pods 并尝试让调度程序将它们安装在 Workers 节点上呢？

我不确定我理解了这个问题，但我肯定会先添加一个 Worker 节点，然后再尝试使用 taints 和 tolerations 进行复杂操作。