kubernetes-specialist

Kubernetes 专家

目的

提供专业的 Kubernetes 编排和云原生应用知识，深入了解容器编排、集群管理和生产级部署。专长包括 Kubernetes 架构、Helm chart、运算符、多集群管理，以及适用于 EKS、AKS、GKE 和本地部署的 GitOps 工作流。

适用场景

• 为生产工作负载设计 Kubernetes 集群架构
• 实施 Helm chart、运算符或 GitOps 工作流（ArgoCD、Flux）
• 排查集群问题（网络、存储、性能）
• 规划 Kubernetes 升级或多集群策略
• 优化 Kubernetes 环境中的资源利用率和成本
• 设置服务网格（Istio、Linkerd）和可观测性
• 实施 Kubernetes 安全和 RBAC 策略

快速开始

在以下情况下调用此技能：

• 为生产工作负载设计 Kubernetes 集群架构
• 实施 Helm chart、运算符或 GitOps 工作流
• 排查集群问题（网络、存储、性能）
• 规划 Kubernetes 升级或多集群策略
• 优化 Kubernetes 环境中的资源利用率和成本

以下情况请勿调用：

• 仅需简单的 Docker 容器操作（直接使用 docker 命令）
• 配置云基础设施（改用 cloud-architect）
• 调试应用代码（改用 backend-developer/frontend-developer）
• 特定于数据库的问题（改用 database-administrator）

决策框架

部署策略选择

├─ Zero downtime required?
│   ├─ Instant rollback needed → Blue-Green Deployment
│   │   Pros: Instant switch, easy rollback
│   │   Cons: 2x resources during deployment
│   │
│   ├─ Gradual rollout → Canary Deployment
│   │   Pros: Test with subset of traffic
│   │   Cons: Complex routing setup
│   │
│   └─ Simple updates → Rolling Update (default)
│       Pros: Built-in, no extra resources
│       Cons: Rollback takes time
│
├─ Stateful application?
│   ├─ Database → StatefulSet + PVC
│   │   Pros: Stable network IDs, ordered deployment
│   │   Cons: Complex scaling
│   │
│   └─ Stateless → Deployment
│       Pros: Easy scaling, self-healing
│
└─ Batch processing?
    ├─ One-time → Job
    ├─ Scheduled → CronJob
    └─ Parallel processing → Job with parallelism

资源配置矩阵

工作负载类型	CPU 请求	CPU 限制	内存请求	内存限制
Web API	100m-500m	1000m	256Mi-512Mi	1Gi
Worker	500m-1000m	2000m	512Mi-1Gi	2Gi
数据库	1000m-2000m	4000m	2Gi-4Gi	8Gi
缓存	100m-250m	500m	1Gi-4Gi	8Gi
批处理任务	500m-2000m	4000m	1Gi-4Gi	8Gi

节点池策略

用例	实例类型	扩缩容	成本
系统 Pod	t3.large (3 nodes)	固定	低
应用	m5.xlarge	自动 3-20	中
批处理/Spot	m5.large-2xlarge	自动 0-50	极低
GPU 工作负载	p3.2xlarge	手动	高

危险信号 → 升级处理

遇到以下情况时，请停止并升级处理：

• 集群升级涉及会造成不兼容的 API 变更（已弃用版本）
• 需要多区域主动-主动部署
• 合规要求（PCI-DSS、HIPAA）需要验证
• 需要开发自定义调度器或控制器
• etcd 损坏或集群状态异常

质量检查清单

集群配置

• 多可用区部署（节点分布在多个可用区）
• 已配置节点自动扩缩容（Cluster Autoscaler 或 Karpenter）
• 系统节点池设置了污点（将关键附加组件与应用分开）
• 已启用加密（使用 KMS 加密静态存储的密钥）
• 已启用审计日志（API 服务器日志）

安全

• 已强制执行 Pod 安全标准（restricted 或 baseline）
• 已配置网络策略（默认拒绝 + 明确允许）
• 已配置 RBAC（所有服务账户均遵循最小权限原则）
• 已启用镜像扫描（扫描漏洞）
• 已配置私有容器镜像仓库

资源管理

• 所有 Pod 均设置了资源请求和限制
• 已为可扩缩工作负载配置 HorizontalPodAutoscaler
• 已定义 PodDisruptionBudget（防止过多 Pod 同时停机）
• 已为每个命名空间设置 ResourceQuota
• 已定义 LimitRange（为 Pod 设置默认限制）

高可用性

• Deployment 至少有 ≥2 个副本
• 反亲和性规则可防止 Pod 共置
• 已配置就绪探针和存活探针
• PodDisruptionBudget 允许滚动更新
• 多区域集群（如需全球规模部署）

可观测性

• 已安装指标服务器（kubectl top 可正常工作）
• Prometheus 正在监控应用指标
• 已配置集中式日志记录（CloudWatch、Elasticsearch、Loki）
• 已配置分布式追踪（Jaeger、Tempo）
• 已创建集群和应用健康状况仪表板

灾难恢复

• 已安装 Velero，用于集群备份
• 已配置备份计划（至少每天一次）
• 已测试恢复（每年演练一次）
• 已自动执行 etcd 备份（云托管集群）

其他资源

• 详细技术参考：请参阅 REFERENCE.md
• 代码示例与模式：请参阅 EXAMPLES.md