文章目录
- 前言
- VPA简介
- 简单理解
- 详细解释
- VPA的优缺点
- 优点
- 1.自动化资源管理
- 2.资源优化
- 3.性能和稳定性提升
- 5.成本节约
- 6.集成性和灵活性
- 缺点
- 1.Pod 重启影响可用性
- 2.与 HPA 冲突
- 3.资源监控和推荐滞后：
- 4.实现复杂度：
- 核心概念
- Resource Requests 和 Limits
- 自动调节
- VPA 的工作原理
- VPA 组件
- VPA 使用场景
- 应用
- 环境
- 1.部署metrics-server及VPA
- （1）部署metrics-server
- （2）升级openssl（所有节点）
- （3）部署VPA
- 2.VPA策略
前言
有任何疑问或不懂的地方均可评论或私信，欢迎交流
VPA简介
官方链接
https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler
简单理解
与HPA类似，区别在于HPA自动控制的pod副本数量
而VPA则自动控制的是CPU 和 内存 的requests，从而允许在节点上进行适当的调度，以便为每个 Pod 提供适当的资源。
注: 不能与HPA（Horizontal Pod Autoscaler ）一起使用
这个是博主写的有关HPA的博客，有兴趣的可以看看
链接: HPA详细解释与应用
详细解释
在 Kubernetes（k8s）中，Vertical Pod Autoscaler（VPA）是一种自动调节 Pod 中容器资源请求（CPU 和内存）的工具。它可以根据 Pod 的实际使用情况自动调整这些资源请求，以确保应用程序具有足够的资源运行，并同时避免资源的浪费。
VPA的优缺点
优点
1.自动化资源管理
简化运维：VPA 自动调整 Pod 的资源请求，减少手动调整的工作量。
动态响应：能实时根据实际资源使用情况调整请求，适应负载变化。
2.资源优化
避免资源浪费：确保 Pod 只请求所需的资源，降低不必要的资源分配。
提高资源利用率：通过优化资源请求，增加集群中可用资源的数量，提高整体资源利用率。
3.性能和稳定性提升
防止资源不足：自动增加资源请求，确保应用在高负载时也能正常运行。
优化性能：通过合理的资源配置，确保应用程序性能得到保障。
5.成本节约
降低运营成本：通过精准的资源配置，减少过度配置带来的成本，提高资源利用效率。
6.集成性和灵活性
兼容性好：VPA 可以与 Kubernetes 中的其他工具（如 HPA）一起使用，以实现全面的自动扩展策略。
可配置性强：提供多种更新策略（如 Auto、Recreate、Initial），适应不同的应用场景。
缺点
1.Pod 重启影响可用性
重启开销：资源请求的更新通常需要重启 Pod，这可能会导致服务短暂不可用，影响用户体验。
滚动更新问题：在滚动更新过程中，如果频繁调整资源请求，可能会导致更新过程复杂化。
2.与 HPA 冲突
配置复杂
同时使用 VPA 和 Horizontal Pod Autoscaler (HPA) 时，可能会产生冲突，需要谨慎配置和管理。
负载模式不同
HPA 和 VPA 针对不同的负载模式（水平扩展 vs. 垂直扩展），混用时需要综合考虑应用负载特性。
3.资源监控和推荐滞后：
数据滞后 ：VPA 基于历史资源使用数据做出推荐，可能存在一定的滞后性，无法实时反映最新的负载变化。
推荐准确性：在负载波动剧烈的情况下，推荐值可能不够准确，导致资源配置不够理想。
4.实现复杂度：
依赖数据质量：VPA 的推荐依赖于准确的资源使用数据，集群监控和数据收集的质量对 VPA 的效果有直接影响。
维护复杂度：需要对 VPA 本身进行维护和监控，确保其正常运行和推荐的准确性。
核心概念
Resource Requests 和 Limits
Requests
容器启动时所需的最小资源量，Kubernetes 会基于 requests 来做调度决策。
Limits
容器能使用的最大资源量，防止单个容器使用过多资源。
自动调节
Vertical Scaling：不同于水平扩展（Horizontal Scaling）通过增加 Pod 数量来应对负载，垂直扩展（Vertical Scaling）是调整单个 Pod 的资源配额。
VPA 的工作原理
监控：VPA 通过监控 Pod 的实际资源使用情况来确定是否需要调整资源请求。
推荐：基于历史数据和当前使用情况，VPA 会生成资源请求的推荐值。
更新：VPA 可以自动更新 Pod 的资源请求，触发 Pod 重启使配置生效。
更新策略可以配置为以下几种：
Auto：自动更新 Pod。
Recreate：删除并重新创建 Pod。
Initial：只在 Pod 初始创建时设置资源请求。
VPA 组件
Recommender：收集资源使用数据并生成资源请求的推荐值。
Updater：负责执行资源请求的更新，可以根据策略决定是否重启 Pod。
Admission Controller：在 Pod 创建和更新时应用资源请求的推荐值。
VPA 使用场景
应用负载变化：适合那些资源需求动态变化的应用。
节省成本：通过合理配置资源请求和限制，避免资源浪费。
提高稳定性：确保应用有足够的资源应对高负载情况。
应用
环境
虚拟机
| Ip | 主机名 | cpu | 内存 | 硬盘 |
|---|---|---|---|---|
| 192.168.10.11 | master01 | 2cpu双核 | 4G | 100G |
| 192.168.10.12 | worker01 | 2cpu双核 | 4G | 100G |
| 192.168.10.13 | worker02 | 2cpu双核 | 4G | 100G |
版本 centos7.9
已部署k8s-1.27
1.部署metrics-server及VPA
（1）部署metrics-server
master上操作
wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/high-availability-1.21+.yaml
kubelet 证书需要由集群证书颁发机构签名
(或者通过向 Metrics Server 传递参数 --kubelet-insecure-tls 来禁用证书验证)。
更改文件
vim high-availability-1.21+.yaml
149行添加
解释
因为是虚拟机环境，这条命令是允许 kubelet 使用不安全的 TLS 连接，生产环境不建议使用，这里是便于快速部署和测试已看到效果。
kubectl apply -f high-availability-1.21+.yaml
watch kubectl get pods -n kube-system
耐心等待，如果一直起不来就先删除pod再重启个节点docker。
kubectl top nodes
kubectl top pods -n kube-system
这里就部署好了
（2）升级openssl（所有节点）
curl -o /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repo
yum install -y openssl-devel openssl11 openssl11-devel
检查下载的 OpenSSL新库版本
openssl11 version
查看旧版本路径
which openssl
查看新版本路径
which openssl11
删除系统默认版本,并创建一个软连接指向新版本
rm -rf `which openssl`
ln -s /usr/bin/openssl11 /usr/bin/openssl
查看默认版本，可以看到已经是新版本了
openssl version
（3）部署VPA
master节点
mkdir vpa
cd vpa
git clone https://github.com/kubernetes/autoscaler.git
cd autoscaler/vertical-pod-autoscaler/
ls hack/
bash ./hack/vpa-up.sh
cd ..
kubectl get pods -n kube-system
没有running就等一会
这样就好了
2.VPA策略
在VPA中，updateMode 是一个重要的配置选项，它决定了VPA如何应用其提供的资源建议。根据不同的设置，VPA可以采取不同的策略来更新Pod的资源配置：
Off：
VPA不会应用任何资源推荐，只是收集和显示数据。
Initial：
VPA只会在Pod创建时应用资源推荐。一旦Pod启动，即使后续有新的资源推荐，也不会再进行调整。
Recreate：
当VPA生成新的资源推荐时，它会终止当前的Pod并重新创建一个新的Pod，新Pod将采用最新的资源推荐。这种方式会导致服务短暂中断，但能确保立即应用新的资源设置。
Auto：
这是默认模式。在这种模式下，VPA会尝试在线调整运行中的Pod的资源请求和限制，而无需重启Pod。如果无法在线调整（例如，由于内核或Kubernetes版本的限制），则会选择重新创建Pod。
由于篇幅过长，关于模式的演示会单独出(水)一篇博客
