kubectl Basics
Learn how kubectl fits into Kubernetes workflows and when to use imperative commands versus declarative manifests.
What Is kubectl?
kubectl is your daily control surface for Kubernetes. It can inspect the cluster, create resources, apply manifests, stream logs, exec into containers, and switch contexts.
How kubectl Talks to the Cluster
Request flow: kubectl → running pod
kubectl apply
Your command
API Server
Validates & persists to etcd
etcd
Stores desired state
Scheduler
Picks the best node
kubelet
Receives pod spec
Container Runtime
Pulls image & starts container
Pod Running
✓ Desired state achieved
kubectl apply
Your command
API Server
Validates & persists to etcd
etcd
Stores desired state
Scheduler
Picks the best node
kubelet
Receives pod spec
Container Runtime
Pulls image & starts container
Pod Running
✓ Desired state achieved
The important idea is that kubectl usually does not talk directly to pods or nodes first. It talks to the API Server.
Imperative vs Declarative
Imperative
With the imperative style, you tell Kubernetes exactly what command to perform right now.
Examples:
kubectl create deployment web --image=nginx
kubectl scale deployment web --replicas=3
Declarative
With the declarative style, you describe the desired end state in YAML and apply it.
kubectl apply -f deployment.yaml
Declarative workflows are better for version control, reviews, repeatability, and production change tracking.
When to Use Each Style
| Style | Best for |
|---|---|
| Imperative | Quick experiments, demos, and one-off tasks |
| Declarative | Team workflows, GitOps, repeatable environments, production changes |
Sub-pages in This Section
| Sub-topic | What you will learn |
|---|---|
| Get and Describe | Inspect resources and read detailed object information |
| Apply and Delete | Create, update, diff, and remove resources |
| Exec and Logs | Debug running workloads and stream logs |
| Contexts and Namespaces | Switch clusters and scope commands safely |
Why kubectl Matters So Much
kubectl is more than a command list. It is how you observe the cluster, express desired state, and debug behavior. Learning it well gives you leverage across nearly every Kubernetes workflow.
Preferred Production Style
Which approach is usually better for production changes that should be reviewed and repeated safely?
kubectl Path
In a typical workflow, what component does kubectl contact first?