TKE 集群可用性最佳实践概述¶

一、整体概述¶

腾讯云 TKE（Tencent Kubernetes Engine）作为腾讯云核心 PaaS 产品，承载了腾讯自研及外部公有云等海量核心业务，管理着数千万核的 CPU 规模，其稳定性直接影响业务的连续性。

然而 K8s 的中心化架构和声明式管理模式，在带来高效运维的同时，也引入了链式故障扩散的致命风险。开放性生态（如 Flink、Rancher 等第三方组件）与多业务、多租户复杂性进一步加剧隐患：

• 级联删除灾难：某客户使用 Rancher 管理 TKE 集群，误删某个 namespace 后，导致生产集群核心业务 workload、pod 等资源后全部被删除，导致业务中断。
• 控制面过载：OpenAI 大集群在部署了 DaemonSet 监控组件后，引发控制面故障、CoreDNS 过载，CoreDNS 扩容又依赖控制面恢复，导致机器数据面受影响，OpenAI 全球业务出现中断。
• 数据面强依赖控制面：开源 Flink on K8s 场景中，API Server 中断可能会导致 Flink 任务 checkpoint 失败，选主异常，严重情况下还可能会触发所有存量任务 Pod 异常退出，数据面全线崩溃，进而引发重大故障。

这些风险的本质是 K8s 架构的脆弱性传导链——一次组件异常、一条错误指令，都可能通过中心化链路引发全局故障。为了解决以上三大挑战，TKE 构建了误删除保护、控制面过载保护、混沌演练等三大体系，旨在发现业务隐患，提升 TKE 集群的可用性，助力客户业务成功。

二、为什么必须构建三大防护体系？¶

1. 为什么要做误删除保护？¶

相比其他云产品，基于 K8s 的云产品更加容易因为误操作导致出现故障，K8s 本身技术架构与云产品的差异性较大，具体体现在：

K8s 是一种中心化，多层级的结构性质，误操作的影响会严重放大¶

• K8s 采用中心式的架构，所有的组件都要通过 API Server 进行访问，一旦 API Server 发生故障就会导致整个链路访问异常。
• K8s 有较为复杂的层级结构，对 K8s 集群、namespace 等资源误删除操作，会导致集群下节点或 namespace 下所有 Pod 等资源被销毁；多数云产品如 CVM、CBS、数据库等都是没有层级结构，用户通常以实例为单位对其进行操作，误操作风险较低。

K8s 控制器模式的全量对账模型，增加了编码错误、运维操作失误时的故障影响范围¶

• K8s 控制器模式下，当云 API 数据返回不符合预期的情况下会导致资源被批量删除，例如 K8s 元数据异常场景导致整个集群 Pod 被全量删除等。
• 在非云原生场景，通常使用命令式 API，仅在脏数据清理逻辑中存在误删除风险。

在 K8s 集群中常见的误删除案例如下¶

2. 为什么需要控制面过载保护？¶

在 TKE 集群大规模运营过程中，我们遇到了一些典型的过载案例，从这些过载案例中，我们总结出了如下深层次的原因：

• 中心化架构，故障放大：K8s 是中心化架构，3 个 master 节点可管理上万节点，但是一旦 master 节点过载，导致整个集群几十万核心不可用，会导致故障严重放大。
• K8s 自身限速机制不足：社区 API Server 1.20 之前无有效的限速机制，1.20 之后引入了 APF，能针对不同组件配置流控策略，但是无法针对使用 admin 凭据的组件限速、list 和 watch 开销较大场景进行有效的流控，也没有基于负载的自适应流控，任何业务方部署一个 DaemonSet 组件、通过 K8s API 基于标签查询下 Pod 就可能会导致控制面故障。
• K8s List-Watch 重试风暴：常态下的 master 负载一般较低，具有欺骗性，但是网络抖动、节点故障导致 Watch 连接中断后，客户端（如大量 kubelet、DaemonSet 组件）并发全量 List 重试，API Server QPS 瞬间暴涨，负载飙升。
• 开放生态组件不成熟：社区组件（如 Flink、Spark、Argo、fluentd）等未经大规模验证，存在滥用 List/Watch（如批量请求传到到 etcd 等），直接击穿 API Server/etcd。
• 多业务、多租户资源混布：大部分业务 K8s 集群是多业务多租户混布的，租户 A 可能基于标签扫描下全量 Pod，就可能触发 etcd 带宽打满，导致租户 B 的强依赖控制面服务的请求超时。跨租户干扰引发级联故障，业务 SLA 无法保障。

3. 为什么需要混沌演练？¶

在云原生、K8s 的火热浪潮下，越来越多的业务场景部署到了 K8s 集群中，从在线服务到大数据、再到大模型训练、推理等，几乎覆盖了所有核心业务场景。但是在这过程中，暴露出了如下问题：

• 业务过于信赖 K8s 自愈特性，不清楚其边界和潜在的风险，未充分验证节点故障对关键业务 Pod 和系统 Pod 影响
• 业务因对 K8s 最佳实践和原理了解不充分，导致过载、误删除等，配置了对应的保护策略后，缺少对应的机制去验证
• 业务数据面依赖 K8s 控制面，如 Flink 等业务场景，控制面故障会影响存量所有 pod
• 无有效机制去帮助业务去检验集群跨 AZ 容灾、甚至多集群容灾能力是符合预期的

因此我们亟需一个标准产品化能力去协助客户解决以上痛点。

三、如何落地防护体系？¶

1. 误删除保护——从"事后救火"到"事前拦截"¶

为了解决上文所提到的误删除故障，TKE 基于开源组件 Gatekeeper 实现了产品化的策略管理中心，可对重要的 K8s 资源进行删除拦截，阻断非预期的删除行为，防止误删除引起重大业务故障。

你可以在控制台一键开启对应资源的误删除保护。

详细可参考：TKE 防误删策略配置文档

2. 控制面过载保护——从"被动扩容"到"主动防御"¶

为了解决 K8s 控制面过载保护难题，我们建立了一整套防护体系，覆盖全链路 K8s 全链路和各类版本。

资源层面¶

• 垂直水平扩容 - 集群规格自动升级（基于负载和节点数）
• 横向水平扩容 - 基于负载和规格自动化水平扩容

架构层面¶

• API Server 拆分：控制台可一键开启专属 API Server，避免非核心组件打崩控制面，实现故障隔离
• etcd 资源拆分：任何 TKE 集群默认后端拆分 event，两套 etcd 集群，还可以基于指定资源 ConfigMap 等拆分更细力度专属 etcd

etcd 流控层面¶

• API Server 缓存策略（已上线）：业务可以一键下发缓存策略，可防止 95% 场景的 etcd 过载，详情可参考：etcd 过载保护文档
• etcd list 流控能力（可防止异常 list 请求打崩 etcd，快速恢复 etcd）
• 内存 OOM 防护（Golang GC 优化，极大降低 etcd OOM 概率）

API Server 流控层面¶

• 资源对象数风险提示及 Quota 机制
• 1.20 以下 TKE 自研令牌桶限速
• 1.20 及以上 TKE 增强版 APF 默认流控策略（能基本防止非 expensive list/watch 请求）
• TKE 自研实现针对 expensive list 精准流控能力
• TKE 自研实现系统组件和业务组件一键熔断能力

详细可参考：API Server 限速和熔断文档

3. 混沌演练——从"盲目信任"到"主动验证"¶

基于 K8s 的自身及业务复杂性、开放性，TKE 提供了一整套混沌演习方案，协助你从"被动救火"转向"主动防御"，将稳定性转化为业务竞争力。

核心混沌特性如下¶

• 验证单点故障逃生能力：模拟关键业务节点宕机 10 分钟，检验业务 Pod、系统组件 Pod 是否能自愈
• 消除数据面强绑定控制面的风险：注入控制面故障，验证业务 Pod 是否因控制面故障而不可使用
• 控制面过载故障注入：模拟 DaemonSet 滚动更新击穿控制面，验证过载保护策略是否有效
• 验证误删除保护机制的有效性：模拟 Namespace、CRD 等误删操作，检验策略拦截是否生效
• 检验 AZ 级容灾有效性：模拟单可用区（AZ）网络隔离，验证跨 AZ 流量切换及业务数据库主备切换机制，保障业务多可用区容灾能力。

通过模拟故障场景，业务可演练控制面故障时数据面是否受影响，检验误删除和过载保护防护底线，提前发现设计缺陷，避免生产环境"爆雷"。

四、总结¶

K8s 的开放性使其成为云原生的基石，但中心化架构的脆弱性也让业务如履薄冰。TKE 通过三大防护体系：

• 误删除保护（防人为失误）
• 控制面过载保护（防组件异常）
• 混沌演练（防架构缺陷）

将 K8s 的"开放风险"转化为"可控竞争力"，让你既能驾驭 Flink、Prometheus 等生态组件的敏捷性，又能规避"一个 DaemonSet 打崩全球服务"的灾难。

通过以上概述希望能帮助你更好的使用好 TKE 集群，提升业务架构的稳定性，助力业务成功。

参考资料¶

• TKE 可用性最佳实践汇总