如何降低kubernetes系统资源的CPU限制？

Question

我想将我的GKE集群中的核心数量保持在3以下。如果K8s复制控制器和pod的CPU限制从100m减少到最多50m，这就变得更加可行。否则，K8s吊舱单独占据一个核心的70％。

我决定不增加节点的CPU功率。在我看来，这在概念上是错误的，因为CPU限制被定义为在核心中测量。相反，我做了以下事情：

• 使用“50m”作为默认CPU限制的版本替换限制范围/限制（不是必需的，但在我看来更干净）
• 修补kube-system命名空间中的所有复制控制器，以便为所有容器使用50米
• 删除他们的豆荚
• 将kube-system命名空间中的所有非rc pod替换为对所有容器使用50m的版本

这是很多工作，可能很脆弱。即将推出的K8版本中的任何进一步更改或GKE配置的更改都可能会破坏它。

那么，有更好的方法吗？

Answer 1

更改默认命名空间的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是实现您所要求的正确方法。就目前而言，“有更好的方法”的答案可悲“不”。我们为中型群集选择默认值 - 对于非常小的群集，您可能需要执行您正在执行的操作。

Answer 2

我发现减少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.

Answer 3

顺便说一下，如果你想在Google Cloud GCE上试试这个。如果您尝试更改kube-dns等核心服务的CPU限制，则会出现这样的错误。

spec：Forbidden：pod更新可能不会更改除spec.containers[*].image，spec.initContainers[*].image，spec.activeDeadlineSeconds或spec.tolerations之外的字段（仅添加现有容差

试过Kubernetes 1.8.7和1.9.4。

所以此时需要部署的最小节点是n1-standard-1。另外，只要你有几个豆荚和头盔，Kubernetes本身几乎不断地吃掉大约8％的cpu。即使你没有运行任何重大负荷。我认为有很多轮询正在进行，并确保群集响应他们不断刷新一些统计数据。