KubeWharf 是字节跳动基础架构团队在对 Kubernetes 进行了大规模应用和不断优化增强之后的技术结晶。

这是一套以 Kubernetes 为基础构建的分布式操作系统，由一组云原生组件构成，专注于提高系统的可扩展性、功能性、稳定性、可观测性、安全性等，以支持大规模多租集群、在离线混部、存储和机器学习云原生化等场景。

诞生背景

首先，让我们来深入分析 KubeWharf 的诞生背景：

以 Kubernetes 为代表的云原生技术底座支撑了字节跳动业务的快速发展。从微服务场景开始，Kubernetes 逐渐演化，统一支撑了字节内部的大数据、机器学习以及存储服务等多种形态基础设施。从 2018 年至今，字节跳动的 Kubernetes 节点的规模增长了 10 倍以上。面对这样的增速，提高 Kubernetes 分布式操作系统的性能、资源利用率、可扩展性、可用性等愈发重要，KubeWharf 就是在这样的背景下诞生。

2022 年 7 月 首批开源的项目分别为：

KubeBrain：高性能元信息存储系统

KubeZoo：轻量级的 Kubernetes 多租户项目

KubeGateway：专为 kube-apiserver 设计并定制的七层负载均衡代理

2023 年，第二批开源项目分别为：

Katalyst：在离线混部、资源管理与成本优化项目

KubeAdmiral：多云多集群调度管理项目

Kelemetry：面向 Kubernetes 控制面的全局追踪系统

截至今年 12 月，KubeWharf 共有 6 个围绕 Kubernetes 生态的云原生项目开放源码。同时，这 6 个项目相互之间不存在绑定依赖，都是独立项目。

以下给大家共享下KubeWharf的开源地址，感兴趣的同学可以去看看源码

KubeWharf 项目地址：https://github.com/kubewharf

笔者认为综合来看，KubeWharf 在多租户管理、离线混部、存储和机器学习云原生化等方面的优势，使其成为一个强大的工具，适用于各种复杂的应用场景。企业和云服务提供商可以通过充分利用 KubeWharf 的特性，更好地构建、管理和维护其云原生基础设施，从而提升整体业务的效率和可靠性。

接下来，我们将深入解读 KubeWharf 项目的核心组件，探讨其优势、不足，并展望未来的发展方向。

Kubernetes 简述

Kubernetes，简称 k8s（k-8 个字符-s（明白了），是一个开源的 Linux 容器自动化运维平台，它消除了容器化应用程序在部署、伸缩时涉及到的许多手动操作。换句话说，你可以将多台主机组合成集群来运行 Linux 容器，而 Kubernetes 可以帮助你简单高效地管理那些集群。构成这些集群的主机还可以跨越公有云、私有云以及混合云。

在生产环境中使用 Kubernetes 的主要优势在于它提供了在物理机或虚拟机集群上调度和运行容器的平台。更宽泛地说，它能帮你在生产环境中实现可以依赖的基于容器的基础设施。而且，由于 Kubernetes 本质上就是运维任务的自动化平台，你可以执行一些其它应用程序平台或管理系统支持的操作，只不过操作对象变成了容器。

kubernetes组件包括

Master（主节点）： 控制 Kubernetes 节点的机器，也是创建作业任务的地方。

Node（节点）： 这些机器在 Kubernetes 主节点的控制下执行被分配的任务。

Pod： 由一个或多个容器构成的集合，作为一个整体被部署到一个单一节点。同一个 pod 中的容器共享 IP 地址、进程间通讯（IPC）、主机名以及其它资源。Pod 将底层容器的网络和存储抽象出来，使得集群内的容器迁移更为便捷。

Replication controller（复制控制器）： 控制一个 pod 在集群上运行的实例数量。

Service（服务）： 将服务内容与具体的 pod 分离。Kubernetes 服务代理负责自动将服务请求分发到正确的 pod 处，不管 pod 移动到集群中的什么位置，甚至可以被替换掉。

Kubelet： 这个守护进程运行在各个工作节点上，负责获取容器列表，保证被声明的容器已经启动并且正常运行。

kubectl： 这是 Kubernetes 的命令行配置工具。

KubeBrain

KubeBrain 是字节跳动针对 Kubernetes 元信息存储的使用需求，基于分布式 KV 存储引擎设计并实现的、可以取代 etcd 的元信息存储系统，目前支撑着线上超过 20,000 节点的超大规模 Kubernetes 集群的稳定运行。

分布式应用编排调度系统 Kubernetes 已经成为云原生应用基座的事实标准，但是其官方的稳定运行规模仅仅局限在 5,000 节点。这对于大部分的应用场景已经足够，但是对于百万规模机器节点的超大规模应用场景， Kubernetes 难以提供稳定的支撑。

尤其随着“数字化””云原生化”的发展，全球整体 IT 基础设施规模仍在加速增长，对于分布式应用编排调度系统，有两种方式来适应这种趋势：

水平扩展：即构建管理多个集群的能力，在集群故障隔离、混合云等方面更具优势，主要通过集群联邦（Cluster Federation）来实现；

垂直扩展：即提高单个集群的规模，在降低集群运维管理成本、减少资源碎片、提高整体资源利用率方面更具优势。

K8s 采用的是一种中心化的架构，所有组件都与 APIServer 交互，而 APIServer 则需要将集群元数据持久化到元信息存储系统中。

当前，etcd 是 APIServer 唯一支持的元信息存储系统，随着单个集群规模的逐渐增大，存储系统的读写吞吐以及总数据量都会不断攀升，etcd 不可避免地会成为整个分布式系统的瓶颈。

过去面对生产环境中 etcd 的性能问题，只能通过按 Resource 拆分存储、etcd 参数调优等手段来进行一定的缓解。但是面对 K8s 更大范围的应用之后带来的挑战，我们迫切的需要一个更高性能的元数据存储系统作为 etcd 的替代方案，从而能对上层业务有更有力的支撑。

借鉴 k3s 的开源项目 kine 的思想，KubeWharf 实现了基于分布式 KV 存储引擎的高性能 K8s 元数据存储项目—— KubeBrain 。

KubeBrain 系统实现了 APIServer 所使用的元信息存储 API ，整体采用主从架构，主节点负责处理写操作和事件分发，从节点负责处理读操作，主节点和从节点之间共享一个分布式强一致 KV 存储，在此基础上进行数据读写。下面介绍 KubeBrain 的核心模块。

KubeZoo

KubeZoo 是由字节跳动自研的 Kubernetes 轻量级多租户项目，它基于协议转换的核心理念，在一个物理的 Kubernetes Master 上虚拟多个租户，具备轻量级、兼容原生 API 、无侵入等特点，是一种打造 Serverless Kubernetes 底座的优良方案。

从 2014 年开源至今，Kubernetes 已经成为容器编排领域的事实标准，为开发者进行应用编排、提高资源利用率提供了极大便利。但面对集群管理，如何提升多租户集群管理能力仍是困扰开发者和企业的一个关键问题。

增强 K8s 集群控制面的多租户能力已经成了一个现实问题：

从运维视角来看，即使 Kubernetes 具备自动化的集群生命周期管理，但是各项控制面组件的维护、升级，和周边庞杂设施的交互，对开发人员来说仍是棘手的问题；

随着机器学习任务、大数据平台接入云原生基础设施，基于 Kubernetes 打造的系统底座需要提供更快速、更低成本、更高效的管理 Kubernetes 集群的能力。

为了解决这些问题，基础架构团队推出了轻量级多租户解决方案 KubeZoo：

KubeZoo 是一个轻量级的 Kubenertes 多租户项目，基于协议转换的核心理念在一个物理的 K8s 控制面上虚拟出多个控制面，它具有以下特点：

资源消耗低：和租户独占集群或者 Master 控制面对比，KubeZoo 只需要一个“网关”，无需为每一个租户起一个独立的控制面集群，资源消耗很少。且租户数量越多，资源消耗方面的收益更加显著。

控制面隔离性高：每个租户可以拥有独立且完整的 Kubernetes 集群视图，租户既可以使用 namespace scope 的资源，又可以使用 cluster scope 的资源，使用体验好。

运维成本低：KubeZoo 有效的减少了集群/ Master 管控面的数量，大大减少了运维、升级维护成本。

高效率：秒级创建租户，每个租户的集群创建相当于创建一个 Tenant 对象，省略了耗时的硬件资源分配和控制面初始化过程。

KubeGateway

KubeGateway 是字节跳动针对 kube-apiserver 流量特征专门定制的七层网关，它彻底解决了 kube-apiserver 负载不均衡的问题，同时在社区范围内首次实现了对 kube-apiserver 请求的完整治理，包括请求路由、分流、限流、降级等，显著提高了 Kubernetes 集群的可用性。

目前外部负载均衡器（LB）的选型一般为 LVS、云厂商的 SLB 或 nginx、HAProxy 的四层负载均衡方案，存在如下问题：

请求负载不均衡：由于 kube-apiserver 和 client 是使用 HTTP2 协议连接，HTTP2 的多个请求都会复用底层的同一个 TCP 连接并且长时间不断开。在 kube-apiserver 滚动升级或者某个实例重启时，很容易引起迟些启动的 kube-apiserver 在长时间内只有很少的请求数。极端情况下，负载较高的实例会出现 OOM，甚至引起雪崩。

缺乏请求治理的灵活性：4 层负载均衡在传输层工作，它只负责消息的传递，但是无法处理应用层的 HTTP 协议的信息，因此相较于 7 层负载缺乏对请求治理的“灵活性”和 “智能性”。比如无法根据请求的内容（比如 verb、url 等字段）制定灵活的负载均衡和路由策略，也无法在网关层对请求级别进行限流降级等处理。

随着云原生技术的发展，目前字节跳动 95% 以上的业务跑在 Kubernetes 上，对集群高可用提出了更高的要求。而在生产环境中，也曾遇到过多次由于 kube-apiserver 负载不均衡或者缺乏请求治理能力带来的事故，因此面对以上问题，字节跳动针对 kube-apiserver 的流量特征自研了七层网关 KubeGateway。

它代理 kube-apiserver 的请求的流程如下图所示，主要分为五个步骤：请求解析、路由匹配、用户认证、流量治理和反向代理。

KubeGateway 作为七层网关接入和转发 kube-apiserver 的请求，它具有以下特点：

对于客户端完全透明，客户端无需任何改造即可以接入 KubeGateway；

支持同时代理多个 K8s 集群的请求，不同 K8s 集群通过不同的域名或者虚拟地址（vip）进行区分；

负载均衡从 TCP 连接级别变为 HTTP 请求级别，进而实现快速、有效的进行负载均衡，彻底解决 kube-apiserver 负载不均衡的问题；

高扩展性的负载均衡策略，目前支持 Round Robin、Random 策略，负载均衡策略插件化，易于扩展；

支持灵活的路由策略，KubeGateway 根据请求信息，包括但不限于 resource/ verb/ user/ namespace/ apigroup 等进行路由。为 kube-apiserver 分组提供基础能力，以低运维成本实现 kube-apiserver 组之间的隔离性，提高集群稳定性；

配置管理云原生化，以 K8s 的标准 API 形式管理网关配置，支持配置热更新；

支持限流、降级、动态服务发现、优雅退出、upstream 异常检测等网关的通用能力。

总结及展望

本文对Kubenetes 的基本概念和KubeWharf 的三个项目做了介绍，KubeWharf不仅仅是某一项或某几项技术，更是一种理念和引导，促进企业在上云的过程中使用相关技术来更好的发挥云计算的优势。

对于 KubeWharf 项目而言，未来的发展方向可能包括：

更强大的多租户支持： 针对大规模多租户集群的场景，进一步加强多租户支持，提供更细粒度的权限控制和更智能的资源分配。

更广泛的云原生整合： 随着云原生技术的发展，KubeWharf 可能会更深入地整合更多云原生工具和服务，以提供更全面的解决方案。

社区的扩大和贡献者的增加： 通过吸引更多的开发者和用户，形成更为活跃的社区，有助于项目的稳健发展和持续创新

在KubeWharf发展的过程中，使得云原生向着更加标准化的方向发展。正是社区和开源的力量把全球开发者凝聚在一起共同推进云原生技术的进步，使其欣欣向荣的向前发展。