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

Question

我想把我的GKE集群中的核心数量保持在3以下。如果K8s复制控制器和pods的CPU限制从100米减少到最多50米，这就更可行了。否则，单是K8s吊舱就占据了一个核心的70%。

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

• 用"50m“作为默认CPU限制替换限制范围/限制(没有必要，但在我看来更干净)
• 修补kube-system命名空间中的所有复制控制器，以便对所有容器使用50m。
• 删除它们的豆荚
• 用所有容器使用50m的版本替换kube-system命名空间中的所有非rc吊舱。

这是大量的工作，可能是脆弱的。对即将发布的K8s版本的任何进一步更改，或对GKE配置的更改，都可能会破坏它。

有更好的办法吗？

Answer 1

更改默认名称空间的LimitRange spec.limits.defaultRequest.cpu应该是更改新Pods缺省值的合法解决方案。请注意，LimitRange对象是名称空间，所以如果您使用额外的名称空间，您可能想考虑一下它们的默认设置是什么。

正如您所指出的，这不会影响中的现有对象或对象。

库贝系统命名空间中的物体大多是根据观测值进行经验测量的.更改这些可能会产生有害的影响，但如果集群非常小，则可能不会。

我们有一个开放问题(https://github.com/kubernetes/kubernetes/issues/13048)，可以根据集群的总大小来调整kube系统请求，但还没有实现。我们还有另一个开放问题(https://github.com/kubernetes/kubernetes/issues/13695)，可能会对一些kube系统资源使用较低的QoS，但仍然没有实现。

其中，我认为#13048是实现你所要求的正确方式。就目前而言，“是否有更好的方法”的答案是遗憾的“不”。我们选择了中型集群的默认设置--对于非常小的集群，您可能需要做您正在做的事情。

Answer 2

我发现减少GKE集群上的系统资源请求的最佳方法之一是使用垂直自动分频器。

下面是我使用的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"

部署。

Answer 3

正如@Tim Hockin所述，默认的外接程序配置适用于典型的集群。但是，可以通过更改资源限制规范对其进行微调。

在进行加载项调整之前，请记住，您也可以禁用不可缺少的加载项供您使用.这可能会因插件、其版本、kubernetes版本和提供者而略有不同。谷歌有一页涵盖了一些选项。，同样的概念也可以在其他提供者中使用。

对于问题的解决办法中的@Tim Hockin应答，第一个被接受的方法是使用 加号。它基本上找出了最佳的限制和需求，对部署/Pod/DaemonSet进行了修补，并重新创建了相关的荚以匹配新的限制，但花费的工作量比手动完成的都要少。

然而，实现这一目标的另一种更健壮的方法是使用垂直Pod自动分词器，如@Tim Smart应答所述。VPA完成了addon-resizer所做的工作，但它有许多优点：

• VPA是一个自定义的资源定义，它允许您的代码比使用addon-resizer更加紧凑。
• 通过作为一个自定义资源定义，保持实现的更新也更加容易。
• 某些提供程序(作为谷歌)在控制平面进程上运行VPA资源，而不是在工作节点上部署。这样做，即使是加法大小更简单。，VPA也不会使用您的资源，而addon-resizer也会使用。

更新的模板如下：

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: <addon-name>-vpa
  namespace: kube-system
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       <addon-kind (Deployment/DaemonSet/Pod)>
    name:       <addon-name>
  updatePolicy:
    updateMode: "Auto"

检查当前集群中使用的加载项是很重要的，因为它们可以根据提供者(AWS、Google等)和它的kubernetes实现版本进行很大的更改。

确保在集群中安装了VPA插件(大多数kubernetes服务都将其作为一个容易检查的选项)

更新策略可以是初始(仅在创建新荚时才应用新限制)、重新创建(强制超出规范的荚死并应用于新荚)、Off (创建建议但不适用)或Auto (当前匹配重新创建、可以在未来改变 )。

@Tim Smart答案示例的唯一不同之处在于，当前的api版本是autoscaling.k8s.io/v1，目标的当前api版本是apps/v1，一些提供者的更新版本使用FluentBit代替apps/v1。他的回答可能更适合于较早的kubernetes版本。

例如，如果您正在使用Google引擎，目前一些“最重”的需求插件是：

• 流利-gke (DaemonSet)
• 元数据服务器(DaemonSet)
• kube-代理(DaemonSet)
• kube-dns (部署)
• 堆栈驱动程序.元数据代理-集群级(部署)

通过在上面应用VPA，我的addon资源需求从1.6降到0.4。