Kubernetes 运维专家技能用于帮助用户在 Kubernetes 集群上部署、管理、调试和优化工作负载，主要围绕 kubectl、Helm 以及 Kubernetes 原生模式展开。
核心原则
在执行任何会修改资源的命令之前，始终先确认当前上下文（kubectl config current-context）。生产环境的变更应使用纳入版本控制的声明式 YAML 清单，而不是命令式的 kubectl 命令。遵循最小权限原则，使用 RBAC、网络策略和 Pod 安全标准。所有资源都应放入命名空间，避免部署到 default 命名空间。
调试工作流
检查 Pod 状态：kubectl get pods -n <ns>，关注 CrashLoopBackOff、Pending 或 ImagePullBackOff。查看 Pod 详情：kubectl describe pod <name> -n <ns>，检查 Events 中的调度失败、探针失败或 OOM 终止信息。读取日志：kubectl logs <pod> -n <ns> --previous 用于已崩溃容器，--follow 用于实时跟踪。进入 Pod：kubectl exec -it <pod> -n <ns> -- sh 进行交互式调试。检查资源：kubectl top pods -n <ns> 查看 CPU/内存使用与限制的对比。
部署模式
无状态工作负载使用 Deployment，数据库和有状态服务使用 StatefulSet。始终设置资源请求与限制，防止吵闹邻居问题。为每个容器配置 readinessProbe 和 livenessProbe，对启动较慢的应用使用 startup 探针。使用 PodDisruptionBudget 在节点维护期间保持可用性。优先使用 RollingUpdate 策略并设置 maxUnavailable: 0 以实现零停机部署。
网络与服务
内部服务使用 ClusterIP，外部流量使用 LoadBalancer 或 Ingress。使用 NetworkPolicy 按标签限制 Pod 之间的通信。DNS 排查可使用 kubectl run debug --rm -it --image=busybox -- nslookup service-name.namespace.svc.cluster.local。
应避免的陷阱
不要用 kubectl delete pod 作为 CrashLoopBackOff 的修复手段，应先调查根本原因。内存限制不要设置得过于接近请求值，突发流量会导致 OOM 终止。生产清单中避免使用 latest 标签，否则无法回滚。不要把密钥存放在 ConfigMap 中，应使用 Kubernetes Secrets 或外部密钥管理器。
适用场景与限制
该技能适用于 Kubernetes 集群的日常运维、故障排查、部署配置与网络调试等任务。资料未提供其具体安装方式、收费模式、支持平台或效果数据，这些信息暂未提供。