李汉波-字节跳动基于 KubeAdmiral 的多云分布式云原生实践之路

李汉波云原生工程师 李汉波 公司职位云原生工程师 开源多云容器编排项目KubeAdmiral与Karmada社区Maintainer负责火山引擎分布式云原生系统的研发专注于云原生容器，多云领域 01业 务 需 求 驱 动 分 布 式 云 架 构 建 设 02字 节 跳 动 基 于K u b e A d m i r a l的集 群 联 邦 技 术 实 践 目录 03从 集 群 联 邦 到 分 布 式 云 原 生 多 云多 集 群 管 理 实 践 04分 布 式 云 原 生 的 下 一 阶 段 业务需求驱动分布式云架构建设 分布式云原生行业现状 为什么需要分布式云原生统一管理 多云多集群运维成本高02 集群规模及稳定性 多云容灾困难 •多云环境异构，云厂商资源管理差异•多云集群管理入口分散，缺乏统一运维方案•多集群孤岛，无法统一调度，集群利用率低•自建调度逻辑，成本高 •单一集群规模受限•单一大集群故障风险大•单一云厂商锁定，容灾难 •跨云迁移困难•多云流量如何调度•集群故障迁移困难 业务需求驱动分布式云架构建设 分布式云原生整体架构方案 多集群统一观测 跨集群调度策略 多集群配额管控 自动故障迁移 字节跳动基于KubeAdmiral的集群联邦技术实践 字节跳动云原生发展历程 以KubeFed (Federation v2)为基础的集群联邦 KubeFed V2面临的问题 状态聚合能力差 调度能力弱 业务连续性 接入难度高 由于联邦层暴露的是“联邦化”的对象，而不是Kubernetes原生对象，上层服务往往需要针对联邦集群做特殊适配 扩缩容过程中，可能产生Rebalance，会影响业务稳定性；同时，故障迁移能力较弱 只支持RSP静态副本调度，导致成员集群水位不均，对其他调度策略只能在程序中特殊处理，扩展性差 只支持把资源的status字段采集上来，无法自定义采集字段，也没有对状态进行多云多集群语义的转换与汇聚 超大规模集群联邦KubeAdmiral •兼容Kubernetes的标准API以及自定义CRD•调度器和调度算法可扩展，支持丰富的调度分发策略•支持差异化覆写策略•支持接管用户单集群已有资源，无损迁移•提供状态采集框架，自定义状态采集字段•更强大的故障自动迁移能力，涵盖集群故障迁移，应用故障迁移，污点迁移等场景•支持联邦HPA，可以低成本接管单集群HPA（原生/自定义） https://github.com/kubewharf/kubeadmiral 降低接入难度：支持原生API和CRD 引入FederatedController，负责将原生的资源转换为FederatedObject 增强状态聚合能力：自定义采集字段，汇聚status 通过引入StatusAggregator，负责将子集群资源的状态聚合到原生资源，针对不同的资源可以添加聚合Plugin 提高调度扩展性：Global Scheduler（1） 参考Kubernetes Scheduling Framework，建设面向多样化FederatedObject的调度器：Global Scheduler 提高调度扩展性：Global Scheduler（2） Global Scheduler的Framework和Plugin： •Filter：根据子集群的状态、亲和性、资源、是否支持CRD等等过滤不符合条件的Member Cluster•Score：对符合条件的Members Cluster打分，例如资源、亲和性等•Selector：最多分发到多少个集群•Replica：面向类似Deployment提供的副本数调度 提高调度扩展性：Global Scheduler（3） Global Scheduler支持丰富的调度策略模板，用户可在应用中指定所需要的调度策略模板，也支持用户使用自定义的扩展调度器 提高调度扩展性：Global Scheduler（4） Global Scheduler支持通过http协议与外部插件交互，用户可以自行编写并部署定制化的调度逻辑： •SchedulerPluginWebhookConfiguration：配置scheduler plugin访问地址•SchedulingProfile：配置scheduler plugin启用顺序•PropagationPolicy:指定使用的scheduling profile 动态调度：基于集群水位 KubeFed V2问题： •副本调度策略RSP只能为每个member集群设置静态权重•静态权重很难做到集群部署率一致，在个别集群部署率很高时，很容易产生pending 基于集群水位的动态调度 •进行权重计算时，同时考虑集群的资源总量allocatable和当前可用资源量available 效果 •所有member集群的部署率都维持在95%以上，部分大规模member集群部署率可以达到98% 重调度：避免业务中断 KubeFed V2问题： 30个实例分布在AB 2个member集群，集群权重1:1，现在用户增加一个集群C，同时缩容到15个实例： •用户预期：停止15个实例 •按权重调度：停止20个实例，启动5个实例，瞬时可用实例5+5+0（启动之前），低于15 集群ABC实例数15150 集群ABC瞬时实例数550实例数555 30个实例分布在AB 2个member集群，集群权重1:1，现在用户增加一个集群C，同时扩容到36个实例： •用户预期：启动6个实例 •按权重调度：启动12个实例，停止6个实例，瞬时可用实例12+12+0（启动之前）,低于30 集群ABC瞬时实例数12120实例数121212 集群ABC实例数15150 重调度：避免业务中断 当前方案：重调度策略增加avoidDisruption= true avoidDisruption在扩缩容时特殊处理，以避免正常运行的pod因为权重的变化被迁移 •先按权重算每个集群desired副本数，后结合当前副本数current计算最终分配副本数 •false:直接用desired作为最终结果，可能会引起集群间的迁移，但最终分布完全遵循权重 •true：避免反向的pod移动（如果是扩容，则没有集群会缩容，反之亦然），但最终分布不完全遵循权重 字节内场实践-流量协调、自动容灾 流量调度实现异常容器识别和规避 字节内部容器间的调用全量切入到service mesh体系，由其提供流量的代理和稳定性的保证 集群联邦实现异常容器迁移和重建 集群联邦实现多集群联合，突破单集群规模上限，在集群间实现容器的自动化迁移 从集群联邦到分布式云原生多云多集群管理实践 字节跳动分布式云原生整体能力 基于K8s和容器技术，让用户进行云原生应用部署和管理时感受不到云厂商、地域、流量的限制的PAAS服务。 统一集群管理 统一应用分发 统一集群观测 统一流量管理 •支持纳管多地域，多基础设施K8S集群•提供统一集群管理入口•支持单集群应用迁移到多集群（联邦）•应用备份，恢复与迁移•多集群RBAC统一认证 •兼容原生K8S API和资源/CRD语义•支持联邦/非联邦两种形态•支持多集群灵活调度：动态/跟随•支持集群差异化复写 •多集群监控、日志数据统一收集与展示•多集群监控数据聚合•应用维度监控数据聚合•多集群故障诊断 •多集群统一流量调度•支持东西/南北向•服务注册/服务发现 分布式云原生平台实践架构 核心能力-多集群管理 提供分布式集群全局管理能力，具备一致的集群管理体验，降低运维成本。 •多集群纳管：连接并管理用户任何地域、任何基础设施上的K8s集群 •统一资源管理：使用容器服务控制台统一管理集群和应用，避免在不同云平台之间切换控制台。 •统一安全治理：对多云集群进行一致的RBAC授权管理。 •统一可观测体系：纳管集群监控、日志数据统一收集与展示。 核心能力-集群连接模式 分布式云原生平台纳管外部集群时，支持通过直连模式、代理模式进行注册接入 直连模式：通过目标集群提供的KubeConfig进行直接注册管理的方式。 •场景：控制面可以通过外网或同一私网中直接访问目标集群的API Server地址。如：私有云DCP公网直连注册公有云集群。 •优势：注册简单、不消耗集群资源（可纳管空节点集群） •劣势：证书失效&到期替换问题、证书泄露风险代理模式：控制面暴露代理服务地址，目标集群通过安装代理连接到控制面后进行统一管理的方式。 •场景：当控制面无法直接访问目标集群，但反向可连通的场景。如：公有云DCP，目标集群部署在IDC环境。 •优势：无证书到期问题、注册安全（不泄露 KubeConfig） •劣势：需要保证集群有节点资源及带宽运行Agent 核心能力-注册节点 分布式云原生平台支持云上云下混合节点统一管理 •混合节点管理：将自有IDC节点或三方云节点一键接入火山VKE容器集群，支持公网、专线、VPN等多种网络接入环境，实现云上云下节点统一管理。 •中心化运维：提供专用的监控、日志采集组件，支持对云下节点及负载的观测指标的统一云上存储，并提供指标查询面板及异常指标告警能力。 •节点自治：在断网或网络信号弱的环境下提供注册节点及应用自治能力，确保关键业务的连续性和稳定性，可适用于弱网连接场景。 •GPU资源调度：提供了注册节点的NVIDIA GPU组件及运行时安装，支持云上统一的GPU负载调度。 •集群免运维：采用火山引擎托管版容器服务VKE作为注册节点的控制面，通过VKE集群控制台及API进行云下工作负载管理，最小化用户对集群的运维负担。 核心能力-应用跨集群分发 将多集群构建成为集群联邦形成统一资源池，通过统一算力分发入口及多集群分发策略，可高效地将应用分发到目标集群，实现了降低操作复杂度、减少运维成本，同时可大大提高集群部署率和资源利用率。 •统一应用分发：通过统一界面入口或kubeconfig将应用分发到多个集群中，而无需切换集群进行多次操作。 •兼容K8s生态：支持原生K8s及CRD资源、Helm等应用定义。 •存量应用无缝接管：无需改造应用及不影响现有业务运行的情况下转变为多集群联邦应用，降低使用门槛和迁移成本。 •灵活的分发策略：支持指定集群名称、标签、污点容忍调度；支持依赖资源自动跟随分发；支持分发到不同集群时的差异化覆写配置。 核心能力-多集群应用故障迁移 为了提高业务的高可用性，工作负载可能会被部署在多个集群中，当集群发生故障或应用在该集群中无法正常部署时，需要进行自动/手动故障迁移，进而保证用户业务的可用性与连续性。 •集群故障迁移：当集群发生故障(不健康或失联)，或是不希望在某个集群上继续运行工作负载（如集群下线、升级）时，支持手动进行集群应用驱逐，被驱逐的工作负载将被调度至其他健康的集群中。 •应用故障迁移：当应用实例调度到目标成员集群后无法正常启动(Cond=Unschedulable)，联邦控制面会触发重调度并将实例迁移到其他健康集群中。 核心能力-单集群资源联邦化 凭借多集群调度引擎对存量单集群资源的无缝接管能力，可以做到无需改造应用及不影响现有业务运行的情况下转变为多集群联邦应用 资源联邦化步骤 •步骤1：将待联邦化资源所在容器集群（以下称源集群）添加到联邦主控实例中，作为联邦集群成员集群。 •步骤2：指定源集群中一个或多个待联邦化的资源，支持指定K8s原生和CRD资源。 •步骤3：平台自动将单集群资源转化为联邦资源定义，并关联默认部署策略将资源分发到源集群，对单集群资源进行接管（anno:kubeadmiral.io/conflict-resolution: adopt）。 •步骤4：已经联邦化的资源可更新部署策略、差异化策略，实现多集群的资源分发/资源迁移。 核心能力