许多部署Kubernetes主节点的过程都建议您使用它--register-schedulable=false来防止将用户Pod调度到主节点（例如https://coreos.com/kubernetes/docs/latest/deploy-master.html）。在非常小的Kubernetes集群上，除非绝对必要，否则似乎无法有效地阻止整个节点用于Pod调度的计算资源浪费。
这个问题的答案（Kubernetes会在主节点上运行Docker容器吗？）表明确实有可能在主节点上运行用户Pod，但并没有解决与之相关的任何问题。允许这个。
到目前为止，我能找到的唯一表明可能与允许这样做有关的信息是，主节点上的Pod似乎通信不安全（请参阅http://kubernetes.io/docs/admin/master- node-communication /和https://github.com/kubernetes/kubernetes/issues/13598）。我假设这将潜在地允许在主节点上运行的恶意Pod访问/劫持Kubernetes功能，这些功能通常是非主节点上的Pod无法访问的。如果仅在内部开发运行的Pod /容器，可能不会有什么大不了的-尽管我猜总是会有某人入侵对Pod /容器的访问权限，从而获得对主节点的访问权限的可能性。
这听起来像与此场景相关的可行潜在风险（允许用户Pod在Kubernetes主节点上运行）吗？这样的设置还有其他潜在的问题吗？
前几天查了一下为什么没有pod被调度到master节点，发现了这个问题：Allow schedule of pods on Kubernetes master？
它告诉这是因为主节点被“NoSchedule”效果污染了，并给出了删除该污染的命令。
但是在我在集群上执行该命令之前，我想首先了解它为什么会出现在那里。
主节点不应该运行 Pod 有什么原因吗？任何与它相关的最佳实践？
kubernetes ×2