Back to skills
SKILL.md
Kubernetes Specialist
ASecurityUse when managing Kubernetes clusters, debugging Pods and workloads, designing Helm charts, reviewing manifests, or improving deployment, scaling, and observability practices.
- 70 stars
- 0 votes
- 0 copies
- 1 view
- Added September 12, 2026
Works with
Security analysis
100/100npx -y skills add seaworld008/Commonly-used-high-value-skills --skill kubernetes-specialist --agent claude-codeAre you the author of Kubernetes Specialist?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/seaworld008-kubernetes-specialist)---
name: kubernetes-specialist
description: 'Use when managing Kubernetes clusters, debugging Pods and workloads, designing Helm charts, reviewing manifests, or improving deployment, scaling, and observability practices.'
zh_description: "用于 Kubernetes 集群管理、Pod 调试、Helm Chart 设计、清单评审和部署优化。"
version: "1.0.0"
author: "seaworld008"
source: "skills.sh"
source_url: "https://skills.sh/jeffallan/claude-skills/kubernetes-specialist"
license: "MIT"
tags: '["development", "kubernetes", "specialist"]'
created_at: "2026-03-27"
updated_at: "2026-06-29"
quality: 4
complexity: "intermediate"
---
# Kubernetes Specialist
## 触发条件
- 需要部署新的微服务到 Kubernetes 集群时。
- 现有 Pod 出现故障、重启或性能瓶颈(如 CPU/Memory 限制)时。
- 需要设计或维护 Helm Charts 以实现应用的参数化部署。
- 配置集群自动扩缩容(HPA/VPA)以应对流量波动。
- 实施 RBAC 权限控制,确保多租户环境的安全。
- 进行集群范围的资源审计或配置优化(ConfigMap/Secret 管理)。
## 核心能力
### 1. 资源管理 (Resource Management)
- **Deployment**: 理解声明式更新,管理副本集、滚动更新策略(RollingUpdate vs Recreate)。
- **Service**: 熟练配置 ClusterIP、NodePort、LoadBalancer,理解 Endpoints 机制。
- **ConfigMap & Secret**: 将配置与代码解耦,理解 Secret 的 base64 编码及其实时挂载特性。
- **Volume**: 管理 PersistentVolume (PV) 和 PersistentVolumeClaim (PVC),配置持久化存储。
### 2. Pod 故障排查流程
- **Phase 1: 查看状态** - `kubectl get pods` 确认状态(Pending, Error, CrashLoopBackOff)。
- **Phase 2: 详情检查** - `kubectl describe pod <name>` 查看事件日志(Events),定位调度失败或探针失败原因。
- **Phase 3: 日志分析** - `kubectl logs <name> [-c container] [--previous]` 查看标准输出/错误流。
- **Phase 4: 运行时调试** - `kubectl exec -it <name> -- /bin/sh` 进入容器内部排查(如网络连通性)。
- **Phase 5: 临时调试容器** - 使用 `kubectl debug` 注入诊断容器。
### 3. Helm Chart 最佳实践
- **模板化**: 合理使用 `{{ .Values.xxx }}` 提取配置,支持多环境部署(values-dev.yaml, values-prod.yaml)。
- **依赖管理**: 使用 `Chart.yaml` 管理子 Chart 依赖。
- **Hook 机制**: 利用 `pre-install`, `post-upgrade` 等 Hooks 处理数据库迁移或清理任务。
- **版本控制**: 严格遵守 Semantic Versioning,确保 Chart 与应用镜像版本同步。
### 4. 自动扩缩容 (HPA/VPA)
- **HPA (Horizontal Pod Autoscaler)**: 基于 CPU/内存利用率或自定义指标(Custom Metrics)自动增减副本数。
- **VPA (Vertical Pod Autoscaler)**: 自动调整 Pod 的资源请求(Requests)和限制(Limits)。
- **Cluster Autoscaler**: 与云厂商集成,自动调整节点池大小。
### 5. 安全与 RBAC
- **Namespace 隔离**: 逻辑上划分开发、测试、生产环境。
- **RBAC**: 定义 Role/ClusterRole 和 RoleBinding/ClusterRoleBinding,遵循最小权限原则。
- **Network Policy**: 控制 Pod 间的流量出入,实施微服务间的安全隔离。
## 常用命令/模板
### 故障排查组合拳
```bash
# 查看所有 Namespace 下异常的 Pod
kubectl get pods -A --field-selector=status.phase!=Running
# 追踪实时日志并显示时间戳
kubectl logs -f <pod-name> --timestamps
# 查看资源占用排行
kubectl top nodes
kubectl top pods
# 导出资源定义的干净版本(去除 runtime 信息)
kubectl get deployment <name> -o yaml | kubectl-neat > deployment.yaml
```
### Deployment 模板 (Best Practice)
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: main
image: my-app:v1.2.3
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "500m"
memory: "512Mi"
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 15
periodSeconds: 20
readinessProbe:
httpGet:
path: /readyz
port: 8080
```
### HPA 配置示例
```yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: my-app-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: my-app
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
```
## 边界与限制
- **有状态应用**: 对于复杂的有状态应用(如数据库),优先考虑使用 Operator 而非简单的 StatefulSet。
- **本地存储**: 避免在 Pod 中使用 HostPath 存储持久数据,除非是特定的系统级组件。
- **配置更新**: 修改 ConfigMap 不会自动触发 Deployment 重启,除非在 Annotation 中加入了 ConfigMap 的 Hash 或使用 Reloader 等工具。
- **安全边界**: Kubernetes 容器不是强隔离边界,对于极高安全性要求的场景(如运行不受信任的代码),应考虑 Kata Containers 或 gVisor。
- **监控缺失**: 如果没有 Prometheus/Grafana 等监控系统,Kubernetes 的自动扩缩容和自愈能力将大打折扣。
Attribution
Comments
Loading comments…