Manage Kubernetes clusters using kubectl — pods, deployments, services, namespaces, nodes, secrets, configmaps, and RBAC. Use this skill whenever the user mentions Kubernetes, K8s, kubectl, pods, deployments, services, namespaces, nodes, clusters, container orchestration, pod logs, pod debugging, scaling deployments, cluster health, node status, drain/cordon, rollouts, configmaps, secrets, RBAC, service accounts, ingress, or any request involving managing workloads on a Kubernetes cluster. Also use when the user pastes kubectl output and asks for help interpreting it, wants to troubleshoot a CrashLoopBackOff or ImagePullBackOff, needs to write or review K8s YAML manifests, or asks about resource quotas and limit ranges. Even if they don't say 'Kubernetes' explicitly but describe container orchestration tasks like 'scale this up', 'check why the pod is failing', or 'deploy this image', use this skill.
ranvirkardhanraj0 estrellas11 abr 2026
Ocupación
Categorías
Contenedores
Contenido de la habilidad
Manage Kubernetes clusters directly from the terminal using kubectl. This skill covers the full lifecycle of cluster operations: pod management, deployments, services, namespace isolation, node diagnostics, secrets/configmaps, and RBAC.
Prerequisites
Before running any commands, verify cluster access:
If the user hasn't specified a context or namespace, ask which cluster and namespace they want to target. Default to the current context if they say "just use whatever I'm connected to."
Show pods with useful context (status, restarts, age, node placement):
# All pods in a namespace with wide output
kubectl get pods -n <namespace> -o wide
# All pods across all namespaces
kubectl get pods --all-namespaces -o wide
# Filter by label
kubectl get pods -n <namespace> -l app=<label>
# Watch for changes in real-time
kubectl get pods -n <namespace> -w
Inspecting a Pod
When a user asks "why is my pod failing?" or "what's wrong with this pod?", follow this diagnostic sequence:
Get status overview: kubectl get pod <name> -n <ns> -o wide
Describe for events: kubectl describe pod <name> -n <ns> — look at the Events section at the bottom
When the user wants to deploy a pod from a YAML manifest:
# Apply a manifest
kubectl apply -f <manifest.yaml>
# Create from image directly (quick testing only)
kubectl run <name> --image=<image> -n <ns>
# Dry-run to validate before applying
kubectl apply -f <manifest.yaml> --dry-run=client
When generating YAML manifests, always include:
metadata.labels for identification
resources.requests and resources.limits for CPU/memory
securityContext.runAsNonRoot: true unless root is explicitly needed
restartPolicy appropriate to the workload
Deleting Pods
# Delete a single pod
kubectl delete pod <name> -n <ns>
# Delete pods by label
kubectl delete pods -l app=<label> -n <ns>
# Force delete a stuck pod (use with caution)
kubectl delete pod <name> -n <ns> --grace-period=0 --force
Always warn the user before force-deleting. Explain that force-delete skips graceful shutdown and the workload may not clean up properly.
# List deployments
kubectl get deployments -n <ns>
# Deployment details (includes replica sets and rollout history)
kubectl describe deployment <name> -n <ns>
# Scale replicas
kubectl scale deployment <name> --replicas=<N> -n <ns>
# Update image (triggers rolling update)
kubectl set image deployment/<name> <container>=<new-image> -n <ns>
# Check rollout status
kubectl rollout status deployment/<name> -n <ns>
# View rollout history
kubectl rollout history deployment/<name> -n <ns>
# Rollback to previous revision
kubectl rollout undo deployment/<name> -n <ns>
# Rollback to specific revision
kubectl rollout undo deployment/<name> --to-revision=<N> -n <ns>
# Restart all pods in a deployment (rolling restart)
kubectl rollout restart deployment/<name> -n <ns>
Services
# List services
kubectl get svc -n <ns>
# Service details (endpoints, ports)
kubectl describe svc <name> -n <ns>
# Expose a deployment as a service
kubectl expose deployment <name> --port=<port> --target-port=<target> --type=ClusterIP -n <ns>
# Delete a service
kubectl delete svc <name> -n <ns>
When the user asks to "expose" or "make accessible" a deployment, ask what type of service they need:
ClusterIP (default): internal-only, reachable within the cluster
NodePort: accessible on each node's IP at a static port
LoadBalancer: provisions an external load balancer (cloud environments)
Ingress
# List ingress resources
kubectl get ingress -n <ns>
# Describe ingress
kubectl describe ingress <name> -n <ns>
3. Cluster Health & Node Diagnostics
Cluster Overview
# Cluster info
kubectl cluster-info
# Component status (etcd, scheduler, controller-manager)
kubectl get componentstatuses
# API server health
kubectl get --raw='/healthz'
Node Management
# List nodes with status and resource info
kubectl get nodes -o wide
# Detailed node info (capacity, allocatable, conditions, taints)
kubectl describe node <name>
# Node resource usage (requires metrics-server)
kubectl top nodes
# Pod resource usage
kubectl top pods -n <ns>
Node Maintenance
When a user needs to take a node out of rotation for maintenance:
# 1. Cordon — mark node as unschedulable (no new pods)
kubectl cordon <node>
# 2. Drain — evict existing pods gracefully
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data
# 3. Perform maintenance...
# 4. Uncordon — mark node as schedulable again
kubectl uncordon <node>
Warn the user that drain will evict all non-DaemonSet pods. Pods managed by a Deployment/ReplicaSet will be rescheduled on other nodes; standalone pods will be deleted.
Troubleshooting Node Issues
Condition
Meaning
Action
Ready=False
Kubelet not reporting healthy
SSH into node, check kubelet logs: journalctl -u kubelet
MemoryPressure
Node running low on memory
Check top consumers with kubectl top pods, consider eviction or scaling
DiskPressure
Node disk space low
Clean up images: docker system prune / crictl rmi --prune