网站域名分析,如何建设一个专业的网站,chatgpt 链接,微信公众号怎样发布wordpress关注【云原生百宝箱】公众号#xff0c;快速掌握云原生 Kubernetes提供了多种自动伸缩机制#xff0c;例如HPA#xff08;Horizontal Pod Autoscaling#xff09;#xff0c;可以根据不同情况动态调整Pod副本数量。此功能使 Pod 能够有效地处理当前流量#xff0c;而无需…关注【云原生百宝箱】公众号快速掌握云原生 Kubernetes提供了多种自动伸缩机制例如HPAHorizontal Pod Autoscaling可以根据不同情况动态调整Pod副本数量。此功能使 Pod 能够有效地处理当前流量而无需管理员不断干预来调整副本数量。
除了HPA之外Kubernetes还提供了其他相关机制例如VPAVertical Pod Autoscaler、CACluster Autoscaler和CPACustom Pod Autoscaler。在本文中我们将探讨这些类别重点关注三个方面 1. 适用场景 2. 触发条件 3. 调整目标
我们将深入研究每个机制的这三个维度。 HPA水平 Pod 自动缩放器
适用场景
Deployment/ReplicaSet 可以部署 Pod 的多个副本但固定数量缺乏灵活性尤其是当应用程序流量根据特定时段波动时。在这种场景下你可以使用HPAHorizontal Pod Autoscaler[1]来动态调整Pod的数量。
触发条件
HPA 是 Kubernetes 中的内置控制器。它与API Server通信以确定是否调整Pod的数量增加或减少。当 Metrics Server 安装在环境中时它可以利用 CPU/内存等资源使用指标来做出决策。这些指标与 Pod 中配置的 CPU/内存请求进行比较以确定是否超出阈值。此外可以根据总体 Pod 使用情况或特定容器使用情况来计算使用情况。
调整目标
HPA 调整 Pod 的数量。 有多个参数包括Behaviour可以调整允许你指定每次调整时 Pod 数量应变化的百分比或绝对值。 除了默认的资源使用情况外HPA 还可以结合 KEDAhttps://keda.sh/等指标或项目来提供不同角度的决策。 VPA垂直 Pod 自动缩放器
适用场景
与水平扩展副本数量以处理流量的 HPA 不同VPA[2]会调整各个实例的资源使用情况例如 CPU 和内存。将新应用程序部署到 Kubernetes 时通常会遇到配置资源请求/限制设置的困难。VPA持续观察实例的资源使用情况并执行相关操作。这些操作可能涉及调整设置和重新启动 Pod或者只是提供建议而不重新启动 Pod。后者依赖Operator根据观察到的资源使用情况收集和修改Deployment文件。
触发条件
在环境中部署 VPA 控制器后你可以创建 VPA 来指定需要观察哪些Deployment。VPA 主要侧重于观察和计算 CPU/内存请求/限制设置的适当数字。观察这一点需要时间并且基于太短的收集时间获得的结果可能会导致不适当的使用估计。
调整目标
VPA 以每个 Pod 为基础运行。它不会修改 Pod 副本的数量但会估计 CPU/内存请求/限制使用情况。 Auto/Recreate模式下设置相应的值并重启Pod。在Off模式下仅执行计算而不重新启动 Pod。
CPA集群比例自动缩放器
适用场景
HPA和VPA是管理资源使用、基于水平和垂直方面调整应用程序以满足当前需求的常用方法。CPA[3]旨在根据集群规模水平扩展 Pod 副本数量。一个常见的例子是 DNS 服务。CPA可以根据当前集群规模动态调整DNS实例数量集群规模可以是节点数也可以是整体CPU容量。 触发条件
与HPA/VPA关注应用本身的资源使用情况不同CPA的触发调整是根据节点自身的能力进行的。设置从应用程序的角度开始探索每个副本可以处理多少个节点实例或总 CPU 实例。相关设置包括coresPerReplica和nodesPerReplica。当前合适的 Pod 数量使用以下公式计算 副本 max(ceil(核心 * 1/coresPerReplica), ceil(节点 * 1/nodesPerReplica)) 调整目标
CPA根据配置的coresPerReplica和nodesPerReplica以及当前节点规模计算出合适的数量。它动态调整目标 Pod 副本。
CA集群自动缩放器
适用场景
之前的HPA、VPA、CPA等方法都是根据各种情况动态调整Pod的数量。CA[4]则根据具体情况动态调整节点数量。例如当 Pod 充分利用所有节点上的资源没有为新部署留下 CPU/内存资源时CA 会动态添加新节点以提供额外的计算资源。反之当节点资源使用率较低时可以动态移除节点尤其是在云环境中以节省成本。
在节点移除过程中常见的做法是使用类似于Drain的方法。必须注意PodDisruptionBudget和TerminationGracePeriodSeconds等参数以确保应用程序过渡期间对现有服务的影响最小。 Drain 命令能否成功完成取决于该节点上的所有 Pod 是否都被成功移除。如果有 Pod 需要较长的时间terminationGracePeriodSeconds来处理 Grafecul 关闭过程则节点驱逐的时间取决于这些 Pod 是否顺利终止。 触发条件
一个常见的触发场景是当任何 Pod 由于 k8s 集群资源不足而进入 Pending 状态时。此操作会提示 CA 控制器添加新节点。一旦新节点成功添加到 Kubernetes 集群并变为 Ready应用程序就可以顺利部署和运行。相反当节点使用率在一定时间内低于阈值时可以移动目标节点上的 Pod 并删除该节点。 不同的 Kubernetes 平台有不同的实现因此需要确认具体的实现和相关设置例如将新节点均匀分布在不同的可用区或使用注释来防止特定应用程序被驱逐。所有设置均取决于平台。 调整目标
CA 根据每个节点进行调整。 当一个节点被删除时所有正在运行的 Pod 都会被重新调度到其他节点。
总结
Kubernetes提供了多种自动伸缩机制如HPA水平Pod自动缩放器可根据不同情况动态调整Pod副本数量。此功能使Pod能够有效处理当前流量无需管理员不断干预。除了HPA外还有VPA垂直Pod自动缩放器、CA集群比例自动缩放器和CPA自定义Pod自动缩放器。它们分别从水平和垂直方面以及整个集群规模角度调整Pod和节点数量。这些机制相互补充可根据需求灵活运用。 1. 上述所有机制并不相互排斥。例如某个应用类别可以使用HPA来调整Pod数量并与CA相辅相成动态调整节点数量以满足需求。 2. 由于这些操作导致 Pod 和节点数量的增加或减少可能会出现意外的 Pod 分发场景。在这种情况下可能需要像descheduler[5]或Affinity、SpreadConstraint 这样的机制来平衡部署情况。
引用链接
[1] HPAHorizontal Pod Autoscaler: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/[2] VPA: https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler[3] CPA: https://github.com/kubernetes-sigs/cluster-proportional-autoscaler[4] CA: https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler[5] descheduler: https://github.com/kubernetes-sigs/descheduler
- END - 推荐阅读 叮你收到一份来自CNCF的云原生景观简介 要魔改Kubernetes我们可以从哪里扩展 问题排查太烦心试试GPT的超能力 Copa无需重建镜像直接修补容器漏洞 玩转K8s网络16张图带你从小白到专家 1000节点集群5秒搭建好 流量何处来又往何处去这次一目了然 Kubernetes CNI 插件选型和应用场景探讨 块/文件/对象存储难统一管理试试这个集大成者 GPU越来越难买如何提高利用率 监控外部服务太复杂ServiceMonitor 和 PrometheusRule有妙招 容器快了却不安全了Rootless 安排上
