如何减少kubernetes系统资源的CPU限制？

Question

我希望我的GKE集群中的内核数量保持在3个以下。如果K8s复制控制器和pod的CPU限制从100m减少到最多50m，这将变得更加可行。不然光K8s豆荚就占了一个核心的70%。

我决定不增加节点的 CPU 功率。在我看来，这在概念上是错误的，因为 CPU 限制被定义为以内核为单位进行测量。相反，我做了以下工作：

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

这是大量的工作，可能很脆弱。K8s未来版本的任何进一步变化，或GKE配置的变化，都可能会打破它。

那么，有没有更好的办法呢？

Answer 1

正如@Tim Hockin所说，附加组件的默认配置适用于典型的集群。但可以通过更改资源限制规范来微调。

在调整加载项大小之前，请记住，您也可以禁用不必要的加载项。这可能会因插件、其版本、kubernetes版本和提供商的不同而有所不同。谷歌有一个页面，涵盖了一些选项，同样的概念也可以用于其他提供商

作为@Tim Hockin回答中所链接问题的解决方案，第一个被接受的方法是使用插件大小调整器。它基本上找到了最佳的限制和要求，修补了Deployment/Pod/DemonSet，并重新创建了相关的Pod以匹配新的限制，但比手动完成所有这些工作要少。

但是，实现此目的的另一种更强大的方法是使用Vertical Pod Autoscaler@Tim如Smart答案中所述。VPA 完成了插件调整器的功能，但它有很多好处：

• VPA是插件本身的自定义资源定义，允许您的代码比使用插件大小调整器更紧凑
• 通过成为自定义资源定义，使实现保持最新也更加容易
• 一些提供商（如谷歌）在控制平面进程上运行VPA资源，而不是在工作节点上部署。因此，即使插件大小调整器更简单，VPA也不会使用您的资源，而插件大小调整程序会使用

更新后的模板将是：

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服务都将其作为一个易于检查的选项）

更新策略可以是初始（仅在创建新pod时应用新限制）、重新创建（强制pod超出规格而死亡并应用于新pod）、关闭（创建建议但不应用）或自动（当前匹配重新创建，将来可以更改）

@Tim Smart answer example上唯一的区别是当前api版本是< code > auto scaling . k8s . io/v1 ，targets的当前api版本是< code>apps/v1，以及一些提供者的较新版本使用FluentBit代替Fluentd。他的答案可能更适合早期的kubernetes版本

例如，如果您使用的是Google Kubernetes Engine，那么目前一些“最重”的需求插件是：

• Fluentbit-gke（DaemonSet）
• gke-元数据-server（DaemonSet）
• 库贝-Proc（DaemonSet）
• 库贝-dns（部署）
• 堆栈驱动器-元数据-代理-集群级（部署）

通过在其上应用 VPA，我的插件资源需求从 1.6 下降到 0.4。

Answer 2

更改默认命名空间的 LimitRange spec.limits.defaultRequest.cpu 应该是更改新 Pod 默认值的合法解决方案。请注意，LimitRange 对象是命名空间的，因此如果您使用额外的命名空间，您可能需要考虑它们的合理默认值是什么。

正如你所指出的，这不会影响现有对象或 kube-system 命名空间中的对象。

kube-system 命名空间中的对象大多根据经验调整大小 - 基于观测值。更改这些可能会产生不利影响，但如果群集非常小，则可能不会。

我们有一个开放的问题（https://github.com/kubernetes/kubernetes/issues/13048）来根据总集群大小调整库贝系统请求，但还没有实现。我们还有另一个开放的问题（https://github.com/kubernetes/kubernetes/issues/13695）可能对一些库贝系统资源使用较低的QoS，但同样-还没有实现。

其中，我认为#13048是实现你所要求的正确方法。就目前而言，对“有更好的方法吗”的回答是令人遗憾的“没有”。我们为中等规模的集群选择了默认值——对于非常小的集群，您可能需要做您正在做的事情。

Answer 3

我发现在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"

下面是它对kube-dns部署所做操作的屏幕截图。