基于 Playbook 实现 TKE 控制面故障演练

黄坚，腾讯云容器服务 TKE 后台开发工程师，主要负责 K8s 控制面相关研发工作。

彭芳，腾讯云容器产品经理，主要负责 TKE 平台的产品能力建设和商业化工作。

背景

被忽视的风暴眼：控制面的全局风险

K8s 的中心化架构和声明式管理模式，在带来高效运维的同时也引入了链式故障扩散的致命风险。而 K8s 集群的控制面组件 Master 承载着“大脑指挥官”的功能，一旦控制面发生故障，其爆炸半径往往波及整个集群，业务停摆风险指数级飙升。例如：

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

行业空白与用户困境：托管服务的黑盒性

面对如此关键的“大脑”和巨大的潜在风险，主流云厂商的托管容器服务鲜有提供可自主验证的控制面故障恢复手段，而社区开源能力也无法打通托管 Master 的演练渠道。这使得控制面的维护对企业而言如同一个“黑盒”：

用户无法主动模拟 etcd 高负载、kube-apiserver 停服等核心故障场景；
用户难以量化评估控制面异常对自身业务的真实影响时长和严重程度；
托管服务的便捷性背后，隐藏着用户对核心组件稳定性的被动依赖和掌控力缺失。

这种“黑盒”状态，使得企业在追求高可用架构时，对最关键的风险环节——控制面稳定性，缺乏有效的主动验证和掌控能力。

破局：基于 Playbook 模式开放控制面演练能力

面对托管控制面“不可知、不可控”的行业困境，团队认为开放真实的故障演习能力是_破解_服务黑盒性的唯一路径。因此，我们基于 TKE 原生防护架构（如全链路流控、资源策略保护、单集群提供多套业务专属kube-apiserver/etcd），研发了三大核心原子化演习能力：组件级压力测试（如kube-apiserver/etcd 高负载）、节点级故障注入（如 Master 关机）、防护策略有效性验证（如误删防护触发检测）。但真实的业务故障演练，从来不是单一原子化操作，更多的是模拟业务实际使用场景、再结合业务领域关键链路等进行统一演练，这意味着：

原子化能力是基础：必须具备将故障抽象为可复用的标准化操作（如“关机”“负载注入”）的能力；
场景化编排是核心：演练需融合专家经验，覆盖从单点故障到复杂故障链的全生命周期（预检→业务负载模拟->故障注入→指标采集→恢复→后检）。

如上，围绕故障演练的原子化能力实现场景化交付成为本项目的关键目标，常见的“最佳实践”文档大多按照“控制台操作+自然语言描述”呈现，这种模式很难确保客户的每一步操作按照预期路线执行。同时，考虑大部分客户业务为多云部署、更期望能结合业务自身场景完成演练，我们意识到云 API 和云厂商耦合程度过高会不方便企业进行扩展和复用。

基于此，TKE 团队提出了 Playbook 交付模式，将接口能力抽象为原子化行为、将演练场景抽象为可编排的工作流。提供了一个包含各种脚手架的“工具箱”，将“高可用架构”从理论设计转化为可量化、可复现的工程实践。这正是 Playbook 模式交付的本质：在原子操作层提供标准化能力，在自动化任务层通过 Workflow 串联起全生命周期流程，最终将演练封装为开箱即用的场景化模版交付用户。

Playbook 故障演练介绍

控制面故障演练 Playbook 地址：

https://github.com/tkestack/tke-chaos-playbook

实现原理

下图基于 Argo Workflow 展示了故障演练的整体流程，通过定义清晰的流程模板可灵活配置不同故障场景。目前已支持的演练场景包括控制面组件（kube-apiserver、etcd）高负载压力演练、kubernetes-proxy/coredns 组件停服演练、关键资源误删除场景演练。

演练配置：选择演练场景，在执行演练前需要配置一些演练参数，如企微群通知、执行演练时长等，上述参数均提供了默认值，用户可以在不修改任何参数的情况下执行演练。
演练前校验：开始执行演练前会对目标集群完成健康检查校验，如演练集群中的 Node 和 Pod 的健康比例，低于阈值将不允许演练；只有存在演练标记资源才可执行演练。
执行演练：演练流程以 Argo Workflow 进行编排，包括故障注入、维持故障注入、故障恢复等主要步骤。
演练结果：可以通过访问 Argo Server UI 查看演练结果，我们也提供了企业_微信_群故障演练通知的能力，您可以通过配置 Webhook 进行企业_微信_群通知。

流程介绍

本节通过对 kube-apiserver 发起大量的洪泛 list 请求来实现 kube-apiserver 高负载故障注入场景演练，如下为 kube-apiserver 高负载故障注入 Playbook 的一部分。我们基于 Argo Workflow 模板构建了针对 kube-apiserver 的性能压测任务，通过模拟大量 list 请求来构建高负载测试环境，其参数配置支持自定义客户端数量、请求 QPS（每秒查询数）以及测试持续时间等关键指标。用户可根据实际业务场景需求，直接引用该标准化模板，并根据具体要求灵活调整相关参数配置。

---
# 功能说明: apiserver压测, 使用tke-chaos工具对apiserver发起大量洪泛list请求, 以构造apiserver高负载
apiVersion: argoproj.io/v1alpha1
kind: ClusterWorkflowTemplate
metadata:
  name: inject-stress-template
spec:
  entrypoint: inject-stress
  templates:
  - name: inject-stress
    # inject-stress 参数
    inputs:
      parameters:
      - name: image
        default: "ccr.ccs.tencentyun.com/tkeimages/tke-chaos:v0.0.1"
        description: "压测工具镜像"
      - name: namespace
        default: ""
        description: "list请求的namespace, 如果为空, 则默认不限制namespace"
      - name: object-type
        default: "pods"
        description: "list的资源, 支持pods, configmaps"
      - name: page-size
        default: "0"
        description: "list是否分页, 默认值为0不分页"
      - name: num-clients
        default: "10"
        description: "list的客户端数, 默认值为1"
      - name: qps
        default: "1"
        description: "每秒的请求数, 默认值为1"
      - name: total-duration
        default: "30s"
        description: "总共持续多长时间, 默认值为30s"
      - name: from-cache
        default: "true"
        description: "是否从缓存中读取数据, 默认值为true, 如果为false, 则请求会击穿至etcd"
      - name: user-agent
        description: "list client UserAgent请求头"
  - name: internal-inject-stress
    inputs:
      parameters:
      # 避免篇幅过长，此处省略...
    container:
      image: "{{inputs.parameters.image}}"
      command:
      - /kubestress
      - list
      - --namespace={{inputs.parameters.namespace}}
      - --object-type={{inputs.parameters.object-type}}
      - --page-size={{inputs.parameters.page-size}}
      - --num-clients={{inputs.parameters.num-clients}}
      - --qps={{inputs.parameters.qps}}
      - --total-duration={{inputs.parameters.total-duration}}
      - --from-cache={{inputs.parameters.from-cache}}
      - --user-agent={{inputs.parameters.user-agent}}

演练示例

本节以 kube-apiserver 高负载场景进行故障演练流程演示。

前置条件

您需要准备两个 TKE 集群：源集群和目标集群。源集群用于执行演练流程，目标集群作为被演练集群。我们假设您在腾讯云拥有两个集群用于演练，并且这两个集群网络是互通的。

目标集群

在目标集群中创建 tke-chaos-test/tke-chaos-precheck-resource ConfigMap，该资源用于标识目标集群可执行演练测试。

kubectl create ns tke-chaos-test && kubectl create -n tke-chaos-test configmap tke-chaos-precheck-resource --from-literal=empty=""

源集群

从腾讯云 TKE 控制台获取目标集群的内网接入 kubeconfig 凭证写入到 dest-cluster-kubeconfig 文件，并在源集群中执行如下命令创建目标集群的 kubeconfig 的 secret。

kubectl create ns tke-chaos-test && kubectl create -n tke-chaos-test secret generic dest-cluster-kubeconfig --from-file=config=./dest-cluster-kubeconfig

克隆故障演练 Playbook 项目，并在源集群中部署 Argo Workflow（若 Argo 已存在则无需重复部署）。

# 克隆项目
git clone https://github.com/tkestack/tke-chaos-playbook.git && cd tke-chaos-playbook

# 部署Argo Workflow
kubectl create -f playbook/install-argo.yaml

# 验证Argo Workflow Pod正常运行
kubectl get po -n tke-chaos-test

腾讯云 TKE 控制台开启 tke-chaos-test/tke-chaos-argo-workflows-server Service 公网访问，浏览器访问 LoadBalancer IP:2746，执行如下命令获取的 Argo Server UI 接入凭证登录 Argo UI，Argo UI 可查看演练流程的详细信息。

# 获取Argo Server UI接入凭证
kubectl exec -it -n tke-chaos-test deployment/tke-chaos-argo-workflows-server -- argo auth token

执行工作流

执行如下命令创建 kube-apiserver 演练工作流：

kubectl create -f playbook/rabc.yaml && kubectl create -f playbook/all-in-one-template.yaml && kubectl create -f playbook/workflow/apiserver-overload-scenario.yaml

通过 Argo Server UI，查看演练流程，从界面可以看到每一个执行流程，如预检阶段执行成功：

对 kube-apiserver 进行压力注入的施压并发 Pod 数、单个施压 Pod QPS 并发数以及持续时间等详细（您可在演练开始前调整这些参数，以设置压力大小）：

效果观测

您可以通过 TKE 控制台的监控告警菜单查看 kube-apiserver 详细的监控信息观察负载情况，如下的 CPU、内存监控信息：

演练 kube-apiserver 高负载演练过程中，您需要关注您的业务 Pod 监控告警，以判断 kube-apiserver 高负载是否会对您的业务造成影响。

结语

本文阐述了基于 Playbook 交付的 K8s 控制面故障演练能力，凭借场景化交付、可编排、自助式执行等优势填补了容器托管服务下对控制面故障演练能力的缺失。基于 Playbook 故障演练模式，以及 TKE 团队提供的 K8s 控制面稳定性一系列解决方案，业务可实现从被动救火到主动防御，从手工注入故障进阶到基于声明式 API 驱动型，实现无人值守、常态化的自动化演练，高效保障好的业务可用性。

未来，我们将持续扩展演练场景，如托管 kube-apiserver、kube-controller-manager、kube-scheduler 等停服演练预计下周上线。社区的力量是推动项目持续进步的核心动力，欢迎大家一起参与共建！若对控制面故障演练能力感兴趣，可通过大客户售后或架构师渠道咨询、交流，也可以通过 Github issue 和 pr 反馈、解决问题。