我希望将我的GKE群集中的核心数量保持在3以下。如果K8s复制控制器和pod的CPU限制从100m减少到最多50m,这就变得更加可行。否则,K8s吊舱单独占据一个核心的70%。
我决定不增加节点的CPU功率。在我看来,这在概念上是错误的,因为CPU限制被定义为在核心中测量。相反,我做了以下事情:
这是很多工作,可能很脆弱。即将推出的K8版本中的任何进一步更改或GKE配置的更改都可能会破坏它。
那么,有更好的方法吗?
答案 0 :(得分:6)
更改默认命名空间的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是实现您所要求的正确方法。就目前而言,“有更好的方法”的答案可悲“不”。我们为中型群集选择了默认值 - 对于非常小的群集,您可能需要做你正在做的事情。
答案 1 :(得分:1)
我发现减少GKE群集上的系统资源请求的最佳方法之一是使用vertical autoscaler。
以下是我使用的VPA定义:
apiVersion: autoscaling.k8s.io/v1beta2
kind: VerticalPodAutoscaler
metadata:
namespace: kube-system
name: kube-dns-vpa
spec:
targetRef:
apiVersion: "extensions/v1beta1"
kind: Deployment
name: kube-dns
updatePolicy:
updateMode: "Auto"
---
apiVersion: autoscaling.k8s.io/v1beta2
kind: VerticalPodAutoscaler
metadata:
namespace: kube-system
name: heapster-vpa
spec:
targetRef:
apiVersion: "extensions/v1beta1"
kind: Deployment
name: heapster-v1.6.0-beta.1
updatePolicy:
updateMode: "Initial"
---
apiVersion: autoscaling.k8s.io/v1beta2
kind: VerticalPodAutoscaler
metadata:
namespace: kube-system
name: metadata-agent-vpa
spec:
targetRef:
apiVersion: "extensions/v1beta1"
kind: DaemonSet
name: metadata-agent
updatePolicy:
updateMode: "Initial"
---
apiVersion: autoscaling.k8s.io/v1beta2
kind: VerticalPodAutoscaler
metadata:
namespace: kube-system
name: metrics-server-vpa
spec:
targetRef:
apiVersion: "extensions/v1beta1"
kind: Deployment
name: metrics-server-v0.3.1
updatePolicy:
updateMode: "Initial"
---
apiVersion: autoscaling.k8s.io/v1beta2
kind: VerticalPodAutoscaler
metadata:
namespace: kube-system
name: fluentd-vpa
spec:
targetRef:
apiVersion: "extensions/v1beta1"
kind: DaemonSet
name: fluentd-gcp-v3.1.1
updatePolicy:
updateMode: "Initial"
---
apiVersion: autoscaling.k8s.io/v1beta2
kind: VerticalPodAutoscaler
metadata:
namespace: kube-system
name: kube-proxy-vpa
spec:
targetRef:
apiVersion: "extensions/v1beta1"
kind: DaemonSet
name: kube-proxy
updatePolicy:
updateMode: "Initial"
Here is a screenshot of what it does to a kube-dns
deployment.
答案 2 :(得分:0)
顺便提一下,如果您想在Google Cloud GCE上试用此功能。如果您尝试更改kube-dns等核心服务的CPU限制,则会出现如下错误。
规范:禁止访问:广告连播更新可能不会更改
spec.containers[*].image
,spec.initContainers[*].image
,spec.activeDeadlineSeconds
或spec.tolerations
以外的字段(仅添加现有容差
尝试了Kubernetes 1.8.7和1.9.4。
因此,此时您需要部署的最小节点是n1-standard-1。另外,只要你有几个豆荚和头盔,Kubernetes本身几乎不断地吃掉大约8%的cpu。即使你没有运行任何重大负荷。我认为有很多轮询正在进行,并确保群集响应他们不断刷新一些统计数据。
答案 3 :(得分:0)
我确实尝试直接在Google控制台中进行此更改,但是即使对于我自己的应用程序pod,我的更改也没有保存。
我收到此错误。 禁止:广告连播更新不得更改{spec.i ..
以外的其他字段。在研究的同时,我确实找到了这方面的出色文章, https://medium.com/@betz.mark/understanding-resource-limits-in-kubernetes-cpu-time-9eff74d3161b