文章目录
- 前言
- 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。
由于篇幅过长,关于模式的演示会单独出(水)一篇博客