2026/9/16 15:05:39
FEATURED · 精选文章 
Kubernetes Specialist 技能详解用 Claude Code 完成从 Deployment 清单到多集群治理的容器编排实战【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills本指南以开源仓库 claude-skills 中的kubernetes-specialist技能为核心系统讲解如何借助 Claude Code 完成 Kubernetes 工作负载部署、网络策略与安全加固、Helm 打包、故障排查、GitOps、成本优化乃至多集群管理的完整实践。读完你将掌握一套可直接落地的声明式 YAML 模板、kubectl 验证命令体系和纵深安全约束并理解该技能背后的参考文档组织方式与源码级实现逻辑。Skill 定位一个基础设施专家角色如何被触发kubernetes-specialist是 claude-skills 仓库自称 67 个面向全栈开发者的专业技能之一中典型的role: specialist、scope: infrastructure类技能定义见 skills/kubernetes-specialist/SKILL.md 的 frontmatter元数据字段值含义domaininfrastructure归属基础设施领域rolespecialist以专家角色提供纵深能力scopeinfrastructure作用域限定在基础设施output-formatmanifests输出以清单YAML为主version1.1.1技能版本遵循语义化版本管理licenseMIT开源许可related-skillsdevops-engineer, cloud-architect, sre-engineer, terraform-engineer, security-reviewer, chaos-engineer可协同的相邻技能frontmatter 中的description与triggers字段决定了 Agent 何时激活本技能当用户请求涉及 Kubernetes、K8s、kubectl、Helm、容器编排、pod 部署、RBAC、NetworkPolicy、Ingress、StatefulSet、Operator、CRD、ArgoCD、Flux、GitOps、Istio、Linkerd、service mesh、多集群、成本优化、VPA、spot 实例等关键词时该技能即被调用用于创建部署清单、配置 Pod 安全策略、设置 ServiceAccount、定义网络隔离规则、调试 Pod 崩溃、分析资源限制、检视容器日志以及为工作负载right-size合理配比资源。何时使用该技能根据 SKILL.md 的 When to Use This Skill 章节该技能覆盖以下典型场景部署工作负载Deployment、StatefulSet、DaemonSet、Jobs配置网络Service、Ingress、NetworkPolicy管理配置ConfigMap、Secret、环境变量搭建持久化存储PV、PVC、StorageClass创建 Helm Chart 进行应用打包排查集群与工作负载问题落实安全最佳实践。核心工作流五步闭环SKILL.md 给出了一条从需求到验证的完整工作流分析需求Analyze requirements——理解工作负载特征、扩展需求与安全需求设计架构Design architecture——选择工作负载类型、网络模式与存储方案实现清单Implement manifests——编写声明式 YAML配齐资源限制resource limits与健康检查health checks安全加固Secure——应用 RBAC、NetworkPolicy、Pod Security StandardsPod 安全标准贯彻最小权限验证Validate——依次执行kubectl rollout status、kubectl get pods -w、kubectl describe pod name确认健康状态必要时用kubectl rollout undo回滚。该技能强调声明式优先始终以 YAML 清单描述期望状态而非依赖命令式 kubectl 指令逐条操作。参考资料矩阵按需加载的知识库SKILL.md 的 Reference Guide 将知识拆分为 11 个主题文件Agent 依据上下文按需加载下表链接已转换为仓库根目录相对路径主题参考文档何时加载工作负载references/workloads.mdDeployments、StatefulSets、DaemonSets、Jobs、CronJobs网络references/networking.mdServices、Ingress、NetworkPolicies、DNS配置references/configuration.mdConfigMaps、Secrets、环境变量存储references/storage.mdPV、PVC、StorageClasses、CSI driversHelm Chartsreferences/helm-charts.mdChart 结构、values、模板、hooks、测试、仓库故障排查references/troubleshooting.mdkubectl debug、日志、事件、常见问题自定义 Operatorreferences/custom-operators.mdCRD、Operator SDK、controller-runtime、reconciliationService Meshreferences/service-mesh.mdIstio、Linkerd、流量管理、mTLS、金丝雀发布GitOpsreferences/gitops.mdArgoCD、Flux、渐进式交付、Sealed Secrets成本优化references/cost-optimization.mdVPA、HPA 调优、spot 实例、配额、right-sizing多集群references/multi-cluster.mdCluster API、联邦、跨集群网络、容灾这种主文件 按需加载参考文件的组织方式是 claude-skills 仓库所有技能的统一模式让 Agent 在保持主提示词精炼的同时能够在具体问题上获取足够深度的领域知识。强制约束MUST DO 与 MUST NOT DOSKILL.md 的 Constraints 章节定义了产出清单时必须遵守的红线这是该技能安全性的核心体现。MUST DO必须做到使用声明式 YAML 清单避免命令式 kubectl 命令为所有容器设置资源 requests 和 limits配置 liveness 与 readiness 探针敏感数据一律使用 Secret绝不硬编码凭据应用最小权限的 RBAC用 NetworkPolicy 实现网络分段使用 namespace 进行逻辑隔离用一致的标签组织资源在 annotations 中记录配置决策。MUST NOT DO严禁触碰无资源限制即部署到生产环境把 Secret 放进 ConfigMap 或以明文环境变量存储应用 Pod 使用默认 ServiceAccount允许不受限制的网络访问默认 allow-all无正当理由以 root 运行容器跳过健康检查liveness/readiness 探针生产镜像使用latest标签暴露不必要的端口或服务。这些约束会直接体现在下文的三份核心 YAML 模式中与参考文档 references/configuration.md、references/networking.md 中的最佳实践清单一一对应。核心 YAML 模式可直接复制使用的生产级模板SKILL.md 提供了三份开箱即用的清单模板完整继承如下。1. 带资源限制、探针与安全上下文的 DeploymentapiVersion: apps/v1 kind: Deployment metadata: name: my-app namespace: my-namespace labels: app: my-app version: 1.2.3 spec: replicas: 3 selector: matchLabels: app: my-app template: metadata: labels: app: my-app version: 1.2.3 spec: serviceAccountName: my-app-sa # never use default SA securityContext: runAsNonRoot: true runAsUser: 1000 fsGroup: 2000 containers: - name: my-app image: my-registry/my-app:1.2.3 # never use latest ports: - containerPort: 8080 resources: requests: cpu: 100m memory: 128Mi limits: cpu: 500m memory: 512Mi livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 15 periodSeconds: 20 readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 5 periodSeconds: 10 securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true capabilities: drop: [ALL] envFrom: - secretRef: name: my-app-secret # pull credentials from Secret, not ConfigMap要点注释serviceAccountName指向专门创建的 SA 而非默认runAsNonRoot: true配合指定 UID 运行allowPrivilegeEscalation: false、只读根文件系统并drop: [ALL]是所有 Capabilities从源头封堵提权路径镜像标签使用固定版本号。2. 最小权限 RBACapiVersion: v1 kind: ServiceAccount metadata: name: my-app-sa namespace: my-namespace --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: my-app-role namespace: my-namespace rules: - apiGroups: [] resources: [configmaps] verbs: [get, list] # grant only what is needed --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: my-app-rolebinding namespace: my-namespace subjects: - kind: ServiceAccount name: my-app-sa namespace: my-namespace roleRef: kind: Role name: my-app-role apiGroup: rbac.authorization.k8s.io此处使用命名空间级Role而非集群级ClusterRole且 verbs 精确到实际所需操作只读get/list是最小权限的直观示范。3. 默认拒绝 显式放行的 NetworkPolicy# Deny all ingress and egress by default apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all namespace: my-namespace spec: podSelector: {} policyTypes: [Ingress, Egress] --- # Allow only specific traffic apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-my-app namespace: my-namespace spec: podSelector: matchLabels: app: my-app policyTypes: [Ingress] ingress: - from: - podSelector: matchLabels: app: frontend ports: - protocol: TCP port: 8080第一份策略以空podSelector匹配命名空间内所有 Pod 并同时声明 Ingress/Egress 两个维度形成默认拒绝基底第二份策略再按标签显式放行来自frontend的 8080 端口流量。这一先关后开模式在 references/networking.md 中被进一步扩展为面向数据库、DNS 与跨命名空间监控的多策略组合。部署后的验证命令清单SKILL.md 的 Validation Commands 章节提供了一套部署后体检命令用于确认健康与安全态势# Watch rollout complete kubectl rollout status deployment/my-app -n my-namespace # Stream pod events to catch crash loops or image pull errors kubectl get pods -n my-namespace -w # Inspect a specific pod for failures kubectl describe pod pod-name -n my-namespace # Check container logs kubectl logs pod-name -n my-namespace --previous # use --previous for crashed containers # Verify resource usage vs. limits kubectl top pods -n my-namespace # Audit RBAC permissions for a service account kubectl auth can-i --list --assystem:serviceaccount:my-namespace:my-app-sa # Roll back a failed deployment kubectl rollout undo deployment/my-app -n my-namespace其中kubectl logs --previous用于读取崩溃前容器crash loop的日志kubectl auth can-i --list用于审计指定 SA 的实际权限面这两条命令在排查崩溃循环与权限越界问题时会成为关键工具。输出模板交付物约定SKILL.md 规定实现 Kubernetes 资源时Agent 必须交付四类产物结构完整的 YAML 清单需要时的 RBAC 配置ServiceAccount、Role、RoleBinding用于网络隔离的 NetworkPolicy设计决策与安全考量的一小段说明。也就是说最终交付不只是一堆 YAML而是清单 权限 网络隔离 设计说明的组合。纵深专题一工作负载模式references/workloads.md 为每种工作负载类型提供了完整清单模板。Deployment滚动更新与配置注入生产级 Deployment 常搭配strategy.type: RollingUpdate、maxSurge/maxUnavailable控制滚动节奏通过configMapKeyRef/secretKeyRef注入配置并通过prometheus.io/scrape: true注解暴露指标端点。revisionHistoryLimit控制保留的旧版本数量以支持回滚。StatefulSet有序部署 独立存储有状态应用如 PostgreSQL的关键点是serviceName指向 headless ServicevolumeClaimTemplates为每个副本生成独立 PVCpodManagementPolicy: OrderedReady保证按序启动。数据目录通过PGDATA指向挂载卷避免容器镜像层中的数据问题。DaemonSet每节点一个监控类组件如 node-exporter使用hostNetwork: true、hostPID: true访问宿主机配合tolerations容忍所有NoSchedule污点以覆盖全部节点maxUnavailable: 1控制逐节点滚动更新。Job 与 CronJob批处理与定时任务数据库迁移等一次性任务用backoffLimit控制重试ttlSecondsAfterFinished让完成的 Job 自动清理CronJob 使用标准 crontab 语法如0 2 * * *并支持timeZone、concurrencyPolicy: Forbid禁止并发、successfulJobsHistoryLimit/failedJobsHistoryLimit控制历史保留。Init Container前置依赖等待initContainers可在主容器启动前完成等待数据库就绪执行 schema 迁移等前置步骤参考文档给出until nc -z postgres-service 5432的轮询等待示例。纵深专题二网络配置与零信任references/networking.md 按Service 类型 → Ingress → NetworkPolicy → DNS → Service Mesh逐层展开。Service 四类型ClusterIP默认集群内虚拟 IP可配合sessionAffinity: ClientIP做会话保持HeadlessclusterIP: None直接暴露 Pod 的稳定 DNS 名供 StatefulSet 使用NodePort节点端口范围固定为 30000-32767LoadBalancer云厂商负载均衡器可用loadBalancerSourceRanges限制来源 IP。Ingress 路由NGINX Ingress 通过注解实现 rewrite、SSL 强制跳转、proxy-body-size、限流nginx.ingress.kubernetes.io/rate-limit并通过cert-manager.io/cluster-issuer注解自动化 TLS 证书签发支持按 host 与 path 的多服务路由。零信任 NetworkPolicy在默认拒绝基础上参考文档给出前端→后端后端→数据库允许 DNS 与外部 HTTPS跨命名空间监控四组典型策略展示了podSelector、namespaceSelector、多端口组合的精确表达能力。核心最佳实践是默认拒绝 → 显式放行 → 只开放必要端口。DNS同命名空间直接使用服务名web-app-service跨命名空间使用web-app-service.production.svc.cluster.localStatefulSet 则得到postgres-0.postgres-headless.database.svc.cluster.local这类稳定 FQDN必要时可用dnsPolicy: NonednsConfig定制解析行为如调整ndots。纵深专题三配置管理与密钥安全references/configuration.md 的核心准则是ConfigMap 管非敏感数据Secret 管凭据二者严格分离。ConfigMap 形态支持简单键值、多行属性文件app.properties: |、JSON 与 YAML 配置块四种形态也可以用kubectl create configmap ... --from-literal... / --from-file... / --from-file.../从字面量、单文件或整个目录生成。Secret 五种类型Opaque通用凭据stringData会由系统自动 base64 编码kubernetes.io/tlsTLS 证书与私钥kubernetes.io/dockerconfigjson镜像仓库登录凭据kubernetes.io/basic-authHTTP Basic 认证kubernetes.io/ssh-authSSH 私钥。注入方式与加固支持单值注入valueFrom.configMapKeyRef/secretKeyRef、整体注入envFromprefix前缀、以卷方式挂载Secret 卷建议defaultMode: 0400仅所有者可读并可用items指定挂载为特定路径。生产环境可将 ConfigMap/Secret 标记immutable: true防止误改云端密钥可用 External Secrets Operator 的ExternalSecretSecretStore从 AWS Secrets Manager 等同步GitOps 场景可用 SealedSecret 加密入库。纵深专题四持久化存储references/storage.md 覆盖从 StorageClass 到卷快照的完整链路。StorageClassAWS EBSebs.csi.aws.comgp3 指定 IOPS/吞吐、GCE PDpd.csi.storage.gke.io、Azure Diskdisk.csi.azure.com、NFS 等关键参数volumeBindingMode: WaitForFirstConsumer延迟绑定以感知节点、allowVolumeExpansion: true支持扩容、reclaimPolicy: Delete临时数据回收。PV/PVC静态供给的 PV 需要手工声明容量、访问模式与节点亲和动态供给只需 PVC 指定storageClassName与容量请求。访问模式ReadWriteOnce单节点读写用于数据库ReadWriteMany多节点共享用于共享资产volumeMode: Block提供块设备。StatefulSet 集成volumeClaimTemplates让每个副本获得独立持久卷。卷快照VolumeSnapshotClassVolumeSnapshot做即时备份新 PVC 通过dataSource指向快照完成恢复。CSI 驱动AWS EBS CSI、Secrets Store CSI将云密钥库挂载为文件等直接以csi卷方式使用。emptyDir支持medium: Memory内存盘与sizeLimit容量上限适合缓存与 scratch 空间。纵深专题五Helm 应用打包references/helm-charts.md 是最厚的一份参考文档构成完整的 Chart 开发教程。标准目录结构Chart.yaml元数据values.yaml默认值values.schema.jsonJSON Schema 校验templates/含NOTES.txt、_helpers.tpl、各资源模板与tests/test-connection.yamlcharts/依赖.helmignoreREADME.md。模板最佳实践_helpers.tpl定义myapp.name/myapp.fullname/myapp.labels/myapp.serviceAccountName等可复用模板Deployment 模板中通过{{ include myapp.labels . | nindent 4 }}统一注入标准标签通过checksum/config注解在 ConfigMap 变更时自动触发 Pod 滚动更新HPA 模板用{{- if .Values.autoscaling.enabled }}条件渲染。Hooks、测试与验证pre-install,pre-upgrade钩子挂载数据库迁移 Jobtest钩子挂载连接性校验 Pod。Helm 命令链helm lint→helm template预渲染 →helm install/upgrade带--atomic --wait配合helm rollback形成可回滚的发布闭环helm-unittest插件支持对模板输出做断言式单元测试values.schema.json用 JSON Schema 约束 values 的取值边界。仓库与发布支持helm repo index生成索引、GitHub Pages 托管、OCI Registryhelm push oci://...插件生态包括helm-diff升级前预览差异、helm-secrets加密密钥、helm-git、helm-s3库型 Charttype: library用于跨应用复用共享模板。纵深专题六故障排查方法论references/troubleshooting.md 给出了一套命令 → 常见问题 → 诊断工具的完整排查体系。排查命令层次Pod 层kubectl get pods -o wide→kubectl describe pod看 Events→kubectl logs带--previous读崩溃前日志→kubectl exec→kubectl cp→kubectl port-forward工作负载层kubectl rollout status/history/undo、kubectl get rs检查 ReplicaSet 状态网络层检查 Service Endpoints、Ingress、NetworkPolicy确认 Pod 标签与 Service selector 是否匹配配置与存储层kubectl get secret ... -o jsonpath{.data.password} | base64 -d解码校验、kubectl get pvc/kubectl get pv检查绑定状态。高频问题速查问题首要检查手段典型原因Pod Pendingkubectl describe podkubectl top nodes资源不足、PVC 未绑定、ImagePullBackOff、nodeSelector 不匹配CrashLoopBackOffkubectl logs --previous应用崩溃、liveness 探针失败、资源超限被杀ImagePullBackOff检查 imagePullSecret仓库凭据缺失或镜像不存在Service 不可达kubectl get endpoints--show-labels标签选择器不匹配DNS 解析失败CoreDNS 日志 nslookupCoreDNS 故障或 dnsPolicy 配置问题NetworkPolicy 拦截临时删除全部 NetworkPolicy 对照测试策略过严Debug 与退出码速查kubectl debug支持以临时调试容器附加到运行中 Pod--imagebusybox --targetcontainer、复制 Pod 加调试工具--copy-to、甚至创建特权 Pod 进入节点kubectl debug node/node-01。Pod 状态包括 Pending、ContainerCreating、Running、Succeeded、Failed、CrashLoopBackOff、ImagePullBackOff、ErrImagePull、Unknown容器退出码中137 SIGKILL通常是 OOMKilled 内存超限、139 SIGSEGV、143 SIGTERM 优雅终止这些速查信息能快速定位根因。纵深专题七自定义 Operator 开发references/custom-operators.md 展示了用 CRD controller-runtime 构建自定义控制器的完整路径先定义CustomResourceDefinition含 OpenAPI v3 schema 校验、subresourcesstatus/scale、additionalPrinterColumns让kubectl get直接显示关键列再写 Go 类型定义与Reconcile方法。调谐逻辑的核心要点包括finalizer 清理外部资源、ownerReferences 建立资源归属、幂等调谐同输入同输出、通过 status 子资源分离期望状态与观测状态、设置调谐重试RequeueAfter。开发命令链为operator-sdk init→operator-sdk create api→make manifests→make docker-build docker-push→make deploy。纵深专题八Service Mesh 流量治理references/service-mesh.md 对比了 Istio 与 Linkerd 两条技术路线维度IstioLinkerdSidecarEnvoylinkerd2-proxyRust资源占用较高较低功能丰富度更全面聚焦、更简单流量管理高级权重、镜像、故障注入基础基于 SMI多集群原生支持需额外配置学习曲线较陡平缓Istio 侧重点包括VirtualService做基于 header/URI 的路由、金丝雀 90/10 权重、超时与重试retryOn: connect-failure,refused-stream,503DestinationRule配连接池、负载均衡算法LEAST_REQUEST与熔断outlierDetection 连续 5xx 剔除PeerAuthentication实现 STRICT mTLSAuthorizationPolicy基于 ServiceAccount principal 做零信任授权VirtualService的fault字段可注入延迟与错误用于混沌测试流量镜像mirror可将真实流量复制到新版本验证。Linkerd 则以linkerd inject、ServiceProfile和TrafficSplit900m/100m 权重实现路由级可观测与金丝雀。纵深专题九GitOps 与渐进式交付references/gitops.md 以四条原则开篇声明式Declarative、版本化不可变Versioned and immutable、自动拉取Pulled automatically、持续调谐Continuously reconciled。ArgoCDApplication声明源码仓库与目标集群syncPolicy.automated开启prune清理漂移资源与selfHeal自动纠偏ApplicationSet通过 list/cluster 生成器一键多环境、多集群发布AppProject划定 sourceRepos、destinations 与资源黑白名单实现多租户隔离。FluxGitRepositoryKustomization构成核心调谐对postBuild.substitute支持变量替换HelmRepositoryHelmRelease管理 Helm 依赖ImageUpdateAutomation监测镜像仓库新 tag 并自动提交 Git实现镜像自动升级。渐进式交付Flagger 的Canary资源配合 Istio Gateway 按stepWeight逐步放量以请求成功率≥99%与延迟指标自动判定是否继续或回滚。密钥入库Sealed Secretskubeseal离线加密与 SOPS Agecreation_rules按路径匹配加密data|stringData两条路线解决Git 仓库不能明文存密钥的难题。ArgoCD vs FluxArgoCD 内置 Web UI 与 AppProject 多租户、集中式架构Flux 走命名空间资源与分布式架构、原生镜像自动化。纵深专题十成本优化references/cost-optimization.md 提供了一套从度量 → 调整 → 治理的成本工程方法Right-sizing用kubectl top pods观察实际用量requests 设为均值 10-20% 缓冲CPU limits 设为 requests 的 2-4 倍以允许突发内存 limits 设为 1.5-2 倍防 OOMVPAupdateMode: Auto/Initial/Off三种模式——先以Off只出推荐值确认后再启用自动调整HPA 调优CPU/内存利用率 自定义指标如http_requests_per_second多指标混合behavior中通过stabilizationWindowSeconds与策略避免抖动thrashingscaleDown 保守每 60 秒最多缩减 10%、scaleUp 激进Spot 实例专用节点池 taint工作负载用tolerations 优选型nodeAffinity调度配合PodDisruptionBudget如minAvailable: 2保障可用性配额治理ResourceQuota限定命名空间总 CPU/内存/PVC/对象数量LimitRange为未显式声明资源的容器注入默认值与上下界时间维度CronJob 在非工作时间将开发环境缩容为 0如周一至周五 20:00 缩、8:00 扩优先级PriorityClassvalue: 1000000高优先级 vsvalue: 100可抢占低优先级保证关键负载不被驱逐监控Kubecost 提供成本分摊视角配合cost-center/team/environment标签做成本归因。纵深专题十一多集群管理与容灾references/multi-cluster.md 覆盖集群生命周期、跨集群网络与容灾Cluster API以ClusterKubeadmControlPlaneMachineDeployment声明式定义控制面与工作节点用clusterctl init初始化 provider实现基础设施即代码式的集群生命周期管理跨集群网络Submariner 通过 broker 模式打通各集群 Pod 网络Cilium Cluster Mesh 可创建全局 Service注解service.cilium.io/global: true实现跨集群服务发现ExternalDNS 统一管理 DNS 记录工作负载分布Federation v2 的FederatedDeployment以placement指定目标集群、overrides按集群覆盖副本数ArgoCDApplicationSet的 cluster 生成器按集群标签批量发布容灾Velero 定时备份Schedule含快照与 30 天 TTL与Restore跨集群恢复Active-Passive 故障转移通过 ExternalDNS 的aws-weight注解在主备集群间切换流量权重100/0。结语从模板到工程实践kubernetes-specialist技能的真正价值不在于单条 YAML 或命令而在于它把安全约束 → 声明式清单 → 验证命令 → 纵深知识库组织成了一套可复用的专家工作流任何一次 Kubernetes 相关的请求都会得到一份配齐资源限制、探针、最小权限 RBAC 与网络隔离的完整交付并附带验证与回滚手段。建议使用者以 skills/kubernetes-specialist/SKILL.md 为操作骨架在遇到具体问题时按需翻阅 11 份参考文档即可在 Claude Code 中获得一名兼具实操能力与安全意识的 Kubernetes 专家协作者。所有技能文件含本技能与其他 60 余个技能均位于仓库 skills/ 目录可结合 SKILLS_GUIDE.md 了解技能的通用规范。【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Kubernetes Specialist 技能详解：用 Claude Code 完成从 Deployment 清单到多集群治理的容器编排实战
Kubernetes Specialist 技能详解用 Claude Code 完成从 Deployment 清单到多集群治理的容器编排实战【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills本指南以开源仓库 claude-skills 中的kubernetes-specialist技能为核心系统讲解如何借助 Claude Code 完成 Kubernetes 工作负载部署、网络策略与安全加固、Helm 打包、故障排查、GitOps、成本优化乃至多集群管理的完整实践。读完你将掌握一套可直接落地的声明式 YAML 模板、kubectl 验证命令体系和纵深安全约束并理解该技能背后的参考文档组织方式与源码级实现逻辑。Skill 定位一个基础设施专家角色如何被触发kubernetes-specialist是 claude-skills 仓库自称 67 个面向全栈开发者的专业技能之一中典型的role: specialist、scope: infrastructure类技能定义见 skills/kubernetes-specialist/SKILL.md 的 frontmatter元数据字段值含义domaininfrastructure归属基础设施领域rolespecialist以专家角色提供纵深能力scopeinfrastructure作用域限定在基础设施output-formatmanifests输出以清单YAML为主version1.1.1技能版本遵循语义化版本管理licenseMIT开源许可related-skillsdevops-engineer, cloud-architect, sre-engineer, terraform-engineer, security-reviewer, chaos-engineer可协同的相邻技能frontmatter 中的description与triggers字段决定了 Agent 何时激活本技能当用户请求涉及 Kubernetes、K8s、kubectl、Helm、容器编排、pod 部署、RBAC、NetworkPolicy、Ingress、StatefulSet、Operator、CRD、ArgoCD、Flux、GitOps、Istio、Linkerd、service mesh、多集群、成本优化、VPA、spot 实例等关键词时该技能即被调用用于创建部署清单、配置 Pod 安全策略、设置 ServiceAccount、定义网络隔离规则、调试 Pod 崩溃、分析资源限制、检视容器日志以及为工作负载right-size合理配比资源。何时使用该技能根据 SKILL.md 的 When to Use This Skill 章节该技能覆盖以下典型场景部署工作负载Deployment、StatefulSet、DaemonSet、Jobs配置网络Service、Ingress、NetworkPolicy管理配置ConfigMap、Secret、环境变量搭建持久化存储PV、PVC、StorageClass创建 Helm Chart 进行应用打包排查集群与工作负载问题落实安全最佳实践。核心工作流五步闭环SKILL.md 给出了一条从需求到验证的完整工作流分析需求Analyze requirements——理解工作负载特征、扩展需求与安全需求设计架构Design architecture——选择工作负载类型、网络模式与存储方案实现清单Implement manifests——编写声明式 YAML配齐资源限制resource limits与健康检查health checks安全加固Secure——应用 RBAC、NetworkPolicy、Pod Security StandardsPod 安全标准贯彻最小权限验证Validate——依次执行kubectl rollout status、kubectl get pods -w、kubectl describe pod name确认健康状态必要时用kubectl rollout undo回滚。该技能强调声明式优先始终以 YAML 清单描述期望状态而非依赖命令式 kubectl 指令逐条操作。参考资料矩阵按需加载的知识库SKILL.md 的 Reference Guide 将知识拆分为 11 个主题文件Agent 依据上下文按需加载下表链接已转换为仓库根目录相对路径主题参考文档何时加载工作负载references/workloads.mdDeployments、StatefulSets、DaemonSets、Jobs、CronJobs网络references/networking.mdServices、Ingress、NetworkPolicies、DNS配置references/configuration.mdConfigMaps、Secrets、环境变量存储references/storage.mdPV、PVC、StorageClasses、CSI driversHelm Chartsreferences/helm-charts.mdChart 结构、values、模板、hooks、测试、仓库故障排查references/troubleshooting.mdkubectl debug、日志、事件、常见问题自定义 Operatorreferences/custom-operators.mdCRD、Operator SDK、controller-runtime、reconciliationService Meshreferences/service-mesh.mdIstio、Linkerd、流量管理、mTLS、金丝雀发布GitOpsreferences/gitops.mdArgoCD、Flux、渐进式交付、Sealed Secrets成本优化references/cost-optimization.mdVPA、HPA 调优、spot 实例、配额、right-sizing多集群references/multi-cluster.mdCluster API、联邦、跨集群网络、容灾这种主文件 按需加载参考文件的组织方式是 claude-skills 仓库所有技能的统一模式让 Agent 在保持主提示词精炼的同时能够在具体问题上获取足够深度的领域知识。强制约束MUST DO 与 MUST NOT DOSKILL.md 的 Constraints 章节定义了产出清单时必须遵守的红线这是该技能安全性的核心体现。MUST DO必须做到使用声明式 YAML 清单避免命令式 kubectl 命令为所有容器设置资源 requests 和 limits配置 liveness 与 readiness 探针敏感数据一律使用 Secret绝不硬编码凭据应用最小权限的 RBAC用 NetworkPolicy 实现网络分段使用 namespace 进行逻辑隔离用一致的标签组织资源在 annotations 中记录配置决策。MUST NOT DO严禁触碰无资源限制即部署到生产环境把 Secret 放进 ConfigMap 或以明文环境变量存储应用 Pod 使用默认 ServiceAccount允许不受限制的网络访问默认 allow-all无正当理由以 root 运行容器跳过健康检查liveness/readiness 探针生产镜像使用latest标签暴露不必要的端口或服务。这些约束会直接体现在下文的三份核心 YAML 模式中与参考文档 references/configuration.md、references/networking.md 中的最佳实践清单一一对应。核心 YAML 模式可直接复制使用的生产级模板SKILL.md 提供了三份开箱即用的清单模板完整继承如下。1. 带资源限制、探针与安全上下文的 DeploymentapiVersion: apps/v1 kind: Deployment metadata: name: my-app namespace: my-namespace labels: app: my-app version: 1.2.3 spec: replicas: 3 selector: matchLabels: app: my-app template: metadata: labels: app: my-app version: 1.2.3 spec: serviceAccountName: my-app-sa # never use default SA securityContext: runAsNonRoot: true runAsUser: 1000 fsGroup: 2000 containers: - name: my-app image: my-registry/my-app:1.2.3 # never use latest ports: - containerPort: 8080 resources: requests: cpu: 100m memory: 128Mi limits: cpu: 500m memory: 512Mi livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 15 periodSeconds: 20 readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 5 periodSeconds: 10 securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true capabilities: drop: [ALL] envFrom: - secretRef: name: my-app-secret # pull credentials from Secret, not ConfigMap要点注释serviceAccountName指向专门创建的 SA 而非默认runAsNonRoot: true配合指定 UID 运行allowPrivilegeEscalation: false、只读根文件系统并drop: [ALL]是所有 Capabilities从源头封堵提权路径镜像标签使用固定版本号。2. 最小权限 RBACapiVersion: v1 kind: ServiceAccount metadata: name: my-app-sa namespace: my-namespace --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: my-app-role namespace: my-namespace rules: - apiGroups: [] resources: [configmaps] verbs: [get, list] # grant only what is needed --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: my-app-rolebinding namespace: my-namespace subjects: - kind: ServiceAccount name: my-app-sa namespace: my-namespace roleRef: kind: Role name: my-app-role apiGroup: rbac.authorization.k8s.io此处使用命名空间级Role而非集群级ClusterRole且 verbs 精确到实际所需操作只读get/list是最小权限的直观示范。3. 默认拒绝 显式放行的 NetworkPolicy# Deny all ingress and egress by default apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all namespace: my-namespace spec: podSelector: {} policyTypes: [Ingress, Egress] --- # Allow only specific traffic apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-my-app namespace: my-namespace spec: podSelector: matchLabels: app: my-app policyTypes: [Ingress] ingress: - from: - podSelector: matchLabels: app: frontend ports: - protocol: TCP port: 8080第一份策略以空podSelector匹配命名空间内所有 Pod 并同时声明 Ingress/Egress 两个维度形成默认拒绝基底第二份策略再按标签显式放行来自frontend的 8080 端口流量。这一先关后开模式在 references/networking.md 中被进一步扩展为面向数据库、DNS 与跨命名空间监控的多策略组合。部署后的验证命令清单SKILL.md 的 Validation Commands 章节提供了一套部署后体检命令用于确认健康与安全态势# Watch rollout complete kubectl rollout status deployment/my-app -n my-namespace # Stream pod events to catch crash loops or image pull errors kubectl get pods -n my-namespace -w # Inspect a specific pod for failures kubectl describe pod pod-name -n my-namespace # Check container logs kubectl logs pod-name -n my-namespace --previous # use --previous for crashed containers # Verify resource usage vs. limits kubectl top pods -n my-namespace # Audit RBAC permissions for a service account kubectl auth can-i --list --assystem:serviceaccount:my-namespace:my-app-sa # Roll back a failed deployment kubectl rollout undo deployment/my-app -n my-namespace其中kubectl logs --previous用于读取崩溃前容器crash loop的日志kubectl auth can-i --list用于审计指定 SA 的实际权限面这两条命令在排查崩溃循环与权限越界问题时会成为关键工具。输出模板交付物约定SKILL.md 规定实现 Kubernetes 资源时Agent 必须交付四类产物结构完整的 YAML 清单需要时的 RBAC 配置ServiceAccount、Role、RoleBinding用于网络隔离的 NetworkPolicy设计决策与安全考量的一小段说明。也就是说最终交付不只是一堆 YAML而是清单 权限 网络隔离 设计说明的组合。纵深专题一工作负载模式references/workloads.md 为每种工作负载类型提供了完整清单模板。Deployment滚动更新与配置注入生产级 Deployment 常搭配strategy.type: RollingUpdate、maxSurge/maxUnavailable控制滚动节奏通过configMapKeyRef/secretKeyRef注入配置并通过prometheus.io/scrape: true注解暴露指标端点。revisionHistoryLimit控制保留的旧版本数量以支持回滚。StatefulSet有序部署 独立存储有状态应用如 PostgreSQL的关键点是serviceName指向 headless ServicevolumeClaimTemplates为每个副本生成独立 PVCpodManagementPolicy: OrderedReady保证按序启动。数据目录通过PGDATA指向挂载卷避免容器镜像层中的数据问题。DaemonSet每节点一个监控类组件如 node-exporter使用hostNetwork: true、hostPID: true访问宿主机配合tolerations容忍所有NoSchedule污点以覆盖全部节点maxUnavailable: 1控制逐节点滚动更新。Job 与 CronJob批处理与定时任务数据库迁移等一次性任务用backoffLimit控制重试ttlSecondsAfterFinished让完成的 Job 自动清理CronJob 使用标准 crontab 语法如0 2 * * *并支持timeZone、concurrencyPolicy: Forbid禁止并发、successfulJobsHistoryLimit/failedJobsHistoryLimit控制历史保留。Init Container前置依赖等待initContainers可在主容器启动前完成等待数据库就绪执行 schema 迁移等前置步骤参考文档给出until nc -z postgres-service 5432的轮询等待示例。纵深专题二网络配置与零信任references/networking.md 按Service 类型 → Ingress → NetworkPolicy → DNS → Service Mesh逐层展开。Service 四类型ClusterIP默认集群内虚拟 IP可配合sessionAffinity: ClientIP做会话保持HeadlessclusterIP: None直接暴露 Pod 的稳定 DNS 名供 StatefulSet 使用NodePort节点端口范围固定为 30000-32767LoadBalancer云厂商负载均衡器可用loadBalancerSourceRanges限制来源 IP。Ingress 路由NGINX Ingress 通过注解实现 rewrite、SSL 强制跳转、proxy-body-size、限流nginx.ingress.kubernetes.io/rate-limit并通过cert-manager.io/cluster-issuer注解自动化 TLS 证书签发支持按 host 与 path 的多服务路由。零信任 NetworkPolicy在默认拒绝基础上参考文档给出前端→后端后端→数据库允许 DNS 与外部 HTTPS跨命名空间监控四组典型策略展示了podSelector、namespaceSelector、多端口组合的精确表达能力。核心最佳实践是默认拒绝 → 显式放行 → 只开放必要端口。DNS同命名空间直接使用服务名web-app-service跨命名空间使用web-app-service.production.svc.cluster.localStatefulSet 则得到postgres-0.postgres-headless.database.svc.cluster.local这类稳定 FQDN必要时可用dnsPolicy: NonednsConfig定制解析行为如调整ndots。纵深专题三配置管理与密钥安全references/configuration.md 的核心准则是ConfigMap 管非敏感数据Secret 管凭据二者严格分离。ConfigMap 形态支持简单键值、多行属性文件app.properties: |、JSON 与 YAML 配置块四种形态也可以用kubectl create configmap ... --from-literal... / --from-file... / --from-file.../从字面量、单文件或整个目录生成。Secret 五种类型Opaque通用凭据stringData会由系统自动 base64 编码kubernetes.io/tlsTLS 证书与私钥kubernetes.io/dockerconfigjson镜像仓库登录凭据kubernetes.io/basic-authHTTP Basic 认证kubernetes.io/ssh-authSSH 私钥。注入方式与加固支持单值注入valueFrom.configMapKeyRef/secretKeyRef、整体注入envFromprefix前缀、以卷方式挂载Secret 卷建议defaultMode: 0400仅所有者可读并可用items指定挂载为特定路径。生产环境可将 ConfigMap/Secret 标记immutable: true防止误改云端密钥可用 External Secrets Operator 的ExternalSecretSecretStore从 AWS Secrets Manager 等同步GitOps 场景可用 SealedSecret 加密入库。纵深专题四持久化存储references/storage.md 覆盖从 StorageClass 到卷快照的完整链路。StorageClassAWS EBSebs.csi.aws.comgp3 指定 IOPS/吞吐、GCE PDpd.csi.storage.gke.io、Azure Diskdisk.csi.azure.com、NFS 等关键参数volumeBindingMode: WaitForFirstConsumer延迟绑定以感知节点、allowVolumeExpansion: true支持扩容、reclaimPolicy: Delete临时数据回收。PV/PVC静态供给的 PV 需要手工声明容量、访问模式与节点亲和动态供给只需 PVC 指定storageClassName与容量请求。访问模式ReadWriteOnce单节点读写用于数据库ReadWriteMany多节点共享用于共享资产volumeMode: Block提供块设备。StatefulSet 集成volumeClaimTemplates让每个副本获得独立持久卷。卷快照VolumeSnapshotClassVolumeSnapshot做即时备份新 PVC 通过dataSource指向快照完成恢复。CSI 驱动AWS EBS CSI、Secrets Store CSI将云密钥库挂载为文件等直接以csi卷方式使用。emptyDir支持medium: Memory内存盘与sizeLimit容量上限适合缓存与 scratch 空间。纵深专题五Helm 应用打包references/helm-charts.md 是最厚的一份参考文档构成完整的 Chart 开发教程。标准目录结构Chart.yaml元数据values.yaml默认值values.schema.jsonJSON Schema 校验templates/含NOTES.txt、_helpers.tpl、各资源模板与tests/test-connection.yamlcharts/依赖.helmignoreREADME.md。模板最佳实践_helpers.tpl定义myapp.name/myapp.fullname/myapp.labels/myapp.serviceAccountName等可复用模板Deployment 模板中通过{{ include myapp.labels . | nindent 4 }}统一注入标准标签通过checksum/config注解在 ConfigMap 变更时自动触发 Pod 滚动更新HPA 模板用{{- if .Values.autoscaling.enabled }}条件渲染。Hooks、测试与验证pre-install,pre-upgrade钩子挂载数据库迁移 Jobtest钩子挂载连接性校验 Pod。Helm 命令链helm lint→helm template预渲染 →helm install/upgrade带--atomic --wait配合helm rollback形成可回滚的发布闭环helm-unittest插件支持对模板输出做断言式单元测试values.schema.json用 JSON Schema 约束 values 的取值边界。仓库与发布支持helm repo index生成索引、GitHub Pages 托管、OCI Registryhelm push oci://...插件生态包括helm-diff升级前预览差异、helm-secrets加密密钥、helm-git、helm-s3库型 Charttype: library用于跨应用复用共享模板。纵深专题六故障排查方法论references/troubleshooting.md 给出了一套命令 → 常见问题 → 诊断工具的完整排查体系。排查命令层次Pod 层kubectl get pods -o wide→kubectl describe pod看 Events→kubectl logs带--previous读崩溃前日志→kubectl exec→kubectl cp→kubectl port-forward工作负载层kubectl rollout status/history/undo、kubectl get rs检查 ReplicaSet 状态网络层检查 Service Endpoints、Ingress、NetworkPolicy确认 Pod 标签与 Service selector 是否匹配配置与存储层kubectl get secret ... -o jsonpath{.data.password} | base64 -d解码校验、kubectl get pvc/kubectl get pv检查绑定状态。高频问题速查问题首要检查手段典型原因Pod Pendingkubectl describe podkubectl top nodes资源不足、PVC 未绑定、ImagePullBackOff、nodeSelector 不匹配CrashLoopBackOffkubectl logs --previous应用崩溃、liveness 探针失败、资源超限被杀ImagePullBackOff检查 imagePullSecret仓库凭据缺失或镜像不存在Service 不可达kubectl get endpoints--show-labels标签选择器不匹配DNS 解析失败CoreDNS 日志 nslookupCoreDNS 故障或 dnsPolicy 配置问题NetworkPolicy 拦截临时删除全部 NetworkPolicy 对照测试策略过严Debug 与退出码速查kubectl debug支持以临时调试容器附加到运行中 Pod--imagebusybox --targetcontainer、复制 Pod 加调试工具--copy-to、甚至创建特权 Pod 进入节点kubectl debug node/node-01。Pod 状态包括 Pending、ContainerCreating、Running、Succeeded、Failed、CrashLoopBackOff、ImagePullBackOff、ErrImagePull、Unknown容器退出码中137 SIGKILL通常是 OOMKilled 内存超限、139 SIGSEGV、143 SIGTERM 优雅终止这些速查信息能快速定位根因。纵深专题七自定义 Operator 开发references/custom-operators.md 展示了用 CRD controller-runtime 构建自定义控制器的完整路径先定义CustomResourceDefinition含 OpenAPI v3 schema 校验、subresourcesstatus/scale、additionalPrinterColumns让kubectl get直接显示关键列再写 Go 类型定义与Reconcile方法。调谐逻辑的核心要点包括finalizer 清理外部资源、ownerReferences 建立资源归属、幂等调谐同输入同输出、通过 status 子资源分离期望状态与观测状态、设置调谐重试RequeueAfter。开发命令链为operator-sdk init→operator-sdk create api→make manifests→make docker-build docker-push→make deploy。纵深专题八Service Mesh 流量治理references/service-mesh.md 对比了 Istio 与 Linkerd 两条技术路线维度IstioLinkerdSidecarEnvoylinkerd2-proxyRust资源占用较高较低功能丰富度更全面聚焦、更简单流量管理高级权重、镜像、故障注入基础基于 SMI多集群原生支持需额外配置学习曲线较陡平缓Istio 侧重点包括VirtualService做基于 header/URI 的路由、金丝雀 90/10 权重、超时与重试retryOn: connect-failure,refused-stream,503DestinationRule配连接池、负载均衡算法LEAST_REQUEST与熔断outlierDetection 连续 5xx 剔除PeerAuthentication实现 STRICT mTLSAuthorizationPolicy基于 ServiceAccount principal 做零信任授权VirtualService的fault字段可注入延迟与错误用于混沌测试流量镜像mirror可将真实流量复制到新版本验证。Linkerd 则以linkerd inject、ServiceProfile和TrafficSplit900m/100m 权重实现路由级可观测与金丝雀。纵深专题九GitOps 与渐进式交付references/gitops.md 以四条原则开篇声明式Declarative、版本化不可变Versioned and immutable、自动拉取Pulled automatically、持续调谐Continuously reconciled。ArgoCDApplication声明源码仓库与目标集群syncPolicy.automated开启prune清理漂移资源与selfHeal自动纠偏ApplicationSet通过 list/cluster 生成器一键多环境、多集群发布AppProject划定 sourceRepos、destinations 与资源黑白名单实现多租户隔离。FluxGitRepositoryKustomization构成核心调谐对postBuild.substitute支持变量替换HelmRepositoryHelmRelease管理 Helm 依赖ImageUpdateAutomation监测镜像仓库新 tag 并自动提交 Git实现镜像自动升级。渐进式交付Flagger 的Canary资源配合 Istio Gateway 按stepWeight逐步放量以请求成功率≥99%与延迟指标自动判定是否继续或回滚。密钥入库Sealed Secretskubeseal离线加密与 SOPS Agecreation_rules按路径匹配加密data|stringData两条路线解决Git 仓库不能明文存密钥的难题。ArgoCD vs FluxArgoCD 内置 Web UI 与 AppProject 多租户、集中式架构Flux 走命名空间资源与分布式架构、原生镜像自动化。纵深专题十成本优化references/cost-optimization.md 提供了一套从度量 → 调整 → 治理的成本工程方法Right-sizing用kubectl top pods观察实际用量requests 设为均值 10-20% 缓冲CPU limits 设为 requests 的 2-4 倍以允许突发内存 limits 设为 1.5-2 倍防 OOMVPAupdateMode: Auto/Initial/Off三种模式——先以Off只出推荐值确认后再启用自动调整HPA 调优CPU/内存利用率 自定义指标如http_requests_per_second多指标混合behavior中通过stabilizationWindowSeconds与策略避免抖动thrashingscaleDown 保守每 60 秒最多缩减 10%、scaleUp 激进Spot 实例专用节点池 taint工作负载用tolerations 优选型nodeAffinity调度配合PodDisruptionBudget如minAvailable: 2保障可用性配额治理ResourceQuota限定命名空间总 CPU/内存/PVC/对象数量LimitRange为未显式声明资源的容器注入默认值与上下界时间维度CronJob 在非工作时间将开发环境缩容为 0如周一至周五 20:00 缩、8:00 扩优先级PriorityClassvalue: 1000000高优先级 vsvalue: 100可抢占低优先级保证关键负载不被驱逐监控Kubecost 提供成本分摊视角配合cost-center/team/environment标签做成本归因。纵深专题十一多集群管理与容灾references/multi-cluster.md 覆盖集群生命周期、跨集群网络与容灾Cluster API以ClusterKubeadmControlPlaneMachineDeployment声明式定义控制面与工作节点用clusterctl init初始化 provider实现基础设施即代码式的集群生命周期管理跨集群网络Submariner 通过 broker 模式打通各集群 Pod 网络Cilium Cluster Mesh 可创建全局 Service注解service.cilium.io/global: true实现跨集群服务发现ExternalDNS 统一管理 DNS 记录工作负载分布Federation v2 的FederatedDeployment以placement指定目标集群、overrides按集群覆盖副本数ArgoCDApplicationSet的 cluster 生成器按集群标签批量发布容灾Velero 定时备份Schedule含快照与 30 天 TTL与Restore跨集群恢复Active-Passive 故障转移通过 ExternalDNS 的aws-weight注解在主备集群间切换流量权重100/0。结语从模板到工程实践kubernetes-specialist技能的真正价值不在于单条 YAML 或命令而在于它把安全约束 → 声明式清单 → 验证命令 → 纵深知识库组织成了一套可复用的专家工作流任何一次 Kubernetes 相关的请求都会得到一份配齐资源限制、探针、最小权限 RBAC 与网络隔离的完整交付并附带验证与回滚手段。建议使用者以 skills/kubernetes-specialist/SKILL.md 为操作骨架在遇到具体问题时按需翻阅 11 份参考文档即可在 Claude Code 中获得一名兼具实操能力与安全意识的 Kubernetes 专家协作者。所有技能文件含本技能与其他 60 余个技能均位于仓库 skills/ 目录可结合 SKILLS_GUIDE.md 了解技能的通用规范。【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
