‹ 首页

kubernetes-specialist

@jeffallan · 收录于 1 周前 · 上游提交 1 个月前

Use when deploying or managing Kubernetes workloads. Invoke to create deployment manifests, configure pod security policies, set up service accounts, define network isolation rules, debug pod crashes, analyze resource limits, inspect container logs, or right-size workloads. Use for Helm charts, RBAC policies, NetworkPolicies, storage configuration, performance optimization, GitOps pipelines, and multi-cluster management.

适合你,如果你需要管理 Kubernetes 集群或部署容器化应用。

/ 下载安装
kubernetes-specialist.skill双击,或拖进 Claude 桌面版 / Cowork,即完成安装↓ .skill↓ .zip
用别的 agent?下载 .zip 解压,把文件夹放进它的技能目录
Claude Code~/.claude/skills/(项目级 .claude/skills/)
Codex CLI~/.codex/skills/
Cursor自动读取上面两处目录
其他工具见其文档的「skills」目录;两个下载是同一份文件,只是名字不同
/ 通过 npx 安装 校验哈希
npx oh-my-skill add jeffallan/claude-skills/kubernetes-specialist
/ 通过 bash 安装
curl -fsSL https://oh-my-skill.com/install.sh | bash -s -- jeffallan/claude-skills/kubernetes-specialist
/ 已经装过?验证本机副本,不用重装
npx oh-my-skill verify jeffallan/claude-skills/kubernetes-specialist
安装目标可用 --agent / --scope 或 --to 明确指定;省略时只会在唯一已存在的 agent 目录上自动选择,零命中或多命中会停止并提示。content_hash 缺失或不一致均拒装。
10501GitHub stars
~1.4K最小装载
~22.5K含声明引用
~22.5K文本包总量
镜像托管

怎么用

商店整理自技能原文 · 版本 e8be415 · 表述以原文为准
它做什么

安装后,Claude 能生成 Kubernetes 部署清单(YAML 文件),配置网络策略、RBAC 权限、存储等,并帮助排查 Pod 崩溃、资源限制等问题。

什么时候触发

当你提到 Kubernetes、K8s、kubectl、Helm 等关键词,或要求部署工作负载、配置网络、管理配置、设置存储、排查集群问题时触发。

装好后可以这样说
技能原文 SKILL.md作者撰写 · MIT · e8be415

Kubernetes Specialist

When to Use This Skill
  • Deploying workloads (Deployments, StatefulSets, DaemonSets, Jobs)
  • Configuring networking (Services, Ingress, NetworkPolicies)
  • Managing configuration (ConfigMaps, Secrets, environment variables)
  • Setting up persistent storage (PV, PVC, StorageClasses)
  • Creating Helm charts for application packaging
  • Troubleshooting cluster and workload issues
  • Implementing security best practices
Core Workflow
  1. Analyze requirements — Understand workload characteristics, scaling needs, security requirements
  2. Design architecture — Choose workload types, networking patterns, storage solutions
  3. Implement manifests — Create declarative YAML with proper resource limits, health checks
  4. Secure — Apply RBAC, NetworkPolicies, Pod Security Standards, least privilege
  5. Validate — Run kubectl rollout status, kubectl get pods -w, and kubectl describe pod <name> to confirm health; roll back with kubectl rollout undo if needed
Reference Guide

Load detailed guidance based on context:

| Topic | Reference | Load When | |-------|-----------|-----------| | Workloads | references/workloads.md | Deployments, StatefulSets, DaemonSets, Jobs, CronJobs | | Networking | references/networking.md | Services, Ingress, NetworkPolicies, DNS | | Configuration | references/configuration.md | ConfigMaps, Secrets, environment variables | | Storage | references/storage.md | PV, PVC, StorageClasses, CSI drivers | | Helm Charts | references/helm-charts.md | Chart structure, values, templates, hooks, testing, repositories | | Troubleshooting | references/troubleshooting.md | kubectl debug, logs, events, common issues | | Custom Operators | references/custom-operators.md | CRD, Operator SDK, controller-runtime, reconciliation | | Service Mesh | references/service-mesh.md | Istio, Linkerd, traffic management, mTLS, canary | | GitOps | references/gitops.md | ArgoCD, Flux, progressive delivery, sealed secrets | | Cost Optimization | references/cost-optimization.md | VPA, HPA tuning, spot instances, quotas, right-sizing | | Multi-Cluster | references/multi-cluster.md | Cluster API, federation, cross-cluster networking, DR |

Constraints
MUST DO
  • Use declarative YAML manifests (avoid imperative kubectl commands)
  • Set resource requests and limits on all containers
  • Include liveness and readiness probes
  • Use secrets for sensitive data (never hardcode credentials)
  • Apply least privilege RBAC permissions
  • Implement NetworkPolicies for network segmentation
  • Use namespaces for logical isolation
  • Label resources consistently for organization
  • Document configuration decisions in annotations
MUST NOT DO
  • Deploy to production without resource limits
  • Store secrets in ConfigMaps or as plain environment variables
  • Use default ServiceAccount for application pods
  • Allow unrestricted network access (default allow-all)
  • Run containers as root without justification
  • Skip health checks (liveness/readiness probes)
  • Use latest tag for production images
  • Expose unnecessary ports or services
Common YAML Patterns
Deployment with resource limits, probes, and security context
apiVersion: 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
Minimal RBAC (least privilege)
apiVersion: 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
NetworkPolicy (default-deny + explicit allow)
# 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
Validation Commands

After deploying, verify health and security posture:

# 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 --as=system:serviceaccount:my-namespace:my-app-sa

# Roll back a failed deployment
kubectl rollout undo deployment/my-app -n my-namespace
Output Templates

When implementing Kubernetes resources, provide:

  1. Complete YAML manifests with proper structure
  2. RBAC configuration if needed (ServiceAccount, Role, RoleBinding)
  3. NetworkPolicy for network isolation
  4. Brief explanation of design decisions and security considerations

Documentation

按 MIT 许可原样转载,未经改动 · 在 GitHub 查看 →

评论

登录即可评论;带「已验证安装」的,是发布者名下有本店的安装或持有记录。