26.4a kubectl get, describe, logs, exec, apply, delete — the essential verb set¶
Welcome to the world of Kubernetes command-line control. As a new engineer stepping into AI infrastructure and operations, kubectl (pronounced "kube-control") is your primary tool for interacting with any Kubernetes cluster — whether it's managing GPU nodes, deploying AI models, or troubleshooting workloads. Think of it as your remote control for the entire cluster.
This section covers the six most essential kubectl verbs you will use daily. Master these, and you will be able to inspect, debug, deploy, and remove resources with confidence.
⚙️ kubectl get — The Resource Inspector¶
kubectl get is your eyes into the cluster. It lists resources of a specific type running in the cluster.
- Use it to see all pods, services, nodes, deployments, or any other Kubernetes object.
- Add the -n flag to specify a namespace (like a project folder).
- Add the -o wide flag to see more details, such as IP addresses and node assignments.
- Add the -w flag to watch for changes in real-time.
Example usage: - To see all pods in the default namespace: kubectl get pods - To see all services across all namespaces: kubectl get svc --all-namespaces - To see nodes with extra details: kubectl get nodes -o wide
🕵️ kubectl describe — The Deep Dive Tool¶
While kubectl get gives you a summary, kubectl describe gives you the full story. It shows detailed configuration, current state, and recent events for a specific resource.
- Use this when a pod is failing and you need to understand why.
- It reveals resource limits, environment variables, mount points, and error messages.
- Events at the bottom of the output are especially useful — they show the history of actions taken by the cluster.
Example usage: - To inspect a specific pod named my-ai-pod: kubectl describe pod my-ai-pod - To check a node's capacity and conditions: kubectl describe node gpu-node-01
📊 kubectl logs — The Application Window¶
kubectl logs streams the standard output (stdout) and standard error (stderr) from a running container inside a pod. This is how you see what your application is printing.
- Use this to debug application errors, check training progress, or verify model outputs.
- If a pod has multiple containers, specify the container name with the -c flag.
- Add the --tail flag to see only the last N lines.
- Add the -f flag to follow the log stream in real-time (like tail -f).
Example usage: - To see logs from a single-container pod: kubectl logs training-pod - To see the last 50 lines from a specific container: kubectl logs inference-pod -c model-server --tail=50 - To follow logs as they are written: kubectl logs -f data-pipeline-pod
🛠️ kubectl exec — The Remote Shell¶
kubectl exec lets you run commands inside a running container. Think of it as SSH for your pods.
- Use this to inspect the filesystem, run diagnostic tools, or manually start processes.
- Add the -it flags for an interactive terminal session (like a shell).
- If a pod has multiple containers, specify which one with the -c flag.
Example usage: - To open a bash shell inside a pod: kubectl exec -it my-pod -- /bin/bash - To run a single command and exit: kubectl exec my-pod -- ls /data - To run a command in a specific container: kubectl exec -it my-pod -c sidecar-container -- sh
📊 Visual Representation: kubectl Command categories¶
This diagram groups essential kubectl subcommands for creating, checking, and debugging cluster objects.
📦 kubectl apply — The Deployment Engine¶
kubectl apply is how you create or update resources in the cluster using a YAML or JSON configuration file. This is the declarative way to manage your infrastructure.
- The file describes the desired state of the resource (what you want).
- Kubernetes works to make the current state match the desired state.
- You can apply the same file multiple times — it will update the resource if it already exists.
- This is the standard method for deploying AI workloads, GPU jobs, and services.
Example usage: - To create or update resources from a file: kubectl apply -f deployment.yaml - To apply all YAML files in a directory: kubectl apply -f ./configs/ - To apply from a URL: kubectl apply -f https://example.com/manifest.yaml
🗑️ kubectl delete — The Cleanup Tool¶
kubectl delete removes resources from the cluster. Use it to clean up after experiments, remove failed pods, or decommission services.
- You can delete by resource type and name, or by using the same YAML file you used to create it.
- Be careful — this action is immediate and irreversible for most resources.
- Some resources (like pods managed by a Deployment) will be recreated automatically unless you delete the parent resource.
Example usage: - To delete a specific pod: kubectl delete pod my-failed-pod - To delete all resources defined in a file: kubectl delete -f deployment.yaml - To delete all pods in a namespace: kubectl delete pods --all -n my-namespace
📋 Quick Reference Table¶
| Verb | Purpose | When to Use |
|---|---|---|
| get | List resources | Overview of what's running |
| describe | Show detailed info | Debugging failures or checking configuration |
| logs | View application output | Debugging application behavior |
| exec | Run commands inside containers | Inspecting files, running diagnostics |
| apply | Create or update resources | Deploying new workloads or updating configs |
| delete | Remove resources | Cleaning up or decommissioning |
💡 Pro Tips for New Engineers¶
- Always use namespaces — especially in shared clusters. It prevents you from accidentally modifying someone else's work.
- Use dry-run before applying changes: kubectl apply -f file.yaml --dry-run=client will validate your YAML without actually creating anything.
- Alias kubectl to k — it saves a lot of typing: alias k=kubectl
- Combine verbs with flags — for example, kubectl get pods -n kube-system -o wide gives you system pods with full details.
- Practice on a test cluster — never experiment on a production GPU cluster until you are confident.
🧠 Why This Matters for AI Infrastructure¶
In AI operations, you will constantly: - get GPU node status to see available resources - describe pods that fail due to insufficient GPU memory - logs to watch training loss curves or inference errors - exec into containers to verify CUDA driver versions - apply YAML files to launch distributed training jobs - delete completed or stuck jobs to free GPU resources
These six verbs form the foundation of every interaction you will have with your Kubernetes cluster. Master them, and you will be ready to manage even the most complex AI workloads at scale.