基于k8s的纵向扩容介绍（VPA）
Vertical Pod Autoscaler VPA
- 介绍
- 安装
- 关于向后兼容性的注意事项
- 先决条件
- 安装命令
- 快速开始
- 测试您的安装
- 示例VPA配置
- 故障排除
- VPA的组成部分
- 删除
- alpha版本的已知限制
- 相关链接
- 原文
Vertical Pod Autoscaler VPA)
介绍
Vertical Pod Autoscaler（VPA）使用户无需为其pods中的容器设置最新的资源request。配置后，它将根据使用情况自动设置request，从而允许在节点上进行适当的调度，以便为每个pod提供适当的资源量。
使用名为VerticalPodAutoscaler的自定义资源定义对象配置自动缩放 。它允许指定垂直自动缩放的pod以及是否/如何应用资源建议。
要在群集上启用vpa，请按照下面介绍的安装步骤进行操作。
安装
关于向后兼容性的注意事项
在alpha期间，VPA CRD对象可能以不同版本之间的兼容方式发展。如果安装新版本的VPA，最安全的做法是删除现有的VPA CRD对象。请注意，如果您只是使用vpa-down.sh脚本拆除旧的VPA安装，则会自动执行此操作。
先决条件
- 强烈建议使用Kubernetes 1.9或更高版本。您的群集必须支持MutatingAdmissionWebhooks，默认情况下自1.9（#58255）启用。了解有关VPA Admission Webhook的更多信息。
kubectl应该连接到要安装VPA的群集。- 必须在群集中部署Metrics Server。阅读有关Metrics Server的更多信息。
- 如果您使用的是GKE Kubernetes群集，则需要授予您当前的Google身份 cluster-admin角色。否则，您将无权授予VPA系统组件额外的权限。
$ gcloud info | grep Account ＃获取当前的Google身份
Account：[[email protected]]
$ kubectl create clusterrolebinding myname-cluster-admin-binding --clusterrole = cluster-admin [email protected]
Clusterrolebinding“myname-cluster-admin-binding”created
- 如果您的群集中已安装了另一版本的VPA，则必须首先删除现有安装：
./hack/vpa-down.sh
安装命令
要安装VPA，请下载VPA的源代码（例如使用 git clone https://github.com/kubernetes/autoscaler.git）并在vertical-pod-autoscaler目录中运行以下命令：
./hack/vpa-up.sh
注意：脚本当前读取环境变量：$REGISTRY和$TAG。除非您要使用非默认版本的VPA，否则请确保不设置它们。
该脚本kubectl向集群发出多个命令，这些命令插入配置并在kube-system命名空间中启动所有需要的pod（请参阅 体系结构）。它还会生成并上载VPA Admission Controller在与API服务器通信时使用的机密（CA证书）。
快速开始
安装完成后，系统就可以为您的pod建议和设置资源请求。为了使用它，您需要为具有相似资源要求的每个逻辑pod组插入Vertical Pod Autoscaler资源。我们建议为每个要自动控制的部署插入VPA，并使用与部署使用的相同的标签选择器。VPA有三种运作模式：
"Auto"：VPA在创建pod时分配资源请求，并使用首选更新机制在现有pod上更新它们。目前这相当于"Recreate"（见下文）。一旦重启免费（“in-place”），pod请求的更新可用，"Auto"模式可以被用作优选的更新机制。"Recreate"：VPA在创建pod时分配资源请求，并在请求的资源与新建议明显不同时（如果已定义，则遵循Pod中断预算），通过逐出驱动来更新它们。只有在需要确保在资源请求发生更改时重新启动pod时，才应该很少使用此模式。否则更喜欢"Auto"可以利用免重启的更新模式。"Initial"：VPA仅在创建pod时分配资源请求，并且以后永远不会更改它们。"Off"：VPA不会自动更改pods的资源要求。计算建议并可在VPA对象中检查。
测试您的安装
检查Vertical Pod Autoscaler在集群中是否完全可操作的一种简单方法是创建示例部署和相应的VPA配置：
kubectl create -f examples/hamster.yaml
上面的命令创建了一个包含2个pod的deployment，每个pod运行一个请求100 millicores 的容器，并尝试使用略高于500millicores的容器。该命令还会创建一个VPA配置，其中包含与部署中的pod匹配的选择器。VPA将观察pod的行为，大约5分钟后，他们应该使用更高的CPU请求进行更新（请注意，VPA不会修改部署中的模板，但会更新pod的实际请求）。要查看VPA配置和当前建议的资源请求，请执行:
kubectl describe vpa
注意：如果您的群集的可用容量很小，则这些容器可能无法安排。您可能需要添加更多节点或调整examples / hamster.yaml以使用更少的CPU。
示例VPA配置
apiVersion: poc.autoscaling.k8s.io/v1alpha1
kind: VerticalPodAutoscaler
metadata:
name: my-app-vpa
spec:
selector:
matchLabels:
app: my-app
updatePolicy:
updateMode: "Auto"
故障排除
要诊断VPA安装问题，请执行以下步骤：
- 检查所有系统组件是否正在运行：
kubectl --namespace=kube-system get pods|grep vpa
上面的命令应该列出状态为Running的3个pod（推荐者，更新者和准入控制器）。
- 检查系统组件是否记录任何错误。对于上一个命令返回的每个pod，执行以下操作：
kubectl --namespace=kube-system logs [pod name]| grep -e '^E[0-9]\{4\}'
- 检查是否已创建VPA自定义资源定义：
kubectl get customresourcedefinition|grep verticalpodautoscalers
VPA的组成部分
该项目包括3个组成部分：
-
Recommender - 它监视当前和过去的资源消耗，并根据它提供推荐值容器的CPU和内存请求。
-
Updater - 它检查哪些托管窗格具有正确的资源集，如果没有，则检查它们，以便控制器可以使用更新的请求重新创建它们。
-
Admission Plugin - 它在新pod上设置正确的资源请求（由于Updater的活动而刚刚由其控制器创建或重新创建）。
有关建筑的更多信息，请点击此处。
删除
请注意，如果您停止在群集中运行VPA，则VPA已修改的pod的资源请求将不会更改，但任何新pod将获取控制器中定义的资源（即部署或复制），而不是根据先前的建议由VPA。
要停止在群集中使用Vertical Pod Autoscaling：
如果在GKE上运行，请清除在先决条件中创建的角色绑定：
kubectl delete clusterrolebinding myname-cluster-admin-binding
删除VPA组件：
./hack/vpa-down.sh
alpha版本的已知限制
- 每当VPA更新pod资源时，都会重新创建pod，这会导致重新启动所有正在运行的容器。可以在不同节点上重新创建pod。
- vpa不应与CPU或内存上的Horizontal Pod Autoscaler(HPA)一起使用。但是，您可以在自定义和外部指标上使用VPA和HPA。
- Auto模式中的VPA 只能用于在控制器（例如部署）下运行的pod，后者负责重新启动已删除的pod。 在Auto模式下，没有在任何控制器下运行的pod的模式下使用VPA 将导致删除该pod并且不会重新创建该pod。
- VPA准入控制器是一个admission webhook。如果您向群集添加其他admission webhook，则必须分析它们之间的交互方式以及它们是否可能相互冲突。准入控制器的顺序由APIserver上的标志定义。
- VPA会对某些内存不足事件做出反应，但并非在所有情况下都会发生。
- VPA性能尚未在大型集群中进行测试。
- VPA建议可能会超出可用资源（例如节点大小，可用大小，可用配额）并导致pod进入待处理状态。这可以通过将VPA与Cluster Autoscaler一起使用来解决。
- 与同一个pod匹配的多个VPA资源具有未定义的行为。
相关链接
- 设计方案
- API定义
原文
- https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler
欢迎加入QQ群：k8s开发与实践（482956822）一起交流k8s技术