需要容量规划

Kubernetes 自动化了大规模管理容器的大部分工作。但是容器化应用程序通常共享池化资源,因此需要适当地分配和管理它们。

Kubernetes 为计划在其上运行的 pod 提供管理所有关键资源(计算、内存和存储)的选项,但集群没有无限资源。这意味着应用程序通常共享池化资源。分配这些资源的“正确”方式因组织和应用程序而异,但好消息是 Kubernetes 包含许多资源管理功能。

管理环境中最常见的 4 个有限容量因素是:

• 利用率

• 个请求

• 限制

• 个配额

利用率

容器 pod 从其底层节点消耗内存和 CPU。高利用率通常会导致性能问题,在节点上有效放置 Pod 可以更好地利用底层基础设施

要求

请求是容器的保证容量。如果一个 Pod 被调度并且没有节点有足够的请求容量——它将不会被调度。对所有单个容器的正确大小请求将允许更多的 pod 安全地放置到环境中。

限制

限制决定了容器在运行时可以使用的最大 CPU 和内存量。节点可以在限制上过度使用(与请求相反)。即限制的总和可以高于节点资源。如果调度的 Pod 超过它的 CPU 限制,它将被限制,如果它超过内存限制,那么 Pod 将终止(并重新启动)并出现 OOM 错误。

限制管理通常是一种平衡,承诺不足会导致资源浪费(其中 pod 无法进行最佳调度),如上所述的过度使用可能会导致资源耗尽。

配额

配额是一种分配资源的机制,通常在命名空间级别施加。请注意,它与集群的实际利用率或整个集群的可用容量没有直接关系。

出现利用率问题是因为 Kubernetes 调度程序在使用给定的一组请求调度 pod 后没有重新评估 pod 的资源需求。因此,过度分配的资源不会被释放或缩减。相反,如果 Pod 没有请求足够的资源,调度程序将不会增加它们以满足更高的需求。

总结一下:

• 如果您过度分配资源:您增加了不必要的工人,浪费了未使用的资源,并增加了您的月度账单。

• 如果资源分配不足:资源会很快用完,应用程序性能会受到影响,kubelet 可能会开始杀死 pod,直到资源利用率下降。

---

[](https://res.cloudinary.com/practicaldev/image/fetch/s--62fSlzjR--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to- uploads.s3.amazonaws.com/uploads/articles/y1z4ur3gy9omtoad2vll.png)

---

Kubernetes 可以在三个维度上进行扩展——增加集群中的 Pod 数量、Pod 大小和节点。它可以根据服务器指标(如 CPU 和内存)或自定义指标(如每个 Pod 每秒的请求数)进行扩展。

它们如何工作 HPA 和 VPA 的工作基于使用 prometheus、metrics server 和其他系统的利用率得出的指标

---

VPA/金发姑娘

受众:开发者

对于简单的 Deployment 或 ReplicaSet(无状态),VPA 会建议请求的 pod 资源的值,并将这些值作为未来部署的建议。或者,我们可以配置 VPA 以将这些值自动应用到我们的部署对象。

注意: VPA 还不能正确支持有状态的工作负载

详细信息https://www.densify.com/kubernetes-autoscaling/kubernetes-vpa

Goldilocks 使用 VPA 中的 Recommender 进行推荐。 Goldilocks 生成的建议基于一段时间内 pod 的历史使用情况,因此您的决策基于多个时间点。

Goldilocks 在仪表板中显示了两种类型的建议。这些建议基于 Kubernetes 服务质量 (QoS) 类。使用 Goldilocks,我们从历史数据中生成两种不同的 QoS 推荐类别:

• 对于 Guaranteed,我们从推荐中获取目标字段,并将其设置为该容器的请求和限制。这保证了容器请求的资源在它被调度时将可供它使用,并且通常会产生最稳定的 Kubernetes 集群。

• 对于 Burstable,我们从 VPA 对象将请求设置为 lowerBound 并将限制设置为 upperBound。调度程序使用请求将 pod 放置在节点上,但它允许 pod 在被杀死或限制之前使用更多资源达到限制。这有助于处理尖峰工作负载,但过度使用会导致过度配置节点。

详细信息https://www.civo.com/learn/fairwinds-goldilocks-kubernetes-resource-recommendation-tool

---

HPA

受众:开发者

HPA 通过运行同一 pod 的更多副本来水平扩展应用程序 pod(假设托管应用程序支持通过复制进行水平扩展)。

注意: 使用 HPA 时,要扩展的 pod 的无状态性方面的幂等性和可扩展性很重要

详细信息https://www.kubecost.com/kubernetes-autoscaling/kubernetes-hpa/

---

集群自动缩放器

受众:运营商

当存在由于资源短缺而无法调度的 Pod 时,集群自动扩缩器会增加集群的大小。它可以配置为不扩大或缩小超过一定数量的机器。

_注意:_集群自动缩放器需要由正在使用的 kubernetes 风格支持,并且通常不是 vanilla kubernetes 的一部分。

详细信息https://medium.com/kubecost/understanding-kubernetes-cluster-autoscaling-675099a1db92

---

扩展应用程序/无服务器工作负载

受众:运营商或基础设施提供商

在无服务器计算中,扩展是根据应用程序本身进行的。例如,Lambda 可以自动以指数方式扩展以应对突发流量。之后,线性达到并发限制。这些限制适用于区域中的所有功能,因此需要注意应用程序中的最大并发实例低于限制。并发限制鼓励执行时间短的细粒度函数。

WHO

KEDA 提供了一种基于从事件代理观察到的需求来扩展事件驱动应用程序的方法。 KEDA 扩展了原生 Kubernetes Horizontal Pod Autoscaler 的能力,是一个开源的 CNCF 孵化项目。

科达的工作原理

在扩展事件驱动的微服务时,消费者输入队列上的消息数量本质上就是需要处理的事件数量。消息计数或队列积压是对给定微服务的需求的一个很好的指标,因为:

• 如果微服务的输入队列备份有大量消息,我们知道需求很高,应该扩展微服务。

• 如果消息计数低(低于定义的阈值),则需求低,应缩减微服务。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--uOp8XK2f--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to- uploads.s3.amazonaws.com/uploads/articles/5d3rr6jxpk1g2lk7ofxm.png)

https://keda.sh/docs/2.5/concepts/

案例研究https://solace.com/blog/scaling-microservices-with-kubernetes-keda-and-solace/

---

有用的链接

https://blog.turbonomic.com/kubernetes-resource-management-best-practices

https://cast.ai/blog/guide-to-kubernetes-autoscaling-for-cloud-cost-optimization/