部署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--但不解决是否存在与允许此问题相关的任何问题 .
迄今为止我能够找到的唯一信息表明可能存在与允许这一点相关的问题，即主节点上的pod似乎不安全地通信（请参阅http://kubernetes.io/docs/admin/master-node-communication/和https://github.com/kubernetes/kubernetes/issues/13598） . 我假设这可能允许在主节点上运行的流氓pod访问/劫持非主节点上的pod通常无法访问的Kubernetes功能 . 如果只运行内部开发的pod /容器可能没什么大不了的 - 尽管我猜总有可能有人黑客访问pod /容器，从而获得对主节点的访问权限 .
这听起来像是与这种情况相关的可行潜在风险（允许用户pod在Kubernetes主节点上运行）吗？是否还存在与此类设置相关的其他潜在问题？
1 回答
绝对可以在主节点上运行pod .
您提到的安全风险是一个问题，但是如果您配置服务帐户，则对于所有已部署的pod，实际上远程访问apiserver与不安全的本地访问权限并不是很不相同 .
另一个问题是资源争用 . 如果在主节点上运行一个破坏主组件的流氓pod，则可能会破坏整个群集的稳定性 . 显然，这是 生产环境 部署的一个问题，但如果您希望在开发/实验环境中最大限度地利用少量节点，那么在主服务器上运行几个额外的pod应该没问题 .
最后，您需要确保主节点有足够大的pod cidr分配给它 . 在某些部署中，主服务器只获得一个/ 30，这将不允许您运行很多pod .