如何降低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

我发现减少 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部署所做的操作的屏幕截图。

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

Answer 3

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

\n

在调整加载项大小之前，请记住您还可以禁用不需要的加载项以供使用。根据附加组件、其版本、kubernetes 版本以及提供商的不同，这可能会略有不同。谷歌有一个页面涵盖了一些选项，相同的概念也可以在其他提供商中使用

\n

至于@Tim Hockin答案中链接的问题的解决方案，第一种接受的方法是使用addon-resizer。它基本上找出最佳的限制和要求，修补 Deployment/Pod/DaemonSet 并重新创建关联的 pod 以匹配新的限制，但比手动完成所有这些工作要省力。

\n

然而，另一种更强大的方法来实现这一点是使用 Vertical Pod Autoscaler，如@Tim Smart答案所述。VPA 完成了 addon-resizer 的功能，但它有很多好处：

\n

\n
• VPA 是插件本身的自定义资源定义，使您的代码比使用 addon-resizer 更加紧凑。
\n
• 通过成为自定义资源定义，也可以更轻松地保持实现的最新状态。
\n
• 一些提供商（如 google ）在控制平面进程上运行 VPA 资源，而不是在工作节点上部署。因此，即使addon-resizer 更简单，VPA 也不会使用您的任何资源，而 addon-resizer 则会使用您的资源。
\n

\n

更新后的模板将是：

\n

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

\n

检查当前集群中使用的插件非常重要，因为它们可能因提供商（AWS、Google 等）及其 kubernetes 实现版本而有很大差异

\n

确保您的集群中安装了 VPA 插件（大多数 kubernetes 服务都将其作为一个简单的选项来检查）

\n

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

\n

@Tim Smart答案示例的唯一区别是当前 api 版本是autoscaling.k8s.io/v1，目标的当前 api 版本是apps/v1，并且某些提供程序的较新版本使用 FluentBit 代替 Fluentd。他的答案可能更适合早期的 kubernetes 版本

\n

例如，如果您当前使用 Google Kubernetes Engine，则一些“最重”的要求插件是：

\n

\n
• Fluentbit-gke (DaemonSet)
\n
• gke-元数据-服务器 (DaemonSet)
\n
• kube-proxy（DaemonSet）
\n
• kube-dns（部署）
\n
• stackdriver-metadata-agent-cluster-level（部署）
\n

\n

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

\n