TKE Skill 使用场景指南

本文档从 TKE Skill 用户的真实使用场景 出发，定义端到端的 User Story。每个 Story 代表一个完整的业务场景，展示 AI + TKE Skill 如何协同完成复杂任务。

!!! tip ”🔗 获取 TKE Skill” 下载地址：TKE Skill

!!! warning “⚠️ 安全与隔离建议” 在实践以下场景时，请注意：

- **巡检/排障场景**（场景 2、4、10）：建议使用 **只读权限** 账号，避免误操作影响生产环境
- **部署场景**（场景 9）：建议先在 **开发测试集群** 验证，确认无误后再应用到生产环境
- **权限管理场景**（场景 8）：为租户分配权限时遵循最小权限原则，按需授权
- **凭证安全**：生成的 kubeconfig 和 Token 应妥善保管，定期轮换

用户角色定义

角色	描述	典型场景
平台管理员	负责 TKE 平台的规划、建设和运维	集群规划、资源盘点、容量管理
DevOps 工程师	负责应用的持续集成和部署	环境搭建、部署流水线、镜像管理
开发工程师	负责应用开发和调试	集群接入、应用调试、日志查看
SRE 工程师	负责服务可靠性和故障处理	巡检、告警、故障定位

场景 1: 新员工集群接入

场景描述

作为一名新入职的开发工程师
我想要 快速获取公司 TKE 集群的访问权限
以便于 能够在本地使用 kubectl 进行开发和调试

业务背景

新员工入职后，需要：

了解公司有哪些 K8s 集群可用
找到自己团队应该使用的集群
获取集群访问凭证
验证能够正常连接集群

AI 执行步骤

1. 查询所有可用集群，了解集群全貌
   - 列出集群名称、版本、节点数、状态
   - 识别出运行中的集群

2. 根据集群名称或标签找到目标集群
   - 假设团队使用的集群名包含 "test" 或 "dev"

3. 检查目标集群的健康状态
   - 集群状态是否为 Running
   - 节点是否全部就绪

4. 检查集群的访问端点
   - 是否已开启外网访问（远程办公需要）
   - 如未开启，提示需要申请开通

5. 获取 kubeconfig
   - 获取外网 kubeconfig
   - 验证 kubeconfig 格式正确

6. 输出接入指南
   - kubeconfig 保存路径建议
   - kubectl 测试命令

验收标准

AC	描述	验证方法
AC1	能够列出所有集群并显示关键信息	返回集群列表，包含名称、状态、版本
AC2	能够识别运行中的集群	过滤出 status=Running 的集群
AC3	能够检查集群健康度	节点全部 running 视为健康
AC4	能够判断外网访问是否可用	端点状态为 Created
AC5	能够获取有效的 kubeconfig	kubeconfig 包含必要配置
AC6	生成完整的接入指南	输出可执行的操作步骤

预期输出示例

================================================================================
🎯 TKE 集群接入向导
================================================================================

📋 可用集群列表:
┌────────────────┬──────────────────┬─────────┬────────┬───────┐
│ 集群 ID        │ 名称             │ 版本    │ 节点数 │ 状态  │
├────────────────┼──────────────────┼─────────┼────────┼───────┤
│ cls-xxxxxxxx   │ dev-cluster      │ 1.30.0  │ 2      │ ✅ 运行中 │
│ cls-yyyyyyyy   │ production       │ 1.28.0  │ 10     │ ✅ 运行中 │
└────────────────┴──────────────────┴─────────┴────────┴───────┘

🎯 目标集群: dev-cluster (cls-xxxxxxxx)

🏥 健康检查:
  ✅ 集群状态: Running
  ✅ 节点状态: 2/2 运行中
  ✅ 外网访问: 已开启

🔑 获取访问凭证:
  ✅ kubeconfig 已获取

📝 接入指南:
  1. 保存 kubeconfig:
     export KUBECONFIG=/tmp/tke-kubeconfig

  2. 测试连接:
     kubectl cluster-info
     kubectl get nodes

  3. 查看命名空间:
     kubectl get namespaces

================================================================================

场景 2: 集群资源巡检

场景描述

作为一名 SRE 工程师
我想要 对所有 TKE 集群进行快速健康巡检
以便于 及时发现潜在问题，保障服务稳定性

业务背景

SRE 需要定期（每天/每周）对集群进行巡检：

检查所有集群的运行状态
检查节点健康状况
检查访问端点可用性
生成巡检报告，标记异常项

AI 执行步骤

1. 获取所有集群列表

2. 对每个集群进行健康检查:
   a. 集群状态检查
      - Running: 正常
      - Creating/Upgrading: 警告（进行中）
      - Abnormal: 严重告警

   b. 节点健康检查
      - 统计 running/initializing/failed 节点数
      - 计算健康率 = running / total
      - 健康率 < 100%: 警告
      - 健康率 < 80%: 严重告警

   c. 端点可用性检查
      - 检查内网/外网端点状态
      - 未开启: 信息提示
      - Creating: 警告
      - Created: 正常

3. 汇总巡检结果
   - 统计正常/警告/严重告警数量
   - 列出所有异常项
   - 给出处理建议

4. 生成巡检报告

验收标准

AC	描述	验证方法
AC1	能够遍历所有集群	对每个集群都执行检查
AC2	能够正确判断集群状态	Running=正常，Abnormal=严重
AC3	能够计算节点健康率	健康率 = running节点数 / 总节点数
AC4	能够检查端点状态	识别端点是否可用
AC5	能够生成分级告警	正常/警告/严重三级
AC6	生成结构化巡检报告	包含汇总和详情

预期输出示例

================================================================================
📊 TKE 集群巡检报告
================================================================================
巡检时间: 2026-03-17 17:30:00
巡检范围: ap-guangzhou 地域所有集群

📈 巡检汇总:
┌──────────┬───────┐
│ 级别     │ 数量  │
├──────────┼───────┤
│ ✅ 正常  │ 2     │
│ ⚠️ 警告  │ 0     │
│ ❌ 严重  │ 0     │
└──────────┴───────┘

📋 详细检查结果:

【集群 1】dev-cluster (cls-xxxxxxxx)
├── 集群状态: ✅ Running
├── K8s 版本: 1.30.0
├── 节点健康: ✅ 2/2 (100%)
│   ├── 10.0.1.10 - running
│   └── 10.0.1.11 - running
├── 内网端点: ℹ️ 未开启
└── 外网端点: ✅ 已开启 (xx.xx.xx.xx:443)

================================================================================
📝 巡检结论: 所有集群运行正常，无需处理
================================================================================

场景 3: 新项目环境规划

场景描述

作为一名平台管理员
我想要 为新项目规划 TKE 集群部署方案
以便于 选择合适的网络、可用区和集群配置

业务背景

新项目立项后，需要：

盘点现有基础设施资源（VPC、子网、安全组）
评估可用区的容量和限制
了解可选的 K8s 版本
生成环境规划建议

AI 执行步骤

1. 盘点 VPC 资源
   - 列出所有 VPC
   - 统计每个 VPC 的子网数量和可用 IP
   - 识别适合部署的 VPC（非默认、IP 充足）

2. 分析子网分布
   - 按可用区统计子网
   - 计算每个可用区的可用 IP 总量
   - 识别 IP 资源紧张的子网

3. 检查安全组配置
   - 列出可用安全组
   - 识别适合 TKE 的安全组（名称包含 tke/k8s/container）

4. 分析可用区状态
   - 哪些可用区可用
   - 推荐的可用区（基于子网 IP 充足度）

5. 获取 K8s 版本信息
   - 可选版本列表
   - 推荐版本（最新稳定版）

6. 生成规划建议
   - 推荐的 VPC
   - 推荐的子网和可用区
   - 推荐的 K8s 版本
   - 预估可支撑的节点规模

验收标准

AC	描述	验证方法
AC1	能够盘点 VPC 资源	列出所有 VPC 及其子网
AC2	能够计算 IP 可用量	汇总每个 VPC/子网的可用 IP
AC3	能够分析可用区分布	按可用区统计资源
AC4	能够推荐部署方案	基于资源情况给出建议
AC5	能够推荐 K8s 版本	列出版本并标记推荐
AC6	生成完整规划报告	包含资源盘点和建议

预期输出示例

================================================================================
📐 TKE 集群环境规划报告
================================================================================

📦 VPC 资源盘点:
┌────────────────┬──────────┬────────────────┬──────────┬───────────┐
│ VPC ID         │ 名称     │ CIDR           │ 子网数   │ 可用 IP   │
├────────────────┼──────────┼────────────────┼──────────┼───────────┤
│ vpc-xxxxxxxx   │ dev      │ 10.0.0.0/16    │ 3        │ 12,500    │
│ vpc-yyyyyyyy   │ prod     │ 172.16.0.0/16  │ 5        │ 8,200     │
└────────────────┴──────────┴────────────────┴──────────┴───────────┘

📍 可用区资源分布:
┌─────────────────┬──────────┬───────────┬─────────────┐
│ 可用区          │ 子网数   │ 可用 IP   │ 推荐度      │
├─────────────────┼──────────┼───────────┼─────────────┤
│ ap-guangzhou-3  │ 2        │ 8,000     │ ⭐⭐⭐ 推荐 │
│ ap-guangzhou-6  │ 2        │ 6,500     │ ⭐⭐ 良好   │
│ ap-guangzhou-7  │ 2        │ 6,200     │ ⭐⭐ 良好   │
└─────────────────┴──────────┴───────────┴─────────────┘

🔐 安全组:
  推荐使用: sg-xxxxxxxx (tke-default-sg)

📦 K8s 版本:
┌─────────┬────────────┐
│ 版本    │ 推荐度     │
├─────────┼────────────┤
│ 1.30.0  │ ⭐ 稳定版  │
│ 1.32.2  │ ⭐ 新版本  │
│ 1.34.1  │ 最新版     │
└─────────┴────────────┘

💡 规划建议:
┌─────────────┬──────────────────────────────────────────┐
│ 配置项      │ 推荐值                                   │
├─────────────┼──────────────────────────────────────────┤
│ VPC         │ vpc-xxxxxxxx (dev) - IP 资源充足        │
│ 子网        │ subnet-xxxxxxxx (ap-guangzhou-3)        │
│ 可用区      │ ap-guangzhou-3                          │
│ 安全组      │ sg-xxxxxxxx                             │
│ K8s 版本    │ 1.30.0 (稳定版)                         │
│ 预估容量    │ 可支撑约 200 个节点                      │
└─────────────┴──────────────────────────────────────────┘

================================================================================

场景 4: 集群访问故障排查

场景描述

作为一名开发工程师
我想要 排查无法连接 TKE 集群的问题
以便于 快速恢复开发工作

业务背景

开发人员反馈 kubectl 无法连接集群，需要：

确认集群是否正常运行
检查访问端点状态
验证 kubeconfig 是否有效
定位问题原因并给出解决方案

AI 执行步骤

1. 验证集群存在且运行中
   - 查询集群状态
   - 如果不存在：提示集群 ID 错误
   - 如果非 Running：提示集群状态异常

2. 检查节点健康状况
   - 如果没有健康节点：可能影响 API Server

3. 检查访问端点
   - 内网端点状态
   - 外网端点状态
   - 根据用户网络环境判断应该使用哪个端点

4. 获取并验证 kubeconfig
   - 检查 server 地址是否与端点匹配
   - 检查证书是否存在

5. 生成诊断报告
   - 问题定位
   - 解决建议

验收标准

AC	描述	验证方法
AC1	能够验证集群状态	正确识别集群是否正常
AC2	能够检查端点可用性	识别端点状态
AC3	能够验证 kubeconfig	检查关键配置
AC4	能够定位问题原因	给出具体问题描述
AC5	能够给出解决建议	针对问题给出操作步骤

预期输出示例

================================================================================
🔍 TKE 集群访问故障诊断
================================================================================
目标集群: cls-xxxxxxxx

📋 诊断检查项:

1️⃣ 集群状态检查
   ✅ 集群存在
   ✅ 状态: Running
   ✅ 版本: 1.30.0

2️⃣ 节点健康检查
   ✅ 节点总数: 2
   ✅ 健康节点: 2
   ✅ API Server 应该可用

3️⃣ 访问端点检查
   ├── 内网端点: ❌ 未开启
   └── 外网端点: ✅ 已开启
       地址: xx.xx.xx.xx:443

4️⃣ Kubeconfig 检查
   ✅ 成功获取 kubeconfig
   ✅ Server 地址: https://xx.xx.xx.xx:443
   ✅ 证书配置存在

================================================================================
📊 诊断结果: 集群访问配置正常
================================================================================

💡 如果仍无法连接，请检查:
   1. 本地网络是否能访问外网 IP xx.xx.xx.xx
   2. 防火墙是否放行 443 端口
   3. kubeconfig 文件路径是否正确设置

   测试命令:
   $ telnet xx.xx.xx.xx 443
   $ kubectl --kubeconfig=/path/to/config cluster-info

================================================================================

场景 5: 多集群资源对比

场景描述

作为一名平台管理员
我想要 对比多个 TKE 集群的配置和资源使用情况
以便于 进行容量规划和成本优化

业务背景

企业有多个集群（开发、测试、生产），需要：

对比各集群的配置差异
分析资源使用情况
识别配置不一致的问题
发现潜在的优化点

AI 执行步骤

1. 获取所有集群信息
   - 基本配置（版本、类型、运行时）
   - 节点数量和规格
   - 网络配置

2. 生成对比矩阵
   - 版本对比
   - 节点规模对比
   - 网络配置对比

3. 识别差异和问题
   - 版本不一致
   - 配置不一致
   - 资源使用不均衡

4. 给出优化建议
   - 版本升级建议
   - 资源调整建议

验收标准

AC	描述	验证方法
AC1	能够获取多集群信息	返回所有集群的详细配置
AC2	能够生成对比矩阵	横向对比关键配置
AC3	能够识别差异	标记不一致的配置
AC4	能够给出建议	针对问题给出优化建议

场景 6: 集群扩容前检查

场景描述

作为一名运维工程师
我想要 在集群扩容前进行资源检查
以便于 确保扩容操作能够成功执行

业务背景

集群需要扩容节点，扩容前需要：

检查目标子网的 IP 是否充足
检查目标可用区是否可用
检查安全组配置
评估扩容风险

AI 执行步骤

1. 获取集群当前配置
   - 所在 VPC、子网、可用区
   - 当前节点数量

2. 检查子网 IP 余量
   - 获取子网可用 IP 数
   - 计算扩容所需 IP（节点数 + Pod 预留）
   - 判断是否充足

3. 检查可用区状态
   - 目标可用区是否可用

4. 检查安全组
   - 安全组是否存在
   - 是否有必要的规则（TKE 需要的端口）

5. 生成扩容检查报告
   - 资源是否充足
   - 风险评估
   - 扩容建议

验收标准

AC	描述	验证方法
AC1	能够获取集群网络配置	返回 VPC、子网信息
AC2	能够检查 IP 余量	计算可用 IP 数
AC3	能够检查可用区状态	返回可用区状态
AC4	能够评估扩容风险	给出风险等级
AC5	能够生成检查报告	包含检查结果和建议

场景 7: TCR 镜像仓库集成检查

场景描述

作为一名 DevOps 工程师
我想要 检查 TKE 集群与 TCR 镜像仓库的集成状态
以便于 确保 CI/CD 流水线能够正常推送和拉取镜像

业务背景

应用部署需要：

确认 TCR 实例存在且可用
检查命名空间配置
验证集群能够访问 TCR
生成镜像仓库使用指南

AI 执行步骤

1. 检查 TCR 实例
   - 列出所有 TCR 实例
   - 检查实例状态
   - 获取实例域名

2. 检查命名空间
   - 列出实例下的命名空间
   - 检查是否有项目对应的命名空间

3. 生成集成指南
   - Docker 登录命令
   - 镜像推送示例
   - K8s ImagePullSecret 配置

验收标准

AC	描述	验证方法
AC1	能够检查 TCR 实例状态	返回实例列表和状态
AC2	能够列出命名空间	返回命名空间列表
AC3	能够生成集成指南	包含可执行的命令

场景 8: 多租户权限管理与 Agent 分发（🆕 新场景）

场景描述

作为一名集群管理员
我想要 快速为新团队创建 K8s 访问权限并生成 AI Agent 安装 Prompt
以便于 租户无需学习 kubectl 就能用自然语言管理自己的命名空间

业务背景

企业 K8s 集群通常是多团队共享的，集群管理员面临以下挑战：

权限配置繁琐：为每个租户创建 RBAC 角色、RoleBinding、ServiceAccount 需要大量手工操作
凭证分发困难：生成 kubeconfig 后，如何安全、便捷地交付给租户是个问题
知识门槛高：即使有了凭证，租户（尤其是开发者）也不一定会用 kubectl

TKE Skill v2.0 的多租户 RBAC 管理功能，可以将这三个问题一次性解决。

AI 执行步骤

1. 解析用户权限需求
   - 租户名称（如 team-frontend）
   - 目标命名空间（如 frontend, frontend-staging）
   - 权限级别（readonly/developer/admin/custom）

2. 创建 RBAC 资源
   - ServiceAccount: tke-tenant-{租户名}
   - Role: 基于权限级别模板
   - RoleBinding: 绑定 SA 和 Role

3. 获取租户 Token
   - 使用 kubectl create token
   - 支持设置过期时间

4. 生成一键安装 Prompt
   - 包含 kubeconfig 配置
   - 包含 Token
   - 包含使用说明
   - 可直接发给租户执行

5. 输出安装指南
   - 租户粘贴 Prompt 到自己的 Agent
   - 自动完成配置
   - 开始使用自然语言操作 K8s

验收标准

AC	描述	验证方法
AC1	能够创建完整的 RBAC 资源	SA + Role + RoleBinding 都已创建
AC2	权限级别正确	readonly/developer/admin 权限符合预期
AC3	能够获取有效 Token	Token 可用于 API 认证
AC4	能够生成可执行的 Prompt	租户可直接使用
AC5	租户能够正常操作	权限范围内的操作都能成功

预期输出示例

管理员创建租户：

管理员：帮我创建一个账号 team-frontend，权限级别 developer，可以访问 frontend 命名空间

Agent：
正在创建租户 RBAC 资源...

✅ 已创建以下资源：
┌─────────────────────────────────────────────────────────────────┐
│ ServiceAccount: tke-tenant-team-frontend                        │
│ Namespace: frontend                                             │
├─────────────────────────────────────────────────────────────────┤
│ Role: tke-tenant-team-frontend-role                             │
│ 权限级别: developer                                              │
│ 权限:                                                           │
│   - pods: get, list, watch, create, update, patch, delete       │
│   - deployments: get, list, watch, create, update, patch, delete│
│   - services: get, list, watch, create, update, patch, delete   │
│   - configmaps/secrets: get, list, watch, create, update, patch │
├─────────────────────────────────────────────────────────────────┤
│ RoleBinding: tke-tenant-team-frontend-binding                   │
│ 绑定命名空间: frontend                                           │
└─────────────────────────────────────────────────────────────────┘

需要我生成该租户的安装 Prompt 吗？

管理员生成安装 Prompt：

管理员：帮我生成 team-frontend 的安装 Prompt

Agent：
📋 已生成安装 Prompt，请将以下内容发送给 team-frontend 团队成员：

---
# TKE Skill 一键安装 Prompt
# 租户: team-frontend | 命名空间: frontend | 集群: my-tke-cluster

## 步骤 1：保存 kubeconfig
将以下内容保存到 ~/.kube/tke-tenant-team-frontend.config：

```yaml
apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority-data: LS0tLS1...
    server: https://xx.xx.xx.xx:443
  name: my-tke-cluster
contexts:
- context:
    cluster: my-tke-cluster
    namespace: frontend
    user: tke-tenant-team-frontend
  name: tke-tenant-team-frontend@my-tke-cluster
current-context: tke-tenant-team-frontend@my-tke-cluster
users:
- name: tke-tenant-team-frontend
  user:
    token: eyJhbGciOiJSUzI1...

步骤 2：配置环境变量

export KUBECONFIG=~/.kube/tke-tenant-team-frontend.config

步骤 3：验证连接

kubectl get pods -n frontend

**租户使用 Agent：**

租户：帮我查看 frontend 命名空间的 Pod 状态

Agent： 📋 frontend 命名空间 Pod 列表： ┌───────────────────────┬─────────┬──────────┬──────────┐ │ Pod 名称 │ 状态 │ 重启次数 │ 运行时间 │ ├───────────────────────┼─────────┼──────────┼──────────┤ │ frontend-web-abc123 │ Running │ 0 │ 2d │ │ frontend-api-def456 │ Running │ 1 │ 1d │ └───────────────────────┴─────────┴──────────┴──────────┘

### 核心价值

| 传统方式 | TKE Skill 多租户管理 |
|---------|---------------------|
| 手写 RBAC YAML | **一句话描述权限** |
| 手动分发 kubeconfig | **生成一键安装 Prompt** |
| 培训租户使用 kubectl | **租户直接用自然语言操作** |
| 权限变更需要重新配置 | **修改 RBAC 后重新生成 Prompt** |

---

## 场景 9: 一句话部署应用（✅ 已验证）

### 场景描述

**作为** 一名开发工程师
**我想要** 用自然语言将应用部署到 TKE 集群
**以便于** 无需手写 YAML 就能完成应用上线

### 业务背景

开发者用 AI 写完代码后，想部署到 K8s，却面临：

1. 需要学习 Dockerfile 编写
2. 需要理解 Deployment、Service、ConfigMap 等概念
3. 需要配置资源限制、健康检查等最佳实践
4. 需要处理镜像构建、推送等流程

### AI 执行步骤

分析部署需求
- 识别应用类型（静态页面/Web 应用/后端服务）
- 确定目标集群和命名空间
设计部署方案
- 选择合适的基础镜像
- 设计架构（如需要处理 ARM/x86 兼容性）
生成 K8s 资源
- 编写 Deployment YAML
- 编写 Service YAML（如需外网访问）
- 编写 ConfigMap（如需配置文件）
执行部署
- kubectl apply 部署资源
- 等待 Pod 就绪
- 获取访问地址
验证部署结果
- 检查 Pod 状态
- 测试服务可访问性

### 验收标准

| AC | 描述 | 验证方法 |
|----|------|----------|
| AC1 | 能够理解自然语言部署需求 | 正确解析"部署静态页面"等指令 |
| AC2 | 能够生成正确的 YAML | 资源配置符合最佳实践 |
| AC3 | 能够执行 kubectl apply | 资源成功创建 |
| AC4 | 能够处理架构兼容问题 | ARM/x86 混合集群正常部署 |
| AC5 | 能够返回访问地址 | 用户可访问部署的应用 |

### 预期输出示例

用户：帮我部署一个”你好，猴哥”静态页面到 TKE 集群

Agent： 📋 分析部署需求… ✅ 应用类型: 静态页面 ✅ 目标集群: cls-xxxxxxxx ✅ 目标命名空间: default

🛠️ 正在生成部署配置… ✅ 已生成 Deployment (nginx + 静态内容) ✅ 已生成 Service (LoadBalancer) ✅ 已生成 ConfigMap (HTML 内容)

🚀 正在部署… ✅ ConfigMap 已创建 ✅ Deployment 已创建 ✅ Service 已创建

⏳ 等待 Pod 就绪… ✅ Pod hello-monkey-xxx Running (1/1)

🎉 部署完成！ ┌─────────────────────────────────────────────────────────┐ │ 应用名称: hello-monkey │ │ 访问地址: http://119.91.184.206 │ │ Pod 状态: 1/1 Running │ └─────────────────────────────────────────────────────────┘

### 实际验证结果

| 应用 | 类型 | 部署结果 | 访问地址 |
|------|------|----------|----------|
| 应用1 | 静态页面（"你好，猴哥"） | ✅ 成功 | http://119.91.184.206 |
| 应用2 | 复杂应用（需打包镜像） | ✅ 成功 | http://119.91.188.55 |

---

## 场景 10: 智能运维排障（✅ 已验证）

### 场景描述

**作为** 一名开发工程师或 SRE
**我想要** 让 AI 帮我排查 K8s 应用故障
**以便于** 快速定位问题原因并恢复服务

### 业务背景

应用部署或运行时出现问题，传统排障流程：

1. 登录控制台查看 Pod 状态
2. 查看 Events 找线索
3. 查看容器日志
4. 搜索文档/Google
5. 不行就找 SRE...

### AI 执行步骤

获取 Pod 状态
- kubectl get pods
- 识别异常 Pod（Pending/CrashLoopBackOff/Error）
分析 Pod 详情
- kubectl describe pod
- 查看 Events 和状态条件
查看容器日志
- kubectl logs
- 分析错误信息
诊断问题根因
- 镜像拉取失败？
- 资源不足？
- 配置错误？
- 架构不兼容？
给出解决方案
- 针对具体问题提供修复步骤
- 必要时直接执行修复

### 验收标准

| AC | 描述 | 验证方法 |
|----|------|----------|
| AC1 | 能够识别异常 Pod | 正确找出问题 Pod |
| AC2 | 能够分析 Pod Events | 提取关键错误信息 |
| AC3 | 能够查看容器日志 | 获取应用错误日志 |
| AC4 | 能够诊断问题根因 | 给出正确的问题原因 |
| AC5 | 能够给出解决方案 | 方案可执行且有效 |

### 预期输出示例

用户：帮我检查 my-app 为什么部署失败

Agent： 🔍 正在分析 Pod 状态…

📋 发现问题 Pod: my-app-7d9f8b6c5d-xxxxx ┌─────────────────────────────────────────────────────────┐ │ 状态: CrashLoopBackOff │ │ 重启次数: 5 │ │ 最近重启: 2 分钟前 │ └─────────────────────────────────────────────────────────┘

📊 Events 分析: ✅ 镜像拉取: 成功 ✅ 容器创建: 成功 ❌ 容器启动: 失败

📜 日志分析: Error: Cannot find module ‘/app/config.json’

💡 诊断结论: 问题原因: 应用配置文件缺失根因分析: Deployment 未挂载 ConfigMap

🔧 解决方案:

创建 ConfigMap 包含配置文件
更新 Deployment 添加 volumeMounts
重新部署

是否需要我帮你执行修复？

### 实际验证结果

在部署复杂应用时，AI 成功完成了：

| 排障步骤 | 执行结果 |
|----------|----------|
| 分析 Pod 状态和事件 | ✅ 正确识别问题 |
| 查看容器日志 | ✅ 获取错误信息 |
| 诊断问题根因 | ✅ 识别 ARM/x86 架构不兼容 |
| 设计解决方案 | ✅ 提出 Nginx + Sidecar 模式 |
| 执行修复 | ✅ 部署成功 |

---

## 场景优先级

| 优先级 | 场景 | 说明 |
|--------|------|------|
| P0 | 场景 1 新员工集群接入 | 最常见场景 |
| P0 | 场景 2 集群资源巡检 | 运维必备 |
| P0 | 场景 8 多租户权限管理 | 🆕 v2.0 新增核心能力 |
| P0 | 场景 9 一句话部署应用 | ✅ 已验证 |
| P0 | 场景 10 智能运维排障 | ✅ 已验证 |
| P1 | 场景 3 新项目环境规划 | 规划场景 |
| P1 | 场景 4 集群访问故障排查 | 故障场景 |
| P2 | 场景 5 多集群资源对比 | 管理场景 |
| P2 | 场景 6 集群扩容前检查 | 运维场景 |
| P2 | 场景 7 TCR 镜像仓库集成 | 集成场景 |

---

## 测试环境要求

- 至少存在一个运行中的 TKE 集群
- 集群有 2 个以上节点
- 已配置腾讯云 API 凭证

---

## 相关文档

- [AI Copilot 概述](index.md) - 模块介绍和学习目标
- [TKE Skill 介绍](tke-skill.md) - AI Agent 的 K8s 运维能力
- kubernetes-mcp-server 集成 - MCP 协议集成方案
- POC 演示案例 - 实际验证案例（一句话部署、智能排障）