一、容量管理的设计理念
1、为什么要做容量管理？
1）容量风险未知
集群/资源池/Node容量水位缺乏可视化，稳定性难以保证
随着云原生和K8S普及，若没有很好的容量管理，我们就无法感知整个集群、整个资源池以及Node容量的水位变化，也无法得知是否有必要采购资源，无法察觉整体的资源风险。
- 容量变更根因难以追溯
有时我们在做一些发版或迭代时，会发现原本充足的资源突然出现紧缺。此时，若要查探容量何时变化或追溯变化的根因，存在一定难度，也比较复杂。
- HPA覆盖率低，业务稳定性难以保障
B站有很多活动和突发流量，但由于HPA的覆盖率比较低，业务容量弹性往往难以保障。
2）降本增效大背景
- 资源使用率低，迫切需要提高整体使用率
- 资源碎片化较为严重，资源无法得到充分利用
- 平台缺乏统一的资源协调能力
由于将物理资源分散到各个部门，如直播业务有独立的直播物理资源池，电商有专属物理资源，碎片化程度极高，所以平台统一协调资源的能力难免存在欠缺。
- 资源占用大头难以快速发现，治理困难
降本增效遵循二八原则，即20%的业务可能占了80%的资源。我们需要快速如何找出20%的业务，并推动其进行治理，这部分业务得到治理后往往收益较大。
2、不同部门的关注点
- 研发/部门：要有资源去做资源的扩容发布、蓝绿发布和回滚。希望部门的成本不能过高，避免资源浪费。
- SRE：服务的稳定性。在保证稳定性的情况下，聚焦服务资源的使用率，以达到降本增效的目的。
- 平台：需要统筹资源buffer，控制资源的超卖率，保证底层容量的稳定，从而实现降本增效的目标。
- 成本部门：资源使用率，账单、预算和成本。
3、容量管理面临的挑战
- 内部因素复杂，变动频繁
包括代码变更、配置变更、压测活动、多活切量、定时任务和缓存过期等，都可能导致容量模型发生改变。
- 外部场景多样，难以预知
B站活动比较多，运营也会进行不定时的推广，一些热门事件或话题都有可能导致容量的突增。
- 链路瓶颈点多，难以提前发现
无论是东西向流量还是南北向流量，整个链路比较长，因此上游服务、下游服务和中间件都可能遇到瓶颈。
- 应急依赖人工，恢复时间长
以上问题发生时，如果依靠人工应急，上游扩容可能会将下游直接打垮，容易引发二次故障。
4、容量管理的整体思路
整个容量体系的设计，从下到上分为几大部分，包括基础容量、弹性资源、合池和配额管理。
首先是基础容量，它包含平台关注的集群容量、资源池容量、Node容量，以及应用画像的相关数据。虽然我们将服务本身发版涉及到应用资源的容量视作基础容量，同时业务也会关注。
在这些基础容量之上，我们构建了一些弹性资源，包括VPA和HPA，还有我们的合池和配额管理。同时我们构建了整个容量可视化的一些页面，用于帮助我们的业务和平台更好地将自己的资源数据可视化，做一些资源的管理。
二、容量管理之降本增效
1、降本增效通用手段
2、具体方案介绍
1）弹性伸缩-VPA(Vertical Pod Autoscaler)
针对每一个服务，我们都有服务的软限和硬限，这是K8S的基本概念。应用CPU Used即应用的CPU的真实使用量。B站所有的硬限和软限都是通过我们的发布平台caster去指定，它们可能是业务基于经验设置的，设置的值不一定合理。随着业务和服务越来越多，这种不合理性就会越发明显，导致分配率非常高，但整体的使用率却不高。
如何解决这个问题？
我们认为，研发部门无需关注软限多少，只需关注需要多少资源。基于应用的真实CPU使用量和应用画像，评估它的服务等级、是否多活等指标，以此判断应动态分配多少软限。这种方法能提高整个服务的部署密度，提高整体资源池的使用率。
进行大型活动时，如果分配率已经很高，可以应用VPA的策略，把非核心服务（如 L2/L3的后台服务）用来降级，调低软限，给核心服务腾让资源。
我们通过VPA管理平台下发VPA策略，使其经过VPA-API组件。这个组件是一个中间代理，主要实现对K8S集群中VPA Generator对象的增删改查操作，负责汇总收集VPA相关的可观测数据。
VPA Generator主要负责拆解先前下发的具有相同画像的规则，如果下发一个L0等级的多活规则，它会拆解并创建很多对应VPA对象，最后通过VPA Recommender从监控系统中采集一些对应的应用资源指标，计算推荐值即合适的request值，并通过VPA Updater组件调整Pod的资源。
发布服务时也可能涉及到资源改变，VPA Webhook会监听类似事件，再动态调整Pod值。
①策略管理
包括VPA指标管理、模板管理和预估/对照组。
- VPA的指标管理：基于不同的指标例如CPU的使用量max、P99等做一些调整。
- VPA的模板管理：基于我们的一些应用画像，例如根据L0服务或L2服务等不同的服务画像做一些不同的模板和管理。
- VPA的策略预估与对照：分清哪种指标或哪部分对我们更优，因此我们会对不同的策略进行策略预估和对照，以便择优。
②数据运营
包括VPA的覆盖大盘、VPA执行记录和VPA策略分析。
- VPA覆盖大盘：分析整个资源池的覆盖率和执行记录，记录服务软限的调整幅度。
- VPA策略分析：调整后，通过可视化界面观察是否还存在问题。
③黑名单
整个服务的使用量一般会在活动时剧增，或某个服务上线了新功能，进行压测，都会导致整个容量数据变化。所以我们制作了黑名单机制，进行VPA策略避让，保证在非预期的情况下，不会对这些服务进行相关调整。
④预警
即使执行了VPA，通常也有可能出现不符合预期的情况，所以我们制作了失败率、覆盖率和冗余度的策略预警。如果本次调整有多处不符合预期，提前预警将递送给SRE和平台方，然后进行治理和排障。
2）PaaS合池
我们的漫画业务、直播业务和OGV业务都是独立的物理资源池，如下图所示，番剧的CPU分配率很高，而漫画跟直播的分配率相比较低。如果番剧需要资源去完成一些事情，漫画和直播往往不能满足，所以需要采购独立的预算，或额外申请云上资源。
所以我们认为业务不应关注底层资源，从而完成了PaaS的合池。合池后，业务更关注逻辑的配额管理，即整个配额的使用率。如果使用率过高或出现问题，业务可以解决，底层资源则由平台统一管控，进而平台的统一管控能力提升。
合池具体如何落地？可分为以下几步：
- 标准化治理
基于历史原因，不同的资源池使用不同策略，甚至配置、内核版本也各不相同，所以涉及到标准化的操作。首先，去除特殊约束，有些服务可能绑定了特殊的物理机发布。其次，不能配置nolimit相关的服务，因为合池完毕后如果某个服务压力比较大，且配得不合理，往往会增加物理机的压力，影响其他业务。同时，我们还进行了去cpuset化、统一操作系统内核和日志规范化的操作。
- 平台支撑
由于合池完毕后资源也不能无限使用，所以要基于合池后的不同组织进行逻辑配额管理，再整个大资源池覆盖VPA。
- 老板的支持
合池涉及到不同的部门，这一方面最重要的是需要老板的支持。自上而下进行的合池较依赖协同合作。
3）配额管理
容量平台提供了配额管理相关的策略下发能力，同时对接内部的CMDB业务树。基于组织业务的关系，可以设置不同的组织需要的资源数量。若使用超额，会联动发布平台，进而控制整体资源。如果资源不够，可能就无法发布或扩容。
降本增效的收益
- 成本：通过这些手段，我们实现了22年H1在线业务PaaS物理机的0新增，同时整个S12的活动保障实现了0采购。
- 平台：统一管控能力极大提升同时，快速支撑大型活动方面，活动数量攀升了不止10倍。以往进行大型活动支撑时，直播资源不足往往需要采购预算，周期漫长。目前我们可以通过协调资源和统筹调度尽快交付资源，时间也从原来的一个半月缩短到现在的一个小时或两个小时。PaaS的整体使用率获得较大提升。
- 业务：首先，对于小业务而言，由于本身资源池的资源较少，物理机不多，所以宕机对它的影响较大。合池后资源池的规模较大，服务相对分散，所以无论挂一台机器还是两台机器，对小业务的影响会大大降低。第二，业务整体的容量需求得到快速满足。资源紧张时，它也可以进行临时的蓝绿发布或者HPA超卖。
三、容量管理之稳定性
1、在线业务的典型特征
2、弹性伸缩-HPA(Horizontal Pod Autoscaler)
HPA的设计理念与VPA相似，包括策略管理、弹性预检、可观测和预警。
- 策略管理
因为HPA基于CPU使用率、内存使用率或QPS之类等指标进行管理，有些基于不同的应用画像进行管理。例如，针对L0和L1的服务，它们的CPU使用率若达到30%就应该扩容，至于非多活的服务，达到扩容标准的最小值则可能稍高。
- 弹性预检
配备HPA后也并非万无一失，因为HPA做弹性会涉及到下游及一些基础的技术组件，比如数据库会涉及到一些连接池，需要考虑它是否会满，是否会导致其他风险等。所以我们进行一些弹性预检的相关措施，包括临近值预检和容量风控等能力。
- 可观测
我们会观测异常记录和覆盖率，比如对L0服务的覆盖率如何，是否所有L0的服务都覆盖了HPA，HPA被触发时HPA的弹性质量如何等问题进行观测。
- 预警
我们设计了扩缩容的失败预警和HPA失效的预警，如果触发一些HPA扩容或缩容的事件，研发部门会收到相关时间通知，告知因服务压力或流量导致HPA发生变化。
1）HPA可视化
①HPA管控
包括HPA 的批量开启和禁用。保障大型活动时，往往会希望容量是稳态的，再基于稳态的容量进行压测，此时需要先关闭HPA，在低峰谷区进行压测。在资源不变的情况下，压测稳态能够支撑的量的数值。后续可能分为几轮压测，最后一轮压测会开启全部HPA，观察我们最终能支持的量，基于这些量预估容估。除此之外，还可能涉及HPA的增删改查能力。
②可视化
主要是HPA覆盖率，要确定整个HPA在不同区域和不同等级覆盖的应用数及覆盖率，对比指标数据和弹性实例。
弹性实例对比表明当前服务的实例数量，并展示一个关键数据。这个数据帮助我们基于HPA配置策略，确定弹性实例的最终数量。弹性实例受限于HPA的最大值控制。如果纯粹通过配置策略计算扩容的实例数，那么能够通过HPA扩至15个。但如果无最大限制，可能会直接扩至20个。因此，借助可视化能直接看出HPA的设置是否合理，了解整个HPA变化的实际趋势。
2）HPA并非可以无限扩容
HPA受限于连接池或下游服务有限的承载能力，因此我们排查了整个过程需要使用消息队列、Tidb、泰山KV、缓存以及中间件等相关组件。整体排查后，发现MySQL风险较大 ，因为大多数组件基本是集中式的代理，例如Tidb和泰山KV都是集中式的proxy部署，无连接池相关风险。缓存使用的redis和mc往往具有较大支持连接数，所以风险相对可控。MySQL 则不同，因此我们在弹性预检这方面增加对MySQL和连接池的预检。如果整个扩容导致MySql水位变高，就会进行相关提示。服务进行HPA扩容时，可能会导致下游的服务压力、下游雪崩，导致一些底层的中间件出现一定的问题或压力。
解决这个问题的整体思路：
一是HPA预检，二是基于全链路的弹性，三是对超出预期的流量做一些组件的限流。
3）容量巡检
容量巡检的作用在于，如果某些服务有风险，能够实现相关数据可视化。
针对不同的场景和不同的角色，关注点也不同。
业务更关注整个业务维度，例如使用率如何、有无风险应用等应用维度，能尽快找到这些列表，进而快速完成治理。配额管理方面，则包括整个配额的使用率和配额可调度的实例数量，帮助快速判断配额风险。
平台方则更关注资源池的分配率，如可调度的实例数峰值、资源使用率、资源池是否为单节点，还会关注整个VPA的调整失败率和冗余度。基于平台方的关注事项，我们制作了风险的巡检大盘，用以确定哪些资源有风险、哪些资源比较空闲、哪些资源急需治理等情况。
4）超载保护
即使有了这些保障，也无法保证万无一失。因为流量突发很常见，如佩洛西事件等热点事件导致B站的直播流量激增、超出预期，所以这方面需要依靠弹性资源。另一比较重要的手段则是依靠技术组件限流熔断和降解。
- 限流
目前限流主要包括分布式的全局限流和基于http、grpc、qps的限流，同时因为每个业务方基本上都会健全账号，所以我们会对一些比较核心的业务做基于caller即调用方的限流，从而避免因某一个业务的流量突发而导致整个账号体系出现问题。
另一方面，我们基于BBR进行动态限流，基于cpu使用率、成功qps和响应rt等限流，同时联动移动端并进行流控。如果服务端超出承受极限，我们会给移动端下发策略，驱使移动端做流控的控制，避免用户重试导致雪崩。
- 熔断
包括通过滑动窗口计算成功失败率以及熔断后需要进行的操作。
- 降级
基于多活进行跨可能区的降级，业务对这个操作无感，这也是我们做多活的一个好处。而对于Node SSR相关的降级，支持降级至静态页，业务也无感，但耗时相对长些。至于数据类的降级，假若AI方面的算法服务出了问题，我们可以进行兜底数据展示，但用户方的内容质量就有所下降。弱依赖降级时，部分服务会直接降级，不展示非核心数据。
四、容量管理之可视化运营
1、基础容量
我们更关注集群、资源池、Node和应用维度的数据，所以制作一些可视化图表，以便更快查看整个集群资源池和应用在这段时间内的变化趋势。
以资源池和Node为例，由于要控制超卖，所以要控制资源池和Node的容量水位和超卖率（Node也有部分热点）。
有些会触发二次调度，把上面的部分服务调用到非热点的服务中。应用则包括应用的资源使用量、使用率、实例数和单实例容器数，它的容器包括多少容器数，例如有一个Pod，它可能包含一个主容器和相关伴生容器，伴生有可能导致容量变化。我们基于这些数据制作趋势图，并在监控上保存应用的相关容量数据。与监控相比，因为数据点更加分散，所以保存期限更长，目前已保存了超过两年的容量数据。
2、业务组织容量
业务痛点
- 在进行降本增效时，如何快速找到资源占用的大头并优先治理；
- 哪些业务的实用率较低使用不合理；
- 是哪个业务扩容导致成本突增
- 容量治理的效果如何，
- 哪些业务的治理不符合预期
解决方案
根据以上痛点，我们设计了组织业务容量，基于内部的CMDB即组织业务数，通过聚合应用指标，从下往上逐渐递归，算出整个组织和业务的容量，呈现历史容量的变化趋势。例如，总容量是1万盒，1万盒属于整个直播业务，而直播的分支包含直播的房间、直播营收相关业务。
列出每一项所占的资源，就能清晰地感知哪些业务是资源占比的大头和占比总量。通过图片上的红线和红点，就能分析它的使用量与使用合理性。下图右方则呈现了整个容量的变化趋势，这样就能快速定位不合理的板块。同时，我们支持数据的一键下钻，作用同上。
3、容量事件
资源治理时，往往会遇到资源变少变空或不能发版的问题。以往查询这些问题根源，我们可能要翻遍各个平台。例如，查看是否有人在发布平台进行扩容或缩容操作，部分服务是否因压力过大触发HPA，或是否有人在管理平台中临时添加了机器导致容量变大。
由于平台数量多，业务SRE排查相当困难，所以我们做了容量事件相关的平台，以消费包括发布平台、HPA以及Node管理等整个变更平台的变更事件。通过变更事件，把数据消费到容量事件平台上，统筹观察这段时间业务的容量变更，因此容量事件是我们快速定位容量变化根因的重要途径。这样做的收益很显著，以往容量发生变化，业务必须联系SRE和平台。而现在无需这样操作，就能快速感知容量变化的根因，处理效率提升。
4、容量周报
容量周报分为部门周报和内部周报，业务部门更关注整体资源的用量以及资源使用率的变化。观察这些数据能更好地感知容量效果。除了降本增效以外，业务还关注稳定性，希望得知具体的风险应用有哪些，以及一周内哪些应用有怎样的容量变化。
对于内部来说，SRE和平台比较关注哪些部门的自营资源占量较大而使用率较低，这些部门对我们来说往往是能用于降本的组织，我们需要提前与他们沟通，所以就需要内部周报帮助完成。同时我们也列出了部门资源使用率的排名，排名越靠前说明治理得越好，反之亦然。
张鹤
哔哩哔哩
基础架构部 资深SRE
2020年加入B站，先后负责社区/直播/OGV/推广搜相关的SRE工作，深度参与多活，活动保障，混沌工程，容量治理相关的建设，主导容量管理平台，混沌平台的架构设计和落地，负责B站S赛、跨年晚会、拜年祭等相关活动的基础架构保障工作，目前主要负责推广搜业务的稳定性建设。
