在Kubernetes主节点上运行用户吊舱是否存在问题？

部署Kubernetes主节点的许多演练建议您使用

--register schedulable=false

来防止将用户吊舱调度到主节点（例如）。在一个非常小的Kubernetes集群上，有效地阻止整个节点用于pod调度似乎有点浪费计算资源，除非绝对必要

这个问题的答案（）表明，在主节点上运行用户pod确实是可能的，但没有说明是否存在与允许这样做相关的任何问题

到目前为止，我所能找到的唯一信息表明，允许这样做可能存在相关问题，即主节点上的吊舱通信不安全（请参阅和）。我假设这可能会允许运行在主节点上的恶意pod访问/劫持非主节点上的pod通常无法访问的Kubernetes功能。如果只运行内部开发的pod/container，可能没什么大不了的——尽管我猜总有人入侵pod/container的访问权限，从而获得对主节点的访问权限

---

这听起来像是与此场景相关的可行潜在风险吗（允许用户吊舱在Kubernetes主节点上运行）？是否存在与此设置相关的任何其他潜在问题？

在主节点上运行POD是绝对可能的

您提到的安全风险是一个问题，但如果您配置了服务帐户，那么所有部署的POD对apiserver进行安全的远程访问与不安全的本地访问实际上并没有多大区别

另一个问题是资源争用。如果在主节点上运行一个破坏主组件的恶意pod，它可能会破坏整个集群的稳定性。显然，这是生产部署的一个问题，但是如果您希望在开发/实验环境中最大限度地利用少量节点，那么在主节点上运行两个额外的pod就可以了

---

最后，您需要确保主节点分配了足够大的pod cidr。在某些部署中，主机只获得a/30，这不允许您运行很多吊舱

@罗伯特给出了明确的答案。我只是想用一个实时的例子，用一种隐喻的方式来解释

你们公司的经理是一个更好的编码员。如果他开始编写代码，公司经理的工作就会停滞不前/效率低下，因为他能以高效的方式处理一件事。这将使你的整个公司处于危险之中

为了高效地运作，雇佣更多的开发人员来编写代码，而不是让你的经理编写代码（为了按你付给他的金额来完成工作）