集群/资源池/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赛、跨年晚会、拜年祭等相关活动的基础架构保障工作，目前主要负责推广搜业务的稳定性建设。
