【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

最新推荐文章于 2022-09-09 10:30:43 发布

m0_67614284

最新推荐文章于 2022-09-09 10:30:43 发布

阅读量277

点赞数

分类专栏： Java 文章标签：经验分享架构 java

本文链接：https://blog.csdn.net/m0_67614284/article/details/124455653

版权

本文介绍了阿里巴巴面对万级规模Kubernetes（K8s）集群的高可用和性能挑战，包括APIServer多路架构升级、ASI多集群联邦架构、性能瓶颈突破与预防能力加强。通过API访问层限流、业务POD限流和数字化容量治理等措施，提升集群的稳定性与安全性。同时，建立应急能力建设，实现快速发现和恢复问题，确保系统的全局高可用。

摘要由CSDN通过智能技术生成

[](()全局高可用基础能力建设

================================================================================

在建设全局高可用能力之前，我们的系统在迅速发展和变化下不断出现事故和险情，需要隔三差五去应急，导致让问题追身的局面，并且追身后没高效应对的手段，面临着几个严峻的挑战：

如何在架构和能力上去提升我们的可用性，降低系统发生故障的概率和影响面？
如何在核心链路性能和架构上做一些突破，能够支撑这么复杂多变的业务场景和业务增长的通用需求？
如何让问题不再追身，做好预防工作，避免应急？
如何在应急发生时，能够快速发现，快速诊断，快速止损？

针对这些问题，并且总结出以下几个核心原因：

可用性能力不足：在集团场景下，组件不断在变化，不断增加系统的压力和复杂度，ASI 在生产可用性的能力上缺失，如限流降级、负载均衡等，组件容易乱用造成低级错误，影响集群可用性。
系统风控和 pod 保护能力不足：在人为误操作或系统 bug 时, 容易造成业务 pod 无辜受损或者大面积受损。
容量风险：集群数量几百，组件接近一百；另外历史问题因 podCIDR 和节点 IP 数的配置，大多 ASI 元集群的节点规模被约束在 128 台以内，随着业务快速发展，对容量风险而言存在较大挑战。
单集群规模受限，加上横向扩展能力不足影响业务发展：单集群不断增长规模，以及业务类型变化，组件变化都对单集群支撑的最大规模产生影响，对 SLO 持续稳定产生影响。

[](()1. 高可用基础能力顶层设计

针对这些解决的问题，我们做了高可用基础能力的顶层设计，这些基础能力建设整体主要分为几个部分：

性能优化和高可用架构建设：主要是从性能优化和架构升级的角度来提升整个集群支撑的业务类型和业务量。
组件规范全生命周期管理：主要从规范的角度在组件的整个生命周期去落地，从出生启用和集群准入开始，到每一次变更，到下线整个生命周期都要防止组件乱用、野蛮生长、无限膨胀，控制组件在系统可承受范围之内。
攻防体系建设：主要从 ASI 系统本身触发，在从攻击和防御的角度来提升系统的安全，防御和风控能力。