苗永昌-字节跳动 Kubernetes 集群2w+节点性能优化实战

苗永昌 字节跳动云原生混合云架构师 苗永昌 公司职位字节跳动云原生混合云架构师 云原生混合云架构师，专注于云原生领域。在K8S大规模集群优化，混部，企业传统架构向云原生转型等领域有着丰富的实战经验。 01 字 节 跳 动 云 原 生 发 展介 绍 目录 02 基 础 设 施 优 化 和 开 源实 践 03K u b e G a t e w a y &K u b e B r a i n 04 其 他优 化 字节跳动云原生发展介绍 字节跳动大规模云原生实践 字节跳动云原生现状全面云原生 拥有100,000+在线微服务，敏捷化构建能力持续增强 节点数 900,000+ 最大集群节点数达到2w，实现大规模集群落地 2021年，字节跳动所有业务均已经实现了全面云原生化，并且基于云原生基础设施，成功支持了抖音央视春晚活动，充分验证了其稳定性和弹性能力。 现有500+生产集群，基础设施深度云原生化 平均每日变更数高达30,000次 离线任务数140M+通过云原生混部，大规模节省企业资源成本 云原生为前线业务提供稳定性保障 字节跳动基础设施优化和开源实践 问题和挑战 规模增长快场景更复杂 1.Kubernetes集群节点持续增多，单集群规模和集群数量增长迅速。2.离线、AI等场景的容器化，相对在线场景，Pod的数量、创建和更新频率、调度吞吐量会大幅增加，对集群性能提出了更高的要求。 K8S控制面关键组件性能受限 官方稳定规模在5k节点，当集群规模到达一定程度，性能迅速下降。集群压力集中在APIServer，etcd等关键组件，造成稳定性风险。 1.横向扩展，构建管理N个集群的能力。->集群联邦 2.纵向扩展：提高单个集群的规模。->性能优化 规模化稳定性问题 01 APIServer多实例负载严重不均衡 单集群对象数量和读写QPS增加，API性能退化 02 例如：List耗时过久，影响组件初始化和故障恢复速度。 APIServer频繁重启，APIServer和etcd不断OOM03 例如：灾难场景APIServer重启或者kubelet批量重启，list请求数量激增，导致APIServer内存被打满，引起控制面雪崩。 社区优化手段 集群治理 组件参数调优 1. Agent访问：尽量查询kube-apiserver缓存；避免全量资源拉取。2.容量规划：合理规划节点数量和单namespace资源数量。3.限流：apf限流。 1.限流参数：大规模集群，适量放大限流参数。2. etcd拆分/ etcd压缩周期调优。3.负载均衡参数：goaway-chance。 控制面 APIServer缓存优化 硬件升级 1. Cache NotReady优化：当Cache还未构建完成时，拒绝所有LIST请求。2.缓存穿透优化：对于未指定ResourceVersion的LIST请求，将其ResourceVersion设置为"0".由从etcd中查询，重定向到从Cache中查询。 1.控制面：升级机器规格和性能。2. etcd：存储硬件升级，etcd独占盘，支持nvme。 字节跳动控制面关键优化 KubeGateway Godel-Scheduler 多集群的高可用API路由层，提供多套K8s集群的KubeAPIServer的HA接入能力，相比于基于Nginx的负载方案，还提供了识别K8s资源对象的集群流量治理能力。 自研在离线融合调度器 KubeBrain Controller Manager 字节自研的元信息存储服务，能够对接开源etcd/TiKV，也能够对接基础架构内部ByteKV设施。支持5万Node，百万Pod容量。 拆分部署，横向扩展Informer cache index KubeGateway &KubeBrain KubeGateway KubeGateway：七层负载均衡 常用方案：四层负载均衡nginx，云厂商的SLB等 1.请求负载不均衡在kube-apiserver滚动升级或者某个实例重启时，很容易引起迟些启动 的kube-apiserver在长时间内只有很少的请求数。极端情况下，负载较高的实例会出现OOM，甚至引起雪崩。 2.缺乏治理灵活性四层负载均衡无法根据请求的内容（比如verb、url等字段）制定灵活的 请求负载不均衡负载均衡和路由策略，也无法在网关层对请求级别进行限流降级等处理。 3.连接数无法收敛四层负载均衡器为每个客户端和APIServer分别建立了TCP连接，连 接数是1:1的关系，无法有效使用http2的多路复用功能，当客户端增多之后（比如node数增加）维护大量TCP连接给APIServer造成压力 4.缺乏通用网关能力由于不具备OSI七层的全部信息，缺乏集群隔离（一个集群请求数过多影 响其他集群）、降级（单个集群的请求和连接数限制）、动态服务发现和变更（更改upstream信息只能修改配置文件进行reload，reload造成所有集群的连接断开）等能力。 KubeGateway 1.客户端无需改造可以接入KubeGateway，支持client-go。 2.支持接入多个K8s集群，不同集群通过域名或者vip区分。 3.负载均衡从TCP连接级别变为HTTP请求级别，进而实现快速、有效的进行负载均衡，彻底解决kube-apiserver负载不均衡的问题。 请求负载不均衡：由于kube-apiserver和client是使用HTTP2协议连接，HTTP2的多个请求都会复用底层的同一个4.收敛单个kube-apiserver实例上的TCP连接数，降低至少一个数量级。 TCP连接并且长时间不断开。在kube-apiserver滚动升级或者某个实例重启时，很容易引起迟些启动的kube-apiserver在长时间内只有很少的请求数。极端情况下，负载较高的实例会出现OOM，甚至引起雪崩。5.支持灵活的路由策略，支持不限于resource/ verb/ user/ namespace/ apigroup等进行路由。 6.支持限流、降级、动态服务发现、优雅退出、upstream异常检测等网关的通用能力。 KubeGateway架构 完整的kube-apiserver逻辑链路对外提供代理集群和路由的CRUD操作 代理通往upstream cluster的流量，提供部分authN/Z的功能，提供灵活的路由匹配规则，提供灵活的限流规则代理通往upstream cluster的流量，提供部分authN/Z的功能，提供灵活的路由匹配规则，提供灵活的限流规则代理通往upstream cluster的流量提供部分authN/Z的功能提供灵活的路由匹配规则，提供灵活的限流规则 KubeGateway代理kube-apiserver的请求的流程 请求解析：解析APIGroup/ Resource/ ResourceName/ Verb/ UserGroup/ User等字段。路由匹配：从以上字段组合出不同的路由规则，来区分不同的API请求。用户认证：支持X509和BearToken认证方式。授权操作由upstream kube-apiserver进行。流量治理：负载均衡/健康监测/限流/降级。反向代理：用户扮演/ HTTP2多路复用。 KubeGateway请求过程 请求解析/路由匹配 请求解析：1.资源请求，如对Pod的CRUD（增删改查） 1.负载均衡：支持Round Robin和Random转发下游实例。 2.非资源请求，如访问/healthz查看kube-apiserver的健康情况，访问/metrics查看暴露的指标等 2.健康监测：/healthz检查APIServer，屏蔽故障实例。 3.限流：精细的限流规则，可对管控组件豁免流量。支持token bucket / max requests inflight限流策略 路由匹配1.通过Verb和Resource的结合，匹配到所有的list pod的请求 2.通过User，UserGroup，ServiceAccount等，我们可以匹配出kube-controller-manager，kube-scheduler等核心控制组件的请求 4.降级：故障期间，降级拒绝所有流量，冻结集群操作。 kubegateway-反向代理 Impersonate（用户扮演） HTTP2多路复用 1.kube-apiserver认证KubeGateway用户，识别出用户扮演的行为2.kube-apiserver确保KubeGateway具有Impersonate权限3.kube-apiserver根据HTTP Header识别出KubeGateway扮演的用户名和用户组，然后将请求执行者替换成被扮演的用户4.对被扮演的用户进行授权验证，检查他是否有权限访问对应的资源 KubeGateway默认使用HTTP2协议，单条连接上默认支持250个Stream，使得upstream单个kube-apiserver的TCP连接数可以降低两个数量级。 落地实践和使用示例 1.创建Kubernetes集群，自动创建KubeGateway对象。2.自动生成Nginx配置条目。3.故障时可切换DNS至Nginx冷备链路。 KubeGateway落地效果 1.平滑的接管了字节所有的Kubernetes集群。 2.KubeGateway性能优异，经过代理后，请求延迟增加在1ms左右。 3.彻底解决了kube-apiserver流量不均衡的问题。 4.增强了kube-apiserver请求的治理能力，包括请求分组、路由、限流、降级等，有效提高了集群的稳定性和可用性。 5.开源后，公有云外部客户生产应用。 Etcd社区优化方案 1.Kubernetes按照对象类型拆分存储Kubernetes支持将不同类型的对象存储到不同的etcd集群中，但是目前同一对象的数据只能存储到一个 etcd集群里。所以按照对象对存储进行了拆分，当某个对象类型的读写到达上限后，无法进行水平扩展。 2. etcd gRPC Proxyetcd gRPC的无状态反向代理，通过合并Watch/ Lease API请求和缓存Range请求，减轻etcd server负 Kubernetes按照对象类型拆分存储载。不支持etcd分片，所以无法水平扩展etcd。 KubeBrain KubeBrain统一抽象了逻辑层所使用的KeyValue存储引擎接口，实现了核心逻辑与底层存储引擎的解耦： 逻辑层基于存储引擎接口来操作底层数据，不关心底层实现；对接新的存储引擎只需要实现对应的适配层，以实现存储接口。 KubeBrain特点和优势 1.无状态实际数据存储在底层存储引擎，apiserver所需监听数据存放在主节点内存。底层为ByteKV，外部可对接tiKV。 2.扩展性抽象kv数据库接口，符合指定特性的kv数据库均可适配。 3.高可用采用主从架构，自动选主。 4.水平扩容KubeBrain增加节点提高并发读。存储引擎通过增加存储节点提高读写性能和容量。 1.读写性能大幅提升- ByteKV读写能力更强悍 -读写逻辑优化提升Kubebrain读写能力 2.支持分片引入proxy架构，解决主单点写，原则上支持无限水平扩展能力 KubeBrain 3.0 单点写架构问题： 1.写吞吐性能有上限：所有写请求由主节点处理，无法水平扩展。2.可用性下降：主节点故障或者切主期间，集群处于无主阶段，完全无法写入。切主一般在8～10 s。3.当前架构强依赖底层ByteKV的强悍写入能力，通用kv效果打折扣。 解决方法： 1.引入proxy架构，解决主单点写，根据Key的Hash发往不同的KubeBrain Group，原则上支持无限水平扩展