在 Kubernetes 主节点上运行用户 Pod 是否存在问题? [英] Are there issues with running user pods on a Kubernetes master node?
问题描述
许多部署 Kubernetes 主节点的运行建议您使用 --register-schedulable=false 来防止用户 Pod 被调度到主节点(例如 https://coreos.com/kubernetes/docs/latest/deploy-master.html).在一个非常小的 Kubernetes 集群上，除非绝对必要，否则有效地阻止整个节点用于 pod 调度似乎有点浪费计算资源.
这个问题的答案(Will(可以) Kubernetes 在主节点上运行 Docker 容器?) 表明确实可以在主节点上运行用户 pod - 但没有解决是否存在与允许此相关的任何问题.>
迄今为止，我能够找到的唯一信息表明，允许这样做可能存在相关问题，主节点上的 pod 似乎不安全地通信(请参阅 http://kubernetes.io/docs/admin/master-node-communication/ 和 https://github.com/kubernetes/kubernetes/issues/13598).我认为这可能会允许在主节点上运行的流氓 Pod 访问/劫持非主节点上的 Pod 通常无法访问的 Kubernetes 功能.如果只运行内部开发的 pods/容器，可能没什么大不了的——尽管我猜总是有可能有人入侵 pod/容器，从而获得对主节点的访问权限.
这听起来像是与此场景相关的可行的潜在风险吗(允许用户 Pod 在 Kubernetes 主节点上运行)?是否存在与此类设置相关的任何其他潜在问题?
在主节点上运行 Pod 绝对是可能的.
您提到的安全风险是一个问题，但是如果您配置服务帐户，对于所有已部署的 pod 而言，对 apiserver 进行安全远程访问与不安全本地访问实际上并没有太大区别.
另一个问题是资源争用.如果您在主节点上运行破坏主组件的流氓 Pod，它可能会破坏整个集群的稳定性.显然，这是生产部署的一个问题，但如果您希望在开发/实验环境中最大限度地利用少量节点，那么在主节点上运行几个额外的 Pod 应该没问题.
最后，您需要确保主节点有足够大的 pod cidr 分配给它.在某些部署中，master 只得到一个/30，这不会允许你运行很多 pod.
Many of the run-throughs for deploying Kubernetes master nodes suggest you use --register-schedulable=false to prevent user pods being scheduled to the master node (e.g. https://coreos.com/kubernetes/docs/latest/deploy-master.html). On a very small Kubernetes cluster it seems somewhat a wasteful of compute resources to effectively prevent an entire node from being used for pod scheduling unless absolutely essential.
The answer to this question (Will (can) Kubernetes run Docker containers on the master node(s)?) suggests that it is indeed possible to run user pods on a master node - but doesn't address whether there are any issues associated with allowing this.
The only information that I've been able to find to date that suggests there might be issues associated with allowing this is that it appears that pods on master nodes communicate insecurely (see http://kubernetes.io/docs/admin/master-node-communication/ and https://github.com/kubernetes/kubernetes/issues/13598). I assume that this would potentially allow a rogue pod running on a master node to access/hijack Kubernetes functionality not normally accessible to pods on non-master nodes. Probably not a big deal with if only running pods/containers developed internally - although I guess there's always the possibility of someone hacking access to a pod/container and thereby gaining access to the master node.
Does this sound like a viable potential risk associated with this scenario (allowing user pods to run on a Kubernetes master node)? Are there any other potential issues associated with such a setup?
Running pods on the master node is definitely possible.
The security risk you mention is one issue, but if you configure service accounts, it isn't actually much different for all deployed pods to have secure remote access to the apiserver vs. insecure local access.
Another issue is resource contention. If you run a rogue pod on your master node that disrupts the master components, it can destabilize your entire cluster. Clearly this is a concern for production deployments, but if you are looking to maximize utilization of a small number of nodes in a development / experimentation environment, then it should be fine to run a couple of extra pods on the master.
Finally, you need to make sure the master node has a sufficiently large pod cidr allocated to it. In some deployments, the master only gets a /30 which isn't going to allow you to run very many pods.
这篇关于在 Kubernetes 主节点上运行用户 Pod 是否存在问题?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
