Install
Terminal · npx$
npx skills add https://github.com/jeffallan/claude-skills --skill kubernetes-specialistWorks with Paperclip
How Kubernetes Specialist fits into a Paperclip company.
Kubernetes Specialist drops into any Paperclip agent that handles this kind of work. Assign it to a specialist inside a pre-configured PaperclipOrg company and the skill becomes available on every heartbeat — no prompt engineering, no tool wiring.
S
SaaS FactoryPaired
Pre-configured AI company — 18 agents, 18 skills, one-time purchase.
$27$59
Explore packSource file
SKILL.md241 linesExpandCollapse
---name: kubernetes-specialistdescription: 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.license: MITmetadata: author: https://github.com/Jeffallan version: "1.1.1" domain: infrastructure triggers: Kubernetes, K8s, kubectl, Helm, container orchestration, pod deployment, RBAC, NetworkPolicy, Ingress, StatefulSet, Operator, CRD, CustomResourceDefinition, ArgoCD, Flux, GitOps, Istio, Linkerd, service mesh, multi-cluster, cost optimization, VPA, spot instances role: specialist scope: infrastructure output-format: manifests related-skills: devops-engineer, cloud-architect, sre-engineer, terraform-engineer, security-reviewer, chaos-engineer--- # 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 requirements2. **Design architecture** — Choose workload types, networking patterns, storage solutions3. **Implement manifests** — Create declarative YAML with proper resource limits, health checks4. **Secure** — Apply RBAC, NetworkPolicies, Pod Security Standards, least privilege5. **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 ```yamlapiVersion: apps/v1kind: Deploymentmetadata: 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) ```yamlapiVersion: v1kind: ServiceAccountmetadata: name: my-app-sa namespace: my-namespace---apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: name: my-app-role namespace: my-namespacerules: - apiGroups: [""] resources: ["configmaps"] verbs: ["get", "list"] # grant only what is needed---apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata: name: my-app-rolebinding namespace: my-namespacesubjects: - kind: ServiceAccount name: my-app-sa namespace: my-namespaceroleRef: kind: Role name: my-app-role apiGroup: rbac.authorization.k8s.io``` ### NetworkPolicy (default-deny + explicit allow) ```yaml# Deny all ingress and egress by defaultapiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: default-deny-all namespace: my-namespacespec: podSelector: {} policyTypes: ["Ingress", "Egress"]---# Allow only specific trafficapiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: allow-my-app namespace: my-namespacespec: 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: ```bash# Watch rollout completekubectl rollout status deployment/my-app -n my-namespace # Stream pod events to catch crash loops or image pull errorskubectl get pods -n my-namespace -w # Inspect a specific pod for failureskubectl describe pod <pod-name> -n my-namespace # Check container logskubectl logs <pod-name> -n my-namespace --previous # use --previous for crashed containers # Verify resource usage vs. limitskubectl top pods -n my-namespace # Audit RBAC permissions for a service accountkubectl auth can-i --list --as=system:serviceaccount:my-namespace:my-app-sa # Roll back a failed deploymentkubectl rollout undo deployment/my-app -n my-namespace``` ## Output Templates When implementing Kubernetes resources, provide:1. Complete YAML manifests with proper structure2. RBAC configuration if needed (ServiceAccount, Role, RoleBinding)3. NetworkPolicy for network isolation4. Brief explanation of design decisions and security considerations