## Intro Kubernetes has become the de facto standard for container orchestration, but its power comes with complexity. For developers and operators, the daily reality is interacting with Pods - the smallest deployable units in a cluster. Whether you are debugging a failing application, scaling a workload, or simply checking the health of your services, knowing the right kubectl commands is essential. This guide focuses on the most useful Kubernetes Pod commands, explained with practical examples and safe implementation steps. We will cover how to list, inspect, create, update, and delete Pods, along with commands for logs, exec, port-forward, and troubleshooting. Each section includes concrete command snippets with expected output, so you can follow along in your own environment. We'll also discuss verification, failure modes, and recovery strategies to keep your operations smooth. By the end, you will have a practical cheat sheet to use daily, reducing guesswork and increasing confidence in managing Kubernetes workloads. ## Version and Environment Inventory Before running any commands, it's important to know what version of Kubernetes and kubectl you are using, as command output and features may vary. This section establishes a consistent baseline for the examples in this guide. Prerequisites: - A running Kubernetes cluster (local like minikube, kind, or a cloud-managed cluster) - kubectl installed and configured to communicate with the cluster - Basic understanding of Kubernetes concepts like Pods, Deployments, and namespaces Check kubectl version: kubectl version --short Expected output (example): Client Version: v1.27.3 Kustomize Version: v5.0.1 Server Version: v1.27.3 Note: Starting from Kubernetes 1.26, --short is deprecated; use kubectl version without flags for full output. Check cluster info: kubectl cluster-info Expected output: Kubernetes control plane is running at https://192.168.49.2:8443 CoreDNS is running at https://192.168.49.2:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy Check nodes: kubectl get nodes Expected output (example): NAME STATUS ROLES AGE VERSION minikube Ready control-plane 10d v1.27.3 Important: The examples in this guide use a minikube single-node cluster, but the commands are applicable to any Kubernetes cluster. The default namespace is used unless specified; we'll show how to work across namespaces as well.
Quick check 1 of 2 Which kubectl subcommand would you use to get detailed information about a resource, including events? - kubectl get - kubectl describe - kubectl logs - kubectl exec
According to the passage, 'kubectl get' lists resources, 'kubectl describe' shows detailed information about a resource, 'kubectl logs' prints logs from a container, and 'kubectl exec' executes a command on a container. The command for detailed information is 'kubectl describe'.
## Safe Configuration Path When managing Pods, it's crucial to follow safe practices to avoid unintended disruptions. This section explains scoped implementation choices: using namespaces, labels, and dry-run before making changes. ### Namespaces for Isolation Always operate within a specific namespace, especially in shared clusters. Use -n or --namespace to scope commands. Example: list Pods in the development namespace: kubectl get pods -n development To list Pods across all namespaces: kubectl get pods --all-namespaces ### Labels and Selectors Labels allow you to group and select Pods for bulk operations. For example, to get Pods with a specific label: kubectl get pods -l app=nginx This returns only Pods labeled app=nginx , reducing risk when filtering. You can combine multiple selectors: kubectl get pods -l app=nginx,environment=production ### Dry-Run for Validation Before applying changes, use --dry-run=client to validate the manifest or command without making changes: kubectl run nginx --image=nginx --dry-run=client -o yaml This prints the YAML that would be sent to the API server, allowing you to review it. The output starts with apiVersion: v1 and kind: Pod , showing the generated manifest. ### Example: Create a Pod Safely Instead of imperatively creating a Pod, generate a YAML manifest, review it, then apply: kubectl run nginx --image=nginx --dry-run=client -o yaml > nginx-pod.yaml # Edit the file as needed kubectl apply -f nginx-pod.yaml This approach aligns with GitOps practices and allows version control of your workloads. Always prefer declarative manifests in production. ## Verification and Diagnostics After creating or modifying Pods, you need to verify their state and diagnose issues. This section covers the essential commands for observability. ### List Pods Basic listing: kubectl get pods Expected output: NAME READY STATUS RESTARTS AGE nginx 1/1 Running 0 5m For more detail, use wide output: kubectl get pods -o wide This shows node, IP, and more. Example output: NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx 1/1 Running 0 5m 10.244.0.5 minikube To watch changes live: kubectl get pods -w This streams updates until you press Ctrl+C. ### Describe a Pod For detailed information including events: kubectl describe pod nginx Look for the Events section at the end to see scheduling, image pulling, and container starts. The output includes container statuses, conditions, and volumes. Example snippet: Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 5m default-scheduler Successfully assigned default/nginx to minikube Normal Pulling 5m kubelet Pulling image "nginx" Normal Pulled 5m kubelet Successfully pulled image "nginx" Normal Created 5m kubelet Created container nginx Normal Started 5m kubelet Started container nginx ### Get Pod Logs View logs from a container: kubectl logs nginx If multiple containers, specify container name: kubectl logs nginx -c nginx-container Follow logs with -f : kubectl logs -f nginx To see logs from a specific time period: kubectl logs nginx --since=1h ### Execute Commands in a Container Run a shell inside the Pod: kubectl exec -it nginx -- /bin/bash If the image does not have bash, try sh . Run a single command without interactive shell: kubectl exec nginx -- ls / Expected output (example): bin dev etc home proc root sys tmp usr var You can also set environment variables for the exec session: kubectl exec nginx -- env ### Port Forwarding Access a Pod's port locally: kubectl port-forward pod/nginx 8080:80 Now you can browse http://localhost:8080. The command runs in the foreground; use & to background it or open another terminal. To bind to a specific address: kubectl port-forward --address 0.0.0.0 pod/nginx 8080:80 ### Check Resource Usage If metrics-server is installed: kubectl top pod nginx Expected output: NAME CPU(cores) MEMORY(bytes) nginx 1m 4Mi For all Pods in a namespace: kubectl top pod -n development If metrics-server is not installed, you'll get an error: error: Metrics API not available . Install it using kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml (see official docs for your cluster).
Quick check 2 of 2 What is the smallest and simplest unit in the Kubernetes object model that you create or deploy? - Deployment - Service - Pod - Node
The passage states: 'A Pod is the basic building block of Kubernetes–the smallest and simplest unit in the Kubernetes object model that you create or deploy.'
## Failure Modes and Recovery Pods can fail for various reasons: image pull errors, crashes, resource limits, or node issues. Knowing how to identify and recover is critical. ### Common Failure Modes - ImagePullBackOff : The image cannot be pulled (wrong name, private registry auth, network). - CrashLoopBackOff : Container starts then exits repeatedly, often due to application error. - Pending : Pod cannot be scheduled, often due to insufficient resources. - OOMKilled : Container exceeded memory limit and was killed. ### Diagnosis Commands - kubectl describe pod : check Events and State. - kubectl logs --previous : get logs from previous crashed container instance. - kubectl get events --field-selector involvedObject.name=: list cluster events related to the Pod. Example for events: kubectl get events --field-selector involvedObject.name=nginx ### Example: Debug CrashLoopBackOff - Describe pod: kubectl describe pod myapp-7d9f8c5b-xyz - Check events: you might see Back-off restarting failed container . - Check logs: kubectl logs myapp-7d9f8c5b-xyz --previous to see why it exited. - If it's a config error, fix the ConfigMap or Secret and reapply. For example, if the container exits with code 1 due to missing environment variable, edit the Deployment to add the variable, then apply: kubectl edit deployment myapp # or modify manifest and kubectl apply -f deployment.yaml ### Recovery Actions - Delete and recreate the Pod (if managed by a Deployment, it will be automatically recreated). - Roll back a Deployment to a previous revision: kubectl rollout undo deployment/myapp . - Scale down to zero and back up if needed. - Adjust resource limits in the Pod spec to prevent OOMKilled. Example: Check rollout history: kubectl rollout history deployment/myapp Then rollback to a specific revision: kubectl rollout undo deployment/myapp --to-revision=2 Important: Never edit a Pod directly (except for debugging with kubectl edit pod ). Pods are immutable; use controllers like Deployments for updates. ## Operations Checklist Use this checklist for daily Pod operations to ensure consistency and safety.
TaskCommandNotes
List Pods in namespacekubectl get pods -n <namespace>Basic overview
List with labelskubectl get pods -l app=myappFilter by label
Describe a Podkubectl describe pod <name>Detailed status and events
View logskubectl logs <name> -fFollow logs
Execute commandkubectl exec -it <name> -- /bin/shInteractive shell
Port forwardkubectl port-forward pod/<name> <local>:<remote>Local access
Delete a Podkubectl delete pod <name>If managed, it will be recreated
Delete with grace periodkubectl delete pod <name> --grace-period=30Allow time for cleanup
Force delete (stuck)kubectl delete pod <name> --force --grace-period=0Last resort
Top resource usagekubectl top pod <name>Requires metrics-server
Check eventskubectl get events --sort-by=.metadata.creationTimestampRecent cluster events
Rollout restartkubectl rollout restart deployment/<name>Restart Pods in a Deployment
Scale Deploymentkubectl scale deployment/<name> --replicas=3Adjust replicas
Review Steps: - Always specify namespace when in doubt. - Prefer declarative manifests ( apply -f ) over imperative commands for production. - Use --dry-run=client before making changes. - Monitor Pod status after any change. - Use labels and selectors to avoid acting on unintended Pods. ## Conclusion Mastering basic Kubernetes Pod commands is essential for anyone working with containerized applications. In this guide, we covered the fundamental commands for listing, inspecting, creating, debugging, and deleting Pods, with safe practices and real-world examples. By following the version inventory, safe configuration path, verification methods, and recovery strategies, you can operate Kubernetes clusters with confidence. The key takeaways: - Use kubectl get , describe , and logs for daily observation. - Use exec and port-forward for debugging and local access. - Always scope commands with namespaces and labels. - Prefer declarative manifests and dry-run for changes. - Know how to diagnose and recover from common Pod failures. Next steps: practice these commands in a sandbox environment, start with a single Pod, then move to Deployments and more complex workloads. Use the operations checklist as a quick reference. With these skills, you'll be well-equipped to manage Kubernetes Pods in production.