Soul容器集群成本治理实践

见贤思齐

Soul容器集群成本治理实践 Soul 运维 Soul技术团队 Soul技术团队 Soul的技术实践分享 6篇内容 2024年09月29日 15:36 上海 背景经过过去几年的发展，Soul的业务现如今已全面拥抱上云，99%的业务部署在阿里云的ack容器服务中，Soul运维团队管理着多个容器集群，并且在上一轮业务发展过程中，考虑到业务的快速迭代，策略性放宽了集群内资源的管控，随着业务的增长，容器集群内资源愈发臃肿，因此需要一轮“成本战役”对其进行“瘦身”，并期望建立持续性的成本运营机制。治理难点与方向先看看容器集群成本组成，除master、etcd等固定组件外，成本主要来自于集群中的worker节点，worker节点上承载多个应用Pod，如下图为例，可以将单个worker上的CPU成本来源描述为：系统组件占用 + Pod占用 + 冗余资源 Kubelet等系统组件占用资源基本恒定，且优化空间有限，因此，我们将优化重心放在提升服务资源使用率和资源池的利用率上，业界常规的做法是进行服务和资源池的横纵向缩容，但在此之前，我们需要跨越一些障碍。障碍一：HPA节点扩展无法应对流量洪峰在固定时间点，Soul的一些业务场景存在流量洪峰，例如零点时lovebell次数的初始化，此时请求量瞬间陡增，持续几分钟后回落。常规的HPA配置在负载升高后才会触发扩容，当请求来临剧烈且持续时间较短时，新扩节点来不及在高峰期介入服务。为避免高峰期过载，我们不得不预先提高服务的冗余。障碍二：服务间资源抢占，影响业务稳定性业务发展初期，我们对部分资源池进行了在离线混布和Burstable质量类型的部署，以平衡成本和性能。随着业务发展，业务对稳定性的要求提升，先前的架构逐渐不适应当前的业务场景，以致成了成本治理之路的“拦路虎”。障碍三：资源池按高峰期标准保有资源，存在大量浪费 Soul业务具有明显的潮汐波动特征，白天用户活跃度比较稳定，晚上某一时刻达到峰值后逐步回落至谷底。为了确保业务连续性，资源池保有资源须按高峰期标准进行规划，并留有充足的冗余空间，但这导致资源浪费严重。障碍四：治理简单，运营复杂公司秉持业务优先理念，资源使用不适合过度限制，导致业务系统整体处于熵增状态。要持续保持资源使用在合理水平，治理仅是基础，还需建立并维护良好的运营机制。我们需要探索一套适合Soul业务场景的资源使用保持机制，否则集群维护将问题频出。在明确以上问题症结后，我们拟定了优化方向，先着力扫清眼前的障碍，主要从以下三个方向入手：服务治理：包括弹性伸缩优化、服务绑核、服务隔离等，并接入热点打散重调度，以保持资源使用始终处于正常水平，便于后续缩容优化升级资源池弹性伸缩：调研弹性伸缩工具，使资源池具备灵活伸缩节点的能力，降低高低峰期资源冗余差异，减少整体资源冗余量优化实施并建立巡检机制：系统性地对服务进行缩容、降配，尝试建立资源使用观测保持机制，使运研团队具备实时感知、管理资源成本变化的能力，提高运研人员对成本的敏感度和控制力服务治理弹性伸缩优化传统管理应用实例数的方法有固定实例数、HPA和CronHPA三种，其中原生HPA应用最为广泛，为解决原生HPA面临的弹性滞后的问题，ack容器集群提供了一种基于历史指标预测弹性节点数的管理方法--AHPA。我们对这几种方法进行了整理，优缺点如下：在Soul的业务场景，业务流量通常遵循凌晨低、白天稳定、晚间高的潮汐波动曲线。HPA能够保证服务在任何时间保持较高的资源使用率，而在零点峰值来临前，可以通过CronHPA扩充服务的资源储备，相较于AHPA的弹性敏感缺陷，HPA为主、CronHPA为辅的方案更能满足我们的需求。为了实现HPA和CronHPA协同运行，首要解决其无法相互感知的问题，为此我们联合基础架构团队，优化了HPA+CronHPA的协同机制。具体做法是，修改原生HPA的定义模板，将HPA配置为CronHPA的scaleTargetRef，CronHPA可明确了解并综合考虑任务的目标副本数、HPA的minReplicas、maxReplicas和desiredReplicas的参数，以及scaleTargetRef对象的当前副本数，最终，HPA将CronHPA作为自身的扩缩容对象，不再直接修改Deployment的副本数，而是通过HPA间接调整，以此避免两者间的冲突。 HPA+CronHPA协同方案，在一些场景替代了原有的HPA、CronHPA独立方案：常规时间内通过HPA自动扩缩容，而在峰值来临前通过CronHPA提前扩容，并在安全承载峰值压力后还原副本数配置，以充分利用了两种方案的优势。此外，为了提升CronHPA的易用性，我们通过常规巡检来评估服务的最优副本数组合，将24小时划分为多个时间段，取每段周期的峰值资源使用率进行计算，逐步调整，确保资源使用更加高效。服务分池基于资源池水位弹性伸缩设计，仅能保证Request CPU小于或等于目标核数的服务正常调度。否则，任何触发容器Pod调度的操作均存在一定风险，为了避免这种情况，我们对服务的资源池进行提前规划，不同Request CPU的服务部署在对应资源池。另一方面，针对一些非常规类型的服务，比如离线高负载服务、高内存要求服务和有状态的服务等，也根据实际情况分配相应资源池，减小其调度失败的风险。总结如下：无状态服务入驻常规资源池：根据服务的Request CPU，将其分配到对应目标核心数的资源池，目标核心数由Node配置决定，如32核Node可划分为4核、8核、14核和28核（预留4核用于系统资源）离线高负载服务迁移到固定资源池：对于长期高负载运行的离线服务，统一迁移到固定的资源池，以降低其对其他服务的影响有状态的服务迁移到专有资源池：对于无法承受Pod重启的服务，例如长时间运行的任务或需要持久化数据的服务，我们将其迁移到ECS或未开启弹性伸缩的资源池中特殊存核比服务迁移到专用资源池：部分服务对内存要求较高，存核比可能达到8:1、10:1或更高。对此，我们使用大内存Node创建专用资源池，以便服务运行热点打散重调度随着节点资源利用率的上升，部分固定节点在高峰期负载过高，影响了业务的稳定性。为解决这一问题，我们引入了Koord热点重调度策略。Koord组件通过Koord-descheduler模块实现主要功能，其中LowNodeLoad插件负责感知负载水位并实施热点打散重调度。与Kubernetes原生的Descheduler的插件LowNodeUtilization不同，LowNodeLoad基于节点的实际利用率进行决策，相比较LowNodeUtilization基于资源分配率进行决策，对热点节点的判定更加精准。 Koord-descheduler模块按周期运行，每个周期由以下三个阶段组成：数据收集：获获取集群中重调度决策所需的数据信息，比如集群中节点、节点使用率等策略插件执行：根据配置策略过滤待发起调度的目标节点和目标Pod容器驱逐迁移：对目标Pod发起驱逐操作LowNodeLoad插件的重要参数lowThresholds和highThresholds，将集群中节点分为空闲节点、正常节点和热点节点，Koord-descheduler在周期性检查中，对于满足highThresholds所有条件的节点，视为热点节点。持续一定时间后，Koord-descheduler会对这些节点中的Pod依次打分排序，并逐个发起驱逐操作，将其调度至空闲节点。其优先级排序标准如下：优先级（Priority）更低的PodQoS等级更低的Pod资源使用率更高的Pod，包括CPU使用率和内存使用率，二者权重相等创建时间更晚的Pod以下是生产环境中可能用到的Koord-descheduler配置，其核心功能如下：Koord对资源池ID为npf9c1ce23a0e147fdb76494xxxx的所有节点进行周期性检查（每分钟一次）。当节点的实际CPU使用率超过highThresholds（45%）时，将其加入待调度节点队列。如果队列中存在实际CPU使用率持续超过consecutiveAbnormalities（5分钟）的节点，则筛选出在evictableNamespaces范围内的节点，并按优先级排序进行驱逐，随后将这些节点调度至CPU使用率低于lowThresholds（30%）的节点。apiVersion: v1kind: ConfigMapmetadata: name: Koord-descheduler-config namespace: kube-systemdata: Koord-descheduler-config: | apiVersion: descheduler/v1alpha2 kind: DeschedulerConfiguration leaderElection: resourceLock: leases resourceName: Koord-descheduler resourceNamespace: kube-system deschedulingInterval: 60s dryRun: true profiles: - name: Koord-descheduler plugins: deschedule: disabled: - name: "*" balance: enabled: - name: LowNodeLoad evict: disabled: - name: "*" enabled: - name: MigrationController pluginConfig: - name: MigrationController args: apiVersion: descheduler/v1alpha2 kind: MigrationControllerArgs defaultJobMode: EvictDirectly maxMigratingPerNode: 1 maxMigratingPerNamespace: 1 maxMigratingPerWorkload: 1 maxUnavailablePerWorkload: 1 evictLocalStoragePods: true objectLimiters: workload: duration: 5m maxMigrating: 1 - name: LowNodeLoad args: apiVersion: descheduler/v1alpha2 kind: LowNodeLoadArgs lowThresholds: cpu: 30 memory: 100 highThresholds: cpu: 45 memory: 100 anomalyCondition: consecutiveAbnormalities: 5 evictableNamespaces: include: - soul-ops - default nodeSelector: matchExpressions: - key: alibabacloud.com/nodepool-id operator: In values: - npf9c1ce23a0e147fdb76494xxxx服务绑核考虑到GPU推理服务的成本，Soul算法业务采用了CPU与GPU进程分离的架构。由于CPU服务资源保有量大且对RT（响应时间）敏感，部分资源池的CPU使用率始终处于较低水平。经过研究发现，业务发展初期很多CPU服务配置为Burstable，Requests设定的资源逐渐不够用，开始上探Limit资源，导致服务间资源争夺严重，同一服务的不同Pod负载波动剧烈。虽然增加资源可以部分缓解，但依然偶现RT增加触发告警的情况。为彻底解决这一问题，我们对Burstable服务进行了统一改造。根据实际负载，统一调整Requests和Limits值，同时优化服务的存核比，以提升资源使用率。Soul弹性伸缩方案为了解决资源池在低峰期资源浪费的问题，我们需要引入一种弹性工具来管理资源伸缩。当前业界已有一些相对成熟的解决方案，包括K8s 社区的Cluster Autoscaler（CA）以及各大云厂商在CA基础上推出的节点伸缩产品。方案对比借助云原生特性，我们可以低成本接入云厂商的节点伸缩产品。阿里云ack容器服务提供了事件驱动的节点自动伸缩和节点即时弹性，两者均通过监听Pod调度失败状态自动扩展节点。然而，由于未预留Buffer，高峰期可能会出现服务Pending的问题，这对于Soul这种具有明显业务曲线的场景是难以接受的。此外，节点伸缩仅支持按量付费节点，其成本约为包年包月节点的1.5倍，整体成本节省效果十分有限。考虑到成本和性能，我们决定自研贴合Soul业务场景的弹性伸缩方案—SNAS（Soul Node AutoScaler）。与阿里云节点伸缩产品不同，SNAS将资源池的节点划分为固定节点和按量节点两类，其中SNAS只管理按量节点，固定节点则根据成本需求灵活调整。SNAS根据资源池的“水位”（即可被调度的Pod数量）自动调整按量节点数量，以确保资源池中始终有足够的资源可供调度。以下是几种方案的对比：可以看出，节点伸缩的优势在于其优秀的伸缩效率。SNAS由于采取先生产ECS再加入集群的策略，效率稍低于节点伸缩，但由于预留了Buffer，这一效率差距尚在可接受范围内。此外，SNAS弹性伸缩方案还具有以下优点：精准可控冗余：资源池保留受控的冗余资源，弹性伸缩次数较少，对业务连续性的影响较低更低的成本：固定节点承载大部分流量，使用包年包月节点，相较于按量付费节点成本更低安全缩容机制：缩容排水前的检测机制，保证服务始终有足量可用Pod，同时具备高效的缩容能力资源使用预测：具备资源使用预测能力，在资源消耗过快时能提前扩容(两种弹性方案下资源曲线对比)工作原理 SNAS弹性伸缩主要由四个核心模块组成：状态管理模块、扩容任务模块、缩容任务模块和核心计算模块。状态管理模块负责监听资源池状态，例如弹性预测水位、资源池配额、资源池水位、资源池维护状态等。当资源池状态满足扩缩容条件时，发送通知给扩缩容任务模块。扩缩容任务模块接到任务请求后，通过核心计算模块获取扩缩容的节点类型及数量等信息，随后调用阿里云API进行节点生产，生产完成后将新增节点加入资源池。(SNAS工作原理)水位范围保持 SNAS预设了资源池的目标核数、扩容阈值和缩容阈值，通过动态调整节点数量，确保水位始终在可控范围。当水位持续下降时，会根据扩容阈值自动增加节点，补足资源缺口；如果水位下降过快，则根据弹性水位预测结果提前批量增加节点，避免服务Pending。当水位上升时，会释放部分最近扩展的节点，确保资源利用率最优。如下图所示，对于目标核数4c的资源池，我们通常将水位范围保持在15-40之间，对应2-7台冗余节点，基本能保证业务正常调度。(资源池水位变化曲线)弹性水位预测在处理峰值流量时，Buffer的设置始终是个痛点。根据我们对近期水位的观察，特定时间点业务会大规模扩容，为了避免业务Pending，原则上需留有更多的Buffer资源，但这些资源在非峰值时段会被浪费，因此，我们引入了弹性水位预测的能力。 对于峰值流量我们分两种情况处理。不可预测的流量峰值，我们依据历史数据预留足够的资源，得益于云原生特性，我们基本能在3分钟内补足缺失的资源。可预测的流量峰值，如自然周和自然日的变化（如凌晨匹配次数重置等），SNAS弹性任务通过监测前一日和前一周的资源池水位变化，当水位消耗过快时，SNAS会启动模拟调度，计算资源池的负载需求，并自动扩展匹配数量的节点，以最大程度减少业务Pending的可能性。安全缩容机制在弹性伸缩中，最重要的是确保弹性缩容时业务的稳定性。对于在线服务，我们需要保证其缩容时有足够的可用节点。Kubernetes的默认调度规则，有优先缩容最近扩容Pod的特性，因此凌晨新扩节点上Pod往往比较稀疏。我们在常规时段使用固定节点承载服务，仅在业务高峰期提供弹性节点，而凌晨时弹性节点上的Pod会自然排空。基于这一特点，SNAS在选取待缩容节点时，会分析最近扩容的N个节点并打上三类标签：无Pod的节点、无重复Pod的节点和有重复Pod的节点。缩容时，优先缩容无重复Pod的节点，并同时释放所有无Pod的节点。如下图所示，SNAS弹性任务选取了Node 1至Node 4，缩容四台节点的同时最多只驱逐一个Pod。对于有重复Pod的节点，缩容前会驱逐重复Pod，更新其状态为“不可调度”，并在确保Replicas存在80%以上的可用Pod的情况下才进行缩容操作。(缩容时选取节点规则)巡检机制在完成服务治理后，我们基于治理结果进行了多轮降本操作，Soul的容器CPU资源成本显著下降，但根据历史经验，不加以干预，容器资源终将回归无序状态。为此，我们采取了一系列措施，持续维护和巩固降本成果。资源准入机制由于SNAS弹性任务的存在，资源池内Node的扩增是不设防的，容器资源的扩展主要的来源是服务的创建和扩容，我们对服务的创建、扩容增加了一道审批流程，由运维来审核资源扩展是否合理，另考虑到请求量徒增等异常情况，我们也增加了紧急扩容机制，在紧急时可不由运维审批直接扩容。资源池成本巡检在现实运维中，容器集群的详细成本通常在月初发布，但成本维护实际难以管理。我们希望能够日、周维度实时感知成本变化，从而更精准地进行资源冗余控制和服务负载治理。在资源冗余控制和服务负载治理两个方向，一方面监控资源池纬度的资源，每周感知资源池成本的变化，并将成本变化的来源精确到服务的操作推送到责任人；另一方面也对资源池的冗余进行监控，以日报的形式将资源池弹性状态推送给运维，并基于固定/按量节点的比例给出优化建议。(资源池成本报告)服务负载巡检由于Soul大部分服务已配置HPA或CronHPA，其他服务虽数量多但资源占用少，服务负载保持的重点主要在于提升HPA和CronHPA的合理性。具体包括以下几点：服务负载波动大，但未开启HPA、CronHPAHPA的最小副本数过高，峰值负载低于CPU阈值可预测流量洪峰未配置CronHPA，峰值负载与均值负载差异过大CronHPA的目标副本数设置过高，实际峰值负载低于期望的CPU阈值我们将上述规则加入服务负载巡检机制，按日检查集群中的潜在优化点，并通知相应的服务负责人跟进处理(服务负载巡检)治理成效回到文章开头提到的治理方向，我们的重点是提升资源池的资源利用率和服务的资源使用率。经过运维团队几个月的努力，接入SNAS的资源池资源使用率长期稳定在90%左右，比治理前提升了约12%。容器集群整体资源使用率在高峰期达到了27%，相比治理前也提高了7%。从成本角度来看，单个资源池的成本明显减少，过去一个月的容器整体资源成本相比三个月前下降了约20%。(资源利用率对比曲线)(资源使用率对比曲线)(某资源池成本变化)结语 Soul在容器集群成本的治理，整体思路是将治理拆分成两个部分，一方面利用SNAS弹性任务控制集群资源利用率，另一方面采取各种措施优化并运营已分配资源的负载，总体上来说，还是充分利用了云原生“即用即走”和容器服务“无状态“的特性，减少了资源的浪费。由于成本优化项目来临较突然，成本配套工具建设基本“各自为政”，尚未协力成完整的体系，下一步我们打算建设FinOps平台，将Soul所有资源成本可视化、优化工具、巡检策略纳入统一管理。