eks-workload-best-practice-assessment

EKS 工作负载最佳实践评估

根据 K8s 官方文档和 EKS 最佳实践指南评估 Amazon EKS 上的 Kubernetes 工作负载。 涵盖 8 个维度：工作负载配置、安全性、可观测性、网络、存储、EKS 平台集成、CI/CD 和镜像安全。

前提条件

此技能需要：

• aws knowledge mcp server 工具：
  • aws___search_documentation — 搜索 AWS 文档
  • aws___read_documentation — 阅读完整文档页面
  • aws___recommend — 获取相关文档
• context7 MCP 工具：
  • context7_resolve-library-id — 解析 K8s 库 ID
  • context7_query-docs — 查询 K8s 文档
• AWS CLI（aws）— 已配置对目标 EKS 集群和 ECR 的读取权限
• kubectl — 已配置为访问目标 EKS 集群
• jq — 用于解析 AWS CLI 和 kubectl 命令的 JSON 输出

范围边界

此技能侧重于工作负载级检查——需要使用 kubectl 或在集群内进行检查的项目。它与涵盖基础设施层（控制平面、节点组、附加组件等）的 aws-best-practice-research 相辅相成。

此技能（工作负载层）	aws-best-practice-research（基础设施层）
Pod 资源请求/限制	控制平面配置
探针（存活、就绪、启动）	节点组规模和可用区分布
PDB、拓扑约束	附加组件版本
Pod 安全上下文、PSA	Secret 信封加密
网络策略	集群网络（VPC、子网）
服务账户、RBAC	身份验证模式、访问条目
容器镜像扫描	GuardDuty EKS 保护
HPA/VPA/Karpenter 工作负载配置	Karpenter/CA 基础设施配置

工作流

步骤 1：确认评估范围

根据用户输入确定：

• 集群名称和AWS 区域
• 评估范围：
  • 整个集群 — 评估所有命名空间（默认排除 kube-system、kube-public、kube-node-lease）
  • 指定命名空间 — 用户指定的列表
  • 指定工作负载 — 用户指定的 Deployments/StatefulSets
• 是否包含基础设施层？ — 是否也调用 aws-best-practice-research 评估 EKS 基础设施层并合并结果（默认：是）

如果用户只提供集群名称，则默认评估整个集群。

步骤 2：环境检测与版本感知

运行以下命令以检测环境：

# Cluster info via AWS CLI
aws eks describe-cluster --name {CLUSTER} --region {REGION}

# K8s version
kubectl version --output=json

# Node distribution
kubectl get nodes -o wide --no-headers

记录：

• K8s 服务器版本（例如 1.30）— 用于版本感知筛选
• EKS 平台版本（例如 eks.15）
• 节点数量和可用区分布
• 节点实例类型

版本感知筛选规则（在步骤 3 中应用）：

• K8s >= 1.25：检查 Pod Security Admission（PSA），跳过 PodSecurityPolicy（PSP）
• K8s < 1.25：检查 PSP，并将 PSA 列为升级建议
• K8s >= 1.20：检查启动探针
• K8s >= 1.19：检查拓扑分布约束
• K8s >= 1.29 + VPC CNI >= 1.21.1：检查管理员网络策略
• EKS 支持 Pod Identity 时：优先使用 Pod Identity，而非 IRSA

步骤 3：动态最佳实践研究

使用 context7 和 aws-knowledge-mcp-server 研究最新最佳实践。 所有查询都必须按顺序执行（一次一个），以避免触发速率限制。

针对 8 个评估维度中的每一个，执行 references/search-queries.md 中定义的搜索查询。每个维度的一般流程如下：

1. 查询 context7（/websites/kubernetes_io），获取 Kubernetes 官方最佳实践
2. 查询 aws-knowledge-mcp-server，获取 EKS 专属最佳实践
3. 阅读搜索结果中的关键文档页面（每个维度最多 2～3 页）
4. 提取包含具体阈值和条件的检查项

所有研究完成后，将结果与 references/check-dimensions.md 中的基线框架合并，确保不遗漏任何关键维度。

应用步骤 2 中的版本筛选，移除不适用的检查项并添加特定版本的建议。

速率限制保护：如果任何 MCP 请求返回“Too many requests”，请等待 5 秒后重试一次。如果再次失败，则跳过并继续。必须按顺序执行。

步骤 4：基础设施层评估（可选）

如果包含基础设施层评估（默认：是）：

1. 为 EKS 集群调用 aws-best-practice-research 技能
2. 保存基础设施层检查清单和评估结果
3. 在步骤 7 中将这些内容合并到最终报告

如果用户选择不执行，请跳过此步骤。

步骤 5：工作负载数据收集

使用 kubectl 收集工作负载配置。独立命令可以并行运行 （不受 MCP 速率限制）。

完整命令列表请参阅 references/kubectl-assessment-commands.md。需要收集的关键数据：

# Core workloads
kubectl get deployments,statefulsets,daemonsets,jobs,cronjobs --all-namespaces -o json

# Pod specifications (within workloads above)
# Already included in the -o json output

# Disruption and scaling
kubectl get pdb,hpa --all-namespaces -o json

# Networking
kubectl get networkpolicies,services,ingresses --all-namespaces -o json

# Security
kubectl get serviceaccounts --all-namespaces -o json
kubectl get clusterrolebindings,rolebindings -o json

# Storage
kubectl get pvc,storageclass -o json

# Namespace labels (for PSA)
kubectl get namespaces -o json

# Events (recent issues)
kubectl get events --all-namespaces --sort-by='.lastTimestamp' -o json

对于ECR 镜像扫描（如果镜像来自 ECR）：

# For each unique ECR image found in workloads
aws ecr describe-image-scan-findings --repository-name {REPO} --image-id imageTag={TAG}
aws ecr describe-repositories --repository-names {REPO}
aws ecr get-lifecycle-policy --repository-name {REPO}

将收集的数据筛选至评估范围内（步骤 1 中的命名空间/工作负载）。

步骤 6：按维度评估

对于研究阶段（步骤 3）中的每项检查，评估范围内的每个工作负载：

状态	含义
PASS	工作负载配置达到或超过建议要求
FAIL	工作负载配置未达到建议要求
WARN	无法完全验证，或仅部分满足建议要求
N/A	此项检查不适用（例如，对无状态工作负载进行存储检查）

对于每项发现，记录：

• 检查项 ID 和名称
• 状态（PASS/FAIL/WARN/N/A）
• 观察到的实际值（不能只写“未配置”）
• 受影响的具体工作负载
• 版本相关说明（如有）

步骤 7：生成报告并保存到本地文件

使用 references/output-template.md 中的模板生成一份完整报告，并直接写入本地 Markdown 文件。

重要 — 文件写入规则：

• 使用 Write/文件工具（而不是 bash heredoc/echo/cat）创建报告文件
• 如果报告过长，无法一次写入，请拆分为多个部分：先将前半部分写入文件，再使用追加/编辑操作添加其余部分
• 请勿将完整报告内容输出到终端

使用以下文件命名约定：

TIMESTAMP=$(TZ=Asia/Shanghai date +%Y-%m-%d-%H-%M-%S)
CLUSTER_SLUG=$(echo "{CLUSTER_NAME}" | tr '[:upper:]' '[:lower:]' | tr ' :/' '-')

评估报告 — 请参阅 references/output-template.md

• 完整的集群概览
• 合规评分卡，包含评级标准、前 3 项优先事项和快速统计数据
• 按维度划分的评估表
• 按工作负载划分的详情部分
• 严重问题及按优先级排序的修复措施
• 数据来源和参考链接
• 保存至： ${TIMESTAMP}-${CLUSTER_SLUG}-assessment-report.md

如果步骤 4 中有基础设施层评估结果，请将其合并到报告中。

保存后，在终端打印简短摘要，仅列出：

• 生成的报告文件路径
• 总体合规分数
• PASS / FAIL / WARN 发现的数量

步骤 8：修复指导与后续步骤

保存报告后，提供以下选项：

• “我可以帮你修复特定的 FAIL 项——你想处理哪些？”
• “修复后，我可以重新运行评估以验证改进效果。”

对于严重问题（FAIL + 高优先级），提供：

• 具体的修复命令或清单变更
• 修复是否需要重启工作负载，还是可以原地完成
• 变更的影响评估

重要指南

• 全面检查：此技能的价值在于全面细致。宁可包含一项检查并将其标记为 N/A，也不要遗漏。
• 始终引用来源：每项检查都必须注明来源（EKS 最佳实践指南、K8s 官方文档等）。
• MCP 查询按顺序执行：所有 context7 和 aws-knowledge-mcp 请求都必须按顺序执行。kubectl 命令可以并行执行。
• 防止触发速率限制：遇到“Too many requests”时，等待 5 秒后重试一次。第二次失败则跳过。
• 关注版本：始终根据检测到的 K8s/EKS 版本筛选检查项。切勿推荐集群版本不支持的功能。
• 在发现项中提供实际值：始终报告实际观察到的内容，而不只是写“未配置”。 正确示例："resources.requests.memory: not set — 容器未设置内存请求" 错误示例：“缺少内存请求”
• 细化到每个工作负载：在单个 Deployment/StatefulSet 级别报告发现项，而不只是提供集群范围的摘要。
• 默认排除系统命名空间：跳过 kube-system、kube-public、kube-node-lease，除非用户明确要求包含。
• 遵循语言要求：使用与用户对话相同的语言输出。
• 区分基础设施与工作负载的边界：切勿重复 aws-best-practice-research 中的检查项。此技能仅处理需要 kubectl/集群内访问权限的内容。