公众号关注 「奇妙的 Linux 世界」
设为「星标」，每天带你玩转 Linux ！
简介
之前的文章我们介绍了HPA（Horizontal Pod Autoscaler）的实现，HPA一般被称为横向扩展，与HPA不同的Vertical Pod Autoscaler ( VPA ) 会自动调整 Pod 的 CPU 和内存属性，被称为纵向扩展。VPA可以给出服务运行所适合的CPU和内存配置，省去估计服务占用资源的时间，更合理的使用资源。当然，VPA也可根据资源的使用情况“调整”pod的资源。
这里的调整我们用了双引号，因为他的实现机制是重建而不是动态增加。下面是一个实际的例子：假设我的memory limits是100Mi，但是现在已经用到了98Mi，如果再大的话就oom了，此时vpa会在垂直方向上提升你的memory limits的大小。这种vpa比较适合一些资源消耗比较大的应用，例如es，你给大了资源浪费，给小了，又不够。所以vpa就派上用场了。当然，vpa不像hpa默认集成在k8s里面的，需要你自己去配置的。
VPA 与 HPA
从根本上来说，VPA 和 HPA 之间的区别在于它们的扩展方式。HPA 通过添加或删除pod进行扩展，从而水平扩展容量。然而，VPA 通过增加或减少现有 Pod 容器内的 CPU 和内存资源来进行扩展，从而垂直扩展容量。下表更详细地解释了 Kubernetes VPA 和 HPA 之间的差异。
| 需要调整容量 | 水平缩放 (HPA) | 垂直缩放 (VPA) |
|---|---|---|
| 更多资源 | 添加更多 Pod | 增加现有 pod 容器的 CPU 或内存资源 |
| 资源较少 | 删除 Pod | 减少现有 Pod 容器的 CPU 或内存资源 |
工作原理
VPA 的组成部分
VPA 部署具有三个主要组件：VPA Recommender、VPA Updater和VPA Admission Controller。让我们看一下每个组件的作用。VPA Recommender：
监控资源利用率并计算目标值。
查看指标历史记录、OOM 事件和 VPA 部署规范并建议公平请求。根据定义的限制请求比例提高/降低限制。
VPA 更新程序：
驱逐那些需要新资源限制的 Pod。
如果定义了“updateMode: Auto”，则实现推荐器建议的任何内容。
VPA 准入控制器：
每当 VPA 更新程序逐出并重新启动 Pod 时，都会在新 Pod 启动之前更改 CPU 和内存设置（使用 Webhook）。
当 Vertical Pod Autoscaler 设置为“Auto”的 updateMode 时，如果需要更改 Pod 的资源请求，则驱逐 Pod。由于 Kubernetes 的设计，修改正在运行的 pod 的资源请求的唯一方法是重新创建 pod。
Kubernetes VPA 工作模式
用户配置VPA。
VPA Recommender 从指标服务器读取 VPA 配置和资源利用率指标。
VPA Recommender 提供 Pod 资源推荐。
VPA Updater 读取 Pod 资源建议。
VPA Updater 启动 Pod 终止。
部署意识到 Pod 已终止，并将重新创建 Pod 以匹配其副本配置。
当 Pod 处于重新创建过程中时，VPA 准入控制器会获取 Pod 资源推荐。由于 Kubernetes 不支持动态更改正在运行的 pod 的资源限制，因此 VPA 无法使用新的限制更新现有 pod。它会终止使用过时限制的 pod。当 Pod 的控制器向 Kubernetes API 服务请求替换时，VPA 准入控制器会将更新的资源请求和限制值注入到新 Pod 的规范中。
最后，VPA 准入控制器会覆盖对 Pod 的建议。在我们的示例中，VPA 准入控制器向 Pod 添加了一个“250m”CPU。
最佳实践
既然你知道了大致原理，让我们开始动手操作你吧
克隆代码
# git clone https://github.com/kubernetes/autoscaler.git
由于某些原因拉不到镜像，改yaml修改优先使用本地镜像
# cd autoscaler/vertical-pod-autoscaler/deploy
# sed -i 's/Always/IfNotPresent/g' recommender-deployment.yaml
# sed -i 's/Always/IfNotPresent/g' admission-controller-deployment.yaml
# sed -i 's/Always/IfNotPresent/g' updater-deployment.yaml
# 拉取镜像
# docker pull giantswarm/vpa-admission-controller:0.14.0
# docker pull giantswarm/vpa-recommender:0.14.0
# docker pull giantswarm/vpa-updater:0.14.0
# 修改tag
# docker tag giantswarm/vpa-updater:0.14.0 registry.k8s.io/autoscaling/vpa-updater:0.14.0
# docker tag giantswarm/vpa-recommender:0.14.0 registry.k8s.io/autoscaling/vpa-recommender:0.14.0
# docker tag giantswarm/vpa-admission-controller:0.14.0 registry.k8s.io/autoscaling/vpa-admission-controller:0.14.0
# cd autoscaler/vertical-pod-autoscaler/hack
# 安装脚本安装之前保证你的K8S集群的metrics-server已安装，并且openssl升级到1.1.1或更高版本
# ./vpa-up.sh等待安装完成
# kubectl get pods -n kube-system | grep vpa
kube-system vpa-admission-controller-75bffbf8d8-6hxqq 1/1 Running 0 5m9s
kube-system vpa-recommender-748c55b5bf-kqqjc 1/1 Running 0 4m34s
kube-system vpa-updater-679d5dcdd6-lslc7 1/1 Running 0 4m15s使用VPA，您需要为要自动计算资源需求的每个控制器插入一个Vertical Pod Autoscaler资源。这将是最常见的Deployment。VPA有四种运行模式
"Auto"：VPA 在创建 pod 时分配资源请求，并使用首选更新机制在现有 pod 上更新它们。目前这相当于"Recreate"（见下文）。一旦 pod 请求的免重启（“就地”）更新可用，它可能会被该"Auto"模式用作首选的更新机制。注意：VPA 的此功能是实验性的，可能会导致您的应用程序停机，当目前运行的pod的资源达不到VPA的推荐值，就会执行pod驱逐，重新部署新的足够资源的服务
"Recreate"：VPA 在创建 Pod 时分配资源请求，并在现有 Pod 上更新它们，当请求的资源与新建议有很大差异时（尊重 Pod 中断预算，如果定义）。这种模式应该很少使用，只有当您需要确保在资源请求发生变化时重新启动 Pod 时。否则，更喜欢这种"Auto"模式，一旦它们可用，就可以利用重新启动免费更新。注意：VPA 的此功能是实验性的，可能会导致您的应用程序停机
"Initial"：VPA 仅在创建 pod 时分配资源请求，以后不会更改它们
"Off"：VPA 不会自动更改 Pod 的资源需求。这些建议是经过计算的，并且可以在 VPA 对象中进行检查。这种模式仅获取资源推荐值，但是不更新Pod
创建一个updateMode: Auto 的VPA
# 将updateMode中的requests 改为 CPU：50m，Memory: 50Mi，同时将updateMode修改为Auto
# 创建一个pod和svc
# kubectl get pods -n vpa
NAME READY STATUS RESTARTS AGE
nginx-8454bb78d8-67pth 1/1 Running 0 9s
nginx-8454bb78d8-6efsh 1/1 Running 0 9s
# kubectl get svc -n vpa
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx NodePort 10.0.200.5 <none> 80:45425/TCP 15s
# 进行压测，压测到一半时，突然连接断了，说明POD被重新创建了
# ab -c 1000 -n 100000 http://192.168.0.191:45425/
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 192.168.0.191 (be patient)
apr_socket_recv: Connection reset by peer (104)
Total of 187078 requests completed
# 查看vpa
# kubectl describe vpa nginx-vpa -n vpa | tail -n 20
Conditions:
Last Transition Time: 2023-09-07T15:41:32Z
Status: True
Type: RecommendationProvided
Recommendation:
Container Recommendations:
Container Name: nginx
Lower Bound: #容器的最小估计值
Cpu: 100m
Memory: 262144k
Target: #目标估计是我们用于设置资源请求的估计
Cpu: 350m
Memory: 262144k
Uncapped Target: #无上限目标估计是在没有minAllowed和maxAllowed限制的情况下产生的目标估计
Cpu: 350m
Memory: 262144k
Upper Bound: #上限是容器的最大建议资源估计
Cpu: 2
Memory: 405160855
Events: <none>
# 查看pod被重新创建了 稍高的配置
# kubectl get pods -n vpa
NAME READY STATUS RESTARTS AGE
nginx-daecsfv8d8-see8h 1/1 Running 0 4m
nginx-daecsfv8d8-fsise 1/1 Running 0 3m已知的限制
每当 VPA 更新 Pod 资源时，都会重新创建 Pod，这会导致重新创建所有正在运行的容器。Pod 可以在不同的节点上重新创建。
VPA 无法保证它驱逐或删除以应用建议（在Auto和Recreate模式下配置时）的 pod 将成功重新创建。通过将 VPA 与Cluster Autoscaler结合使用可以部分解决这个问题。
VPA 不会更新不在控制器下运行的 Pod 的资源。
目前，Vertical Pod Autoscaler不应与CPU 或内存上的Horizontal Pod Autoscaler (HPA)一起使用。但是，您可以在自定义和外部指标上将 VPA 与 HPA结合使用。
VPA 准入控制器是一个准入 Webhook。如果您将其他准入 Webhook 添加到集群中，则分析它们如何交互以及它们是否可能相互冲突非常重要。准入控制器的顺序由 API 服务器上的标志定义。
VPA 会对大多数内存不足事件做出反应，但并非在所有情况下都会做出反应。
VPA 性能尚未在大型集群中进行测试。
VPA 建议可能会超出可用资源（例如节点大小、可用大小、可用配额）并导致Pod 处于挂起状态。通过将 VPA 与Cluster Autoscaler结合使用可以部分解决这个问题。
与同一 Pod 匹配的多个 VPA 资源具有未定义的行为。
总结
在本文中，我们使用VPA实现了基于POD对配置进行横向扩展，合理的使用可以提高对K8S的利用率，实现降本增效。但是目前的VPA也存在一些问题，我个人觉得VPA最大的问题是会对服务进行重建，重建过程中可能会有流量损失，但是好消息是从1.27 版本动态调整容器CPU和内存资源限制，无需重启应用程序，在可见的将来，会实现动态扩容更加顺滑，让我们一起期待~
本文转载自：「云原生运维圈」，原文：https://url.hi-linux.com/eWfd6，版权归原作者所有。欢迎投稿，投稿邮箱: editor@hi-linux.com。
最近，我们建立了一个技术交流微信群。目前群里已加入了不少行业内的大神，有兴趣的同学可以加入和我们一起交流技术，在 「奇妙的 Linux 世界」 公众号直接回复 「加群」 邀请你入群。
你可能还喜欢
点击下方图片即可阅读
再见 Tailscale，是时候拥抱下一代虚拟组网神器 NetBird 了
点击上方图片，『美团|饿了么』外卖红包天天免费领
更多有趣的互联网新鲜事，关注「奇妙的互联网」视频号全了解！
扫一扫
561
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
