我想将我的GKE集群中的核心数量保持在3以下 . 如果K8s复制控制器和pod的CPU限制从100m减少到最多50m,这就变得更加可行 . 否则,K8s吊舱单独占据一个核心的70% .
我决定不增加节点的CPU功率 . 在我看来,这在概念上是错误的,因为CPU限制被定义为在核心中测量 . 相反,我做了以下事情:
-
使用"50m"作为默认CPU限制的版本替换限制范围/限制(不是必需的,但在我看来更干净)
-
修补kube-system命名空间中的所有复制控制器,以便对所有容器使用50米
-
删除他们的 beans 荚
-
将kube-system命名空间中的所有非rc pod替换为对所有容器使用50m的版本
这是很多工作,可能很脆弱 . 即将推出的K8版本中的任何进一步更改或GKE配置的更改都可能会破坏它 .
那么,有更好的方法吗?
2 回答
更改默认命名空间的LimitRange
spec.limits.defaultRequest.cpu
应该是更改新Pod默认值的合法解决方案 . 请注意,LimitRange对象是命名空间,因此如果使用额外的命名空间,您可能需要考虑它们的默认值 .正如您所指出的,这不会影响kube系统命名空间中的现有对象或对象 .
kube系统命名空间中的对象大多是根据经验确定的 - 基于观察值 . 改变这些可能会产生不利影响,但如果您的集群非常小,可能不会 .
我们有一个未解决的问题(https://github.com/kubernetes/kubernetes/issues/13048)来根据总的簇大小调整kube系统请求,但尚未实现 . 我们还有另一个未解决的问题(https://github.com/kubernetes/kubernetes/issues/13695)可能会为某些kube系统资源使用较低的QoS,但同样 - 尚未实现 .
其中,我认为#13048是实现您所要求的正确方法 . 就目前而言,“有更好的方法”的答案可悲“不” . 我们为中型群集选择默认值 - 对于非常小的群集,您可能需要执行您正在执行的操作 .
顺便说一下,如果你想在Google Cloud GCE上试试这个 . 如果您尝试更改kube-dns等核心服务的CPU限制,则会出现这样的错误 .
试过Kubernetes 1.8.7和1.9.4 .
因此,此时您需要部署的最小节点是n1-standard-1 . 另外,只要你有几个 beans 荚和头盔,Kubernetes本身几乎不断地吃掉大约8%的cpu . 即使你没有运行任何重大负荷 . 我认为有很多轮询正在进行,并确保群集响应他们不断刷新一些统计数据 .