在Kubernetes主节点上运行用户pod有问题吗？

Question

部署Kubernetes主节点的许多运行建议您使用--register-schedulable=false来阻止将用户pod安排到主节点（例如https://coreos.com/kubernetes/docs/latest/deploy-master.html）。在一个非常小的Kubernetes集群上，除非绝对必要，否则有效地防止整个节点被用于pod调度似乎有点浪费计算资源。

这个问题（Will (can) Kubernetes run Docker containers on the master node(s)?）的答案表明，确实可以在主节点上运行用户窗格 - 但是没有解决是否存在与允许此问题相关的任何问题。

我迄今为止能够找到的唯一信息表明可能存在与允许相关的问题，主节点上的pod似乎不安全地通信（请参阅http://kubernetes.io/docs/admin/master-node-communication/和{{3 }}）。我假设这可能允许在主节点上运行的流氓pod访问/劫持非主节点上的pod通常无法访问的Kubernetes功能。如果只是在内部开发运行的pod /容器，可能没什么大不了的 - 虽然我想总有可能有人黑客访问pod /容器，从而获得对主节点的访问权限。

这听起来像是与此方案相关的可行潜在风险（允许用户pod在Kubernetes主节点上运行）吗？是否还存在与此类设置相关的其他潜在问题？

Answer 1

绝对可以在主节点上运行pod。

您提到的安全风险是一个问题，但是如果您配置服务帐户，那么所有已部署的pod实际上对于使用apiserver和不安全的本地访问进行安全远程访问实际上并不是很不相同。

另一个问题是资源争用。如果在主节点上运行流氓pod会破坏主组件，则可能会破坏整个群集的稳定性。显然，这是生产部署的一个问题，但如果您希望在开发/实验环境中最大限度地利用少量节点，那么在主服务器上运行几个额外的pod应该没问题。

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

Answer 2

@robert给出了明确的答案。我只是想通过实时示例以隐喻的方式进行解释。

您公司的MANAGER是更好的编码器。如果他开始编码，则您公司的MANAGER工作将停滞/效率降低，因为他可以用有效方式处理一件事情。这将使整个公司面临风险。

为了有效地运作，请更多的开发人员进行编码，并且不要让您的经理进行编码（以得到您所付的款项来获得作品）。