Autoscaler 中 VPA 的设计与实现

Pod 自动垂直伸缩(Vertical Pod Autoscaler,VPA)是 K8s 中集群资源控制的重要一部分。它的主要目的有:

  • 通过自动化更新 Pod 所需资源(CPU、内存等)的方式来降低集群的维护成本
  • 提升集群资源的利用率,减少集群中容器发生 OOM 或 CPU 饥饿[1]的风险

本文以 VPA 为切入点,对 Autoscaler[2] 的 VPA 设计与实现原理进行了分析。本文源代码基于 Autoscaler HEAD fbe25e1[3]。

Autoscaler VPA 整体架构

Autoscaler 的 VPA 会根据 Pod 的资源真实用量来自动调整 Pod 的资源需求量。它通过定义 VerticalPodAutoscaler[4] CRD 来实现 VPA,简单来说,该 CRD 定义了哪些 Pod(通过 Label Selector 选取)使用何种更新策略(Update Policy)来更新以某种方式(Resources Policy)计算的资源值。 Autoscaler 的 VPA 由如下几个模块配合实现:

  • Recommender,负责计算每个 VPA 对象管理下的所有 Pod 的资源推荐值
  • Admission Controller,负责拦截所有 Pod 的创建请求,并依据 Pod 所属的 VPA 对象,重填 Pod 的资源值字段
  • Updater,负责 Pod 资源的实时更新

Recommender

Autoscaler 的 VPA Recommender 是以 Deployment 形式部署的。在 VerticalPodAutoscaler CRD 的 spec 中,可以通过Recommenders字段指定一个或多个 VPA Recommender(默认使用名为default的 VPA Recommender)。

VPA Recommender 的核心组成结构包括:

  • ClusterState表示整个集群的对象状态,主要包含 Pod 和 VPA 对象的状态,充当了一个本地缓存的作用
  • ClusterStateFeeder定义了一系列集群对象或资源状态的获取方式,这些获取的状态最终都会存储在ClusterState

VPA Recommender 会定期执行一次推荐资源值的计算,执行周期可由--recommender-interval参数指定(默认为 1 min)。执行期间,VPA Recommender 首先通过ClusterStateFeeder全量加载 VPA、Pod 资源和实时 Metrics 数据到ClusterState。最后 VPA Recommender 将计算的 Pod 资源推荐值写入至 VPA 对象。

Pod 资源的推荐值是通过 Autoscaler VPA 定义的推荐值算子(Estimator)计算。主要的计算方式围绕PercentileEstimator算子展开,该算子会根据 Pod 内每个容器的一组历史资源状态计算出一个分布,并取该分布的某个分位点(例如,95分位点)对应的资源值作为最终的资源推荐值。

Admission Controller

Autoscaler 的 VPA Admission Controller 以 Deployments 形式部署,并默认在kube-system命名空间下以名为vpa-webhook的 Service 提供 HTTPS 服务。

VPA Admission Controller 主要负责创建并启动 Admission Server,其整体执行过程如下:

  • 注册 Pod 和 VPA 对象的 Handler,负责处理各自对象的请求
  • 注册 Calculator,以获取 Recommender 中计算的资源推荐值
  • 注册 Mutating Admission Webhook,以拦截 Pod 对象的创建请求和 VPA 对象的创建、更新请求

针对拦截到的请求,Admission Server 会调用相关 Handler,将 Autoscaler VPA Recommender 计算的资源推荐值以 JSON Patch[5] 的方式回填至原始对象字段。 以 Pod 对象为例,其 Handler 对应的GetPatches方法如下:

// vertical-pod-autoscaler/pkg/admission-controller/resource/pod/handler.go

func (h *resourceHandler) GetPatches(ar *admissionv1.AdmissionRequest) ([]resource_admission.PatchRecord, error) {
        raw, namespace := ar.Object.Raw, ar.Namespace
        pod := v1.Pod{}
        err := json.Unmarshal(raw, &pod)
        // ...
    
        controllingVpa := h.vpaMatcher.GetMatchingVPA(&pod)  // 获取控制该 Pod 的 VPA 资源
        patches := []resource_admission.PatchRecord{}

        for _, c := range h.patchCalculators {
                partialPatches, err := c.CalculatePatches(&pod, controllingVpa)  // 根据每种 calculator 的计算方式返回 patch
                patches = append(patches, partialPatches...)
        }

        return patches, nil
}

Updater

Autoscaler 的 VPA Updater 以 Deployment 形式部署。VPA Updater 用于决定哪些 Pods 需要根据 VPA Recommender 计算的资源推荐值进行调整,VPA Updater 对 Pod 的资源调整采用驱逐再重建的方式(同时也考虑了 Pod Disruption Budget[6])。VPA Updater 自身并没有资源更新的能力,而是只负责驱逐 Pod,再次创建 Pod 时则依赖 VPA Admission Controller 来更新资源值。

每次资源更新调用的都是 VPA Updater 的RunOnce方法,该方法会枚举每个 VPA 资源及其对应的 Pods,筛选出在当前 VPA 中需要进行资源更新的 Pods 并对它们逐一进行驱逐。

// vertical-pod-autoscaler/pkg/updater/logic/updater.go

func (u *updater) RunOnce(ctx context.Context) {
        // ...

        vpaList, err := u.vpaLister.List(labels.Everything())  // 列出所有 VPA 资源
        vpas := make([]*vpa_api_util.VpaWithSelector, 0)
        for _, vpa := range vpaList {
                selector, err := u.selectorFetcher.Fetch(vpa)
                vpas = append(vpas, &vpa_api_util.VpaWithSelector{
                        Vpa:      vpa,
                        Selector: selector,
                })
        }

        podsList, err := u.podLister.List(labels.Everything())  // 列出所有 Pod 资源
        allLivePods := filterDeletedPods(podsList)  // 过滤掉所有被删除的 Pod(即 DeletionTimestamp 不为空的)
        controlledPods := make(map[*vpa_types.VerticalPodAutoscaler][]*apiv1.Pod)
        for _, pod := range allLivePods {
                controllingVPA := vpa_api_util.GetControllingVPAForPod(pod, vpas)  // 获取当前 Pod 对应的 VPA 资源
                if controllingVPA != nil {
                        controlledPods[controllingVPA.Vpa] = append(controlledPods[controllingVPA.Vpa], pod)
                }
        }

        for vpa, livePods := range controlledPods {
                evictionLimiter := u.evictionFactory.NewPodsEvictionRestriction(livePods, vpa)
                podsForUpdate := u.getPodsUpdateOrder(filterNonEvictablePods(livePods, evictionLimiter), vpa)  // 获取需要进行资源更新的 Pod 以进行驱逐
                for _, pod := range podsForUpdate {
                        if !evictionLimiter.CanEvict(pod) {  // 判断是否能驱逐
                                continue
                        }
                        evictErr := evictionLimiter.Evict(pod, u.eventRecorder)  // 执行驱逐
                }
        }
}

更新优先级

在上述方法的最后,VPA Updater 通过getPodsUpdateOrder方法返回一个需要资源更新的 Pods 列表,列表中的 Pod 是按照更新优先级从高到低排序的。

Pod 的更新优先级是通过GetUpdatePriority方法计算的,其返回值类型PodPriority中的ResourceDiff字段表示了所有资源类型差值(请求值与推荐值差的绝对值)的归一化总和。最后在使用更新优先级对 Pod 进行排序时,ResourceDiff就是排序所使用的标准。

// vertical-pod-autoscaler/pkg/updater/priority/priority_processor.go

func (*defaultPriorityProcessor) GetUpdatePriority(pod *apiv1.Pod, _ *vpa_types.VerticalPodAutoscaler, recommendation *vpa_types.RecommendedPodResources) PodPriority {
        // ...
        
        totalRequestPerResource := make(map[apiv1.ResourceName]int64)      // 请求资源的总值,按资源类型分类
        totalRecommendedPerResource := make(map[apiv1.ResourceName]int64)  // 推荐资源的总值,按资源类型分类

        for _, podContainer := range pod.Spec.Containers {
                recommendedRequest := vpa_api_util.GetRecommendationForContainer(podContainer.Name, recommendation)  // 获取该容器对应的推荐值
    
                for resourceName, recommended := range recommendedRequest.Target {
                        totalRecommendedPerResource[resourceName] += recommended.MilliValue()
                        lowerBound, hasLowerBound := recommendedRequest.LowerBound[resourceName]
                        upperBound, hasUpperBound := recommendedRequest.UpperBound[resourceName]
                        
                        // 几种边界情况的判断...
                }
        }
        resourceDiff := 0.0  // 所有资源类型差值的总和
        for resource, totalRecommended := range totalRecommendedPerResource {
                totalRequest := math.Max(float64(totalRequestPerResource[resource]), 1.0)
                resourceDiff += math.Abs(totalRequest-float64(totalRecommended)) / totalRequest  // 对每种资源类型差值都进行了归一化
        }
        return PodPriority{
                ResourceDiff:            resourceDiff,
                // ...
        }
}

驱逐事件

对于每一个需要更新资源值的 Pod,VPA Updater 都会先检测该 Pod 是否能被驱逐,若能,则将其驱逐;若不能,则跳过此次驱逐。 VPA Updater 对 Pod 是否能够被驱逐的判断是通过CanEvict方法来完成的。它既保证了一个 Pod 对应的 Controller 只能驱逐可容忍范围内的 Pod 副本数,又保证了该副本数不会为 0(至少为 1)。

// vertical-pod-autoscaler/pkg/updater/eviction/pods_eviction_restriction.go

func (e *podsEvictionRestrictionImpl) CanEvict(pod *apiv1.Pod) bool {
        cr, present := e.podToReplicaCreatorMap[getPodID(pod)]  // 根据 pod ID 找到其控制器
        if present {
                singleGroupStats, present := e.creatorToSingleGroupStatsMap[cr]
                if pod.Status.Phase == apiv1.PodPending {
                        return true  // 对于处于 Pending 状态的 Pod,可以被驱逐
                }
                if present {
                        shouldBeAlive := singleGroupStats.configured - singleGroupStats.evictionTolerance  // 由 evictionToleranceFraction 控制,表示最多能驱逐的副本数
                        if singleGroupStats.running-singleGroupStats.evicted > shouldBeAlive {
                                return true  // 对于可容忍的驱逐数量之内,可以被驱逐
                        }
                        if singleGroupStats.running == singleGroupStats.configured &&
                                singleGroupStats.evictionTolerance == 0 &&
                                singleGroupStats.evicted == 0 {
                                return true  // 若所有 Pods 都在运行,并且可容忍的驱逐数量过小,则只可以驱逐一个
                        }
                }
        }
        return false
}

Evict函数负责对一个 Pod 进行驱逐,即指对目的 Pod 发送一个驱逐请求。

总结

Autoscaler 是 Kubernetes 社区维护的一个集群自动化扩缩容工具库,VPA 只是其中的一个模块。目前许多公有云的 VPA 实现,也都与 Autoscaler 的 VPA 实现类似,比如 GKE 等。但 GKE 相比 Autoscaler[7] 还存在一些改进:

  • 在资源推荐值计算时,额外考虑了支持最大节点数与单节点资源限额
  • VPA 能够通知 Cluster Autoscaler 来调整集群容量
  • 将 VPA 作为一个控制面的进程,而非 Worker 节点中的 Deployments 但无论如何,Autoscaler 的 VPA 是基于对 Pod 的驱逐重建完成的。在部分对驱逐敏感的场景下,Autoscaler 其实并不能很好的胜任 VPA 工作。面对这种场景时,就需要一种可以原地更新 Pod 资源的技术了。

参考链接

  1. https://en.wikipedia.org/wiki/Starvation_(computer_science)
  2. https://github.com/kubernetes/autoscaler
  3. https://github.com/kubernetes/autoscaler/tree/fbe25e1708cef546e6b114e93b06f03346c39c24
  4. https://github.com/kubernetes/autoscaler/blob/fbe25e1708cef546e6b114e93b06f03346c39c24/vertical-pod-autoscaler/pkg/apis/autoscaling.k8s.io/v1/types.go#L53
  5. https://jsonpatch.com/
  6. https://kubernetes.io/docs/concepts/workloads/pods/disruptions/
  7. https://cloud.google.com/kubernetes-engine/docs/concepts/verticalpodautoscaler
  8. https://shawnh2.github.io/post/2023/09/30/vpa-in-autoscaler.html

关于 Greptime 的小知识:

Greptime 格睿科技于 2022 年创立,目前正在完善和打造时序数据库 GreptimeDB,格睿云 GreptimeCloud 和可观测工具 GreptimeAI 这三款产品。

GreptimeDB 是一款用 Rust 语言编写的时序数据库,具有分布式、开源、云原生和兼容性强等特点,帮助企业实时读写、处理和分析时序数据的同时降低长期存储成本;GreptimeCloud 可以为用户提供全托管的 DBaaS 服务,能够与可观测性、物联网等领域高度结合;GreptimeAI 为 LLM 量身打造,提供成本、性能和生成过程的全链路监控。

GreptimeCloud 和 GreptimeAI 已正式公测,欢迎关注公众号或官网了解最新动态!

官网:https://greptime.cn/

GitHub: https://github.com/GreptimeTeam/greptimedb

文档:https://docs.greptime.cn/

Twitter: https://twitter.com/Greptime

Slack: https://greptime.com/slack

LinkedIn: https://www.linkedin.com/company/greptime/

TIOBE 2023 年度编程语言:C# 某中学采购“智能互动宣泄仪”——实则为任天堂 Wii 的套壳 女高管开除员工事件后续:公司董事长称员工“惯犯”并质疑“学历简历造假” 开源神器 LSPosed 宣布停更,作者称遭受大量恶意攻击 被女高管违法开除员工发声,因反对用盗版 EDA 工具设计芯片遭针对 Linux Kernel 6.7 正式发布 罗永浩称“荣耀任意门”抄袭锤子开源软件 One Step 中文 JDK 教程网站正式上线,助力开发者掌握 Java 编程语言 2024 年,Linux 内核的开发语言是否要从 C 转换为 C++ R 语言社区知名开发者“谢益辉”被 RStudio/Posit 解雇
{{o.name}}
{{m.name}}

猜你喜欢

转载自my.oschina.net/u/6839317/blog/10305144