If Kubernetes is the operating system/manager of your cluster, then:

kubectl is your command-line remote control for Kubernetes.

By the end of this chapter, you should be comfortable with the commands you'll use constantly in real Kubernetes work.

1. What is kubectl?#

kubectl is the official command-line tool for communicating with the Kubernetes API.

When you run:

kubectl get pods

the flow is approximately:

You
 ↓
kubectl
 ↓
Kubernetes API Server
 ↓
Cluster
 ↓
Response
 ↓
kubectl
 ↓
Terminal

Remember Chapter 3:

kubectl → API Server → Kubernetes

kubectl does not directly control the containers.

It communicates with the Kubernetes API.

2. Installing Kubernetes Locally#

For learning, you need a local Kubernetes cluster.

There are several options:

Option 1 — Docker Desktop Kubernetes#

Easy if you're already using Docker Desktop.

Option 2 — Minikube#

Very popular for learning.

Your Computer
     ↓
Minikube
     ↓
Kubernetes Cluster

Option 3 — Kind#

Kind = Kubernetes IN Docker

It runs Kubernetes nodes as Docker containers.

For this course, we'll use the concepts in a way that works across local Kubernetes environments.

3. Check kubectl#

Run:

kubectl version --client

You should see the client version.

Then:

kubectl cluster-info

If your cluster is running, you'll see information about the Kubernetes control plane.

4. kubectl get#

The most commonly used command is:

kubectl get

It asks Kubernetes:

"Show me resources."

For example:

kubectl get pods

You might get:

NAME       READY   STATUS    RESTARTS   AGE
nginx      1/1     Running   0          2m

5. What is a Pod?#

You already learned this in Chapter 1.

For now:

Pod
└── Container

So:

kubectl get pods

means:

Show me the Pods in the current namespace.

6. kubectl get nodes#

To see your Kubernetes machines:

kubectl get nodes

Example:

NAME       STATUS   ROLES           AGE   VERSION
node-1     Ready    control-plane   10m   v1.xx.x
node-2     Ready    <none>          10m   v1.xx.x

The important column is:

STATUS

You generally want:

Ready

7. kubectl get all#

You can get several common resources using:

kubectl get all

You might see:

NAME                         READY   STATUS
pod/nginx                    1/1     Running
 
NAME                 TYPE        CLUSTER-IP
service/nginx        ClusterIP   10.x.x.x
 
NAME                    READY
deployment.apps/nginx   1/1
 
NAME                               DESIRED
replicaset.apps/nginx-xxxxx       1

Don't worry about all these resource types yet.

We'll learn them individually.

8. Creating Your First Pod#

Let's create a Pod using an image.

kubectl run nginx --image=nginx

This means approximately:

Create a Pod named nginx using the nginx container image.

Now:

kubectl get pods

You should see something like:

NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          10s

Congratulations — you've created your first Kubernetes workload.

9. Understanding the Output#

Look at:

READY

If you see:

1/1

it means:

1 container ready
/
1 container expected

STATUS#

For example:

Running

means the Pod is currently running.

Other states you'll eventually encounter:

Pending
Running
Succeeded
Failed
Unknown
CrashLoopBackOff
ImagePullBackOff

We'll learn troubleshooting later.

10. kubectl describe#

This is one of the most important debugging commands.

Run:

kubectl describe pod nginx

You'll get detailed information about the Pod.

You'll see things such as:

Name
Namespace
Node
Status
IP
Containers
Images
Ports
Conditions
Events

11. Why describe is so useful#

Suppose your Pod is stuck:

STATUS
Pending

You run:

kubectl describe pod nginx

At the bottom you'll often find:

Events:
  Warning  FailedScheduling

This can tell you why Kubernetes couldn't schedule the Pod.

So remember:

get
 ↓
Quick overview
 
describe
 ↓
Detailed information

12. kubectl logs#

Your application generates logs.

For example:

console.log("Server started");

To see container logs:

kubectl logs nginx

For a Node.js application:

kubectl logs my-api

13. Follow Logs#

Just like:

docker logs -f

you can use:

kubectl logs -f nginx

-f means:

Follow the logs.

You'll see new log entries as they're generated.

14. Multiple Containers in a Pod#

Remember:

Pod
├── Container A
└── Container B

If a Pod has multiple containers, you can specify which container's logs you want:

kubectl logs my-pod -c my-container

15. kubectl exec#

Sometimes you need to enter a running container.

For example:

kubectl exec -it nginx -- /bin/sh

This is similar to:

docker exec -it <container> /bin/sh

You might then see:

/ #

Now you're inside the container.

Try:

ls

or:

pwd

Then:

exit

16. kubectl delete#

To delete the Pod:

kubectl delete pod nginx

Then:

kubectl get pods

You might see:

No resources found

Important: This behavior is different if the Pod is managed by a Deployment.

If a Deployment says:

replicas: 3

and you manually delete one Pod:

Pod 1
Pod 2
Pod 3
 
Delete Pod 2

the Deployment controller will create a replacement:

Pod 1
Pod 3
Pod 4

That's the reconciliation concept from Chapter 3 in action.

17. kubectl apply#

This is one of the most important commands in real Kubernetes development.

Instead of creating resources manually, you usually define the desired state in YAML.

Example:

apiVersion: v1
kind: Pod
 
metadata:
  name: nginx
 
spec:
  containers:
    - name: nginx
      image: nginx

Save it as:

pod.yaml

Then:

kubectl apply -f pod.yaml

Kubernetes reads your declaration and attempts to make the cluster match it.

18. Imperative vs Declarative#

This is a very important concept.

Imperative#

You're telling Kubernetes what action to perform.

kubectl run nginx --image=nginx

Meaning:

Create this Pod.

Declarative#

You're describing the desired state.

kind: Deployment
spec:
  replicas: 3

Then:

kubectl apply -f deployment.yaml

Meaning:

Make the cluster match this configuration.

Production Kubernetes heavily relies on the declarative approach.

19. kubectl apply Is Powerful#

Suppose your YAML says:

replicas: 3

Kubernetes has:

3 Pods

You change:

replicas: 5

and run:

kubectl apply -f deployment.yaml

Kubernetes works toward:

5 Pods

You don't manually create Pod #4 and Pod #5.

You tell Kubernetes the desired state.

20. kubectl get -o wide#

Sometimes you want additional information.

Run:

kubectl get pods -o wide

You might see:

NAME    READY   STATUS    IP          NODE
nginx   1/1     Running   10.1.0.5    node-1

Now you can see which node the Pod is running on.

21. kubectl get pods -A#

Remember namespaces?

By default:

kubectl get pods

looks in your current namespace.

To see Pods across all namespaces:

kubectl get pods -A

You might see:

NAMESPACE       NAME
default         nginx
kube-system     coredns-xxxxx
kube-system     kube-proxy-xxxxx

-A means:

All namespaces.

22. Namespaces#

You can list namespaces:

kubectl get namespaces

or:

kubectl get ns

Typical output:

NAME              STATUS
default           Active
kube-system       Active
kube-public       Active
kube-node-lease   Active

We'll study namespaces properly later.

For now:

A namespace is a logical boundary for Kubernetes resources.

23. -n — Namespace#

Suppose your application is in:

production

You can run:

kubectl get pods -n production

Without -n, Kubernetes uses the current namespace.

24. kubectl get deployment#

Once we start using Deployments:

kubectl get deployments

or:

kubectl get deploy

Example:

NAME    READY   UP-TO-DATE   AVAILABLE
api     3/3     3            3

This means your Deployment currently has the desired number of replicas available.

25. kubectl get replicaset#

You can inspect ReplicaSets:

kubectl get replicasets

or:

kubectl get rs

We'll learn why Deployments create ReplicaSets in the next few chapters.

26. kubectl get services#

Services:

kubectl get services

or:

kubectl get svc

Example:

NAME    TYPE        CLUSTER-IP
api     ClusterIP   10.96.100.20

Services provide stable networking for Pods.

We'll study them deeply later.

27. Resource Shortcuts#

Kubernetes has shortcuts.

Instead of:

kubectl get pods

you can use:

kubectl get po

Deployment:

kubectl get deploy

Service:

kubectl get svc

ReplicaSet:

kubectl get rs

Namespace:

kubectl get ns

You'll naturally memorize these with practice.

28. kubectl explain#

This is a fantastic built-in learning tool.

For example:

kubectl explain pod

You can go deeper:

kubectl explain pod.spec

And:

kubectl explain pod.spec.containers

This lets you inspect Kubernetes resource schemas from the CLI.

29. kubectl config#

Your kubectl needs to know:

Which Kubernetes cluster should I communicate with?

This information is managed through Kubernetes configuration.

Check your current context:

kubectl config current-context

List contexts:

kubectl config get-contexts

Example:

CURRENT   NAME
*         minikube
          production
          staging

30. What is a Context?#

A context tells kubectl things such as:

Which cluster?
Which user?
Which default namespace?

Conceptually:

kubectl
   ↓
Current Context
   ↓
Cluster
   ↓
API Server

This becomes extremely important when you work with multiple environments.

Imagine:

Local
Staging
Production

You definitely don't want to accidentally deploy to production.

31. The Most Important kubectl Commands#

Start memorizing these:

kubectl get pods
kubectl get nodes
kubectl get deployments
kubectl get services

Detailed information:

kubectl describe pod <name>
kubectl describe deployment <name>

Logs:

kubectl logs <pod>
kubectl logs -f <pod>

Execute:

kubectl exec -it <pod> -- /bin/sh

Apply YAML:

kubectl apply -f file.yaml

Delete:

kubectl delete -f file.yaml

All namespaces:

kubectl get pods -A

Current context:

kubectl config current-context

32. A Real Debugging Workflow#

Suppose your application isn't working.

Don't randomly run commands.

Use a systematic process.

Step 1 — Check Pods#

kubectl get pods

Maybe:

api-abc123   0/1   CrashLoopBackOff

Step 2 — Check Logs#

kubectl logs api-abc123

Maybe you discover:

Error: DATABASE_URL is missing

Step 3 — Describe the Pod#

kubectl describe pod api-abc123

Look at:

Events

Step 4 — Check Deployment#

kubectl get deployment

Step 5 — Check Service#

kubectl get service

This basic workflow will become second nature.

33. Kubernetes Troubleshooting Mindset#

Remember:

Problem
  ↓
kubectl get
  ↓
What's happening?
  ↓
kubectl describe
  ↓
Why is it happening?
  ↓
kubectl logs
  ↓
What does the application say?

A useful rule:

get tells you WHAT. describe often tells you WHY. logs tell you WHAT THE APPLICATION IS SAYING.

34. Important Command Pattern#

You'll notice Kubernetes commands generally follow:

kubectl
   ↓
verb
   ↓
resource
   ↓
optional name/flags

Example:

kubectl get pod nginx

kubectl → tool
get     → action
pod     → resource
nginx   → specific resource

Another:

kubectl delete pod nginx

delete → action
pod    → resource
nginx  → resource name

35. YAML Is Going to Become Very Important#

Kubernetes is heavily declarative.

You'll frequently write:

apiVersion: apps/v1
kind: Deployment
 
metadata:
  name: api
 
spec:
  replicas: 3

Then:

kubectl apply -f deployment.yaml

Instead of memorizing hundreds of commands, you'll learn to define the desired state in YAML.

🧠 Chapter 4 Cheat Sheet#

kubectl get
    ↓
See resources
 
kubectl describe
    ↓
Detailed information
 
kubectl logs
    ↓
Application logs
 
kubectl exec
    ↓
Enter/run command inside container
 
kubectl apply
    ↓
Create/update desired state
 
kubectl delete
    ↓
Delete resource
 
kubectl get -A
    ↓
All namespaces
 
kubectl -n <namespace>
    ↓
Specific namespace
 
kubectl config
    ↓
Manage cluster/context configuration

🎯 Mini Practical Exercise#

If you have a local Kubernetes cluster, try:

1. Check cluster#

kubectl cluster-info

2. Check nodes#

kubectl get nodes

3. Create nginx#

kubectl run nginx --image=nginx

4. Check Pod#

kubectl get pods

5. Get detailed information#

kubectl describe pod nginx

6. View logs#

kubectl logs nginx

7. Delete it#

kubectl delete pod nginx

8. Confirm#

kubectl get pods

⭐ One Important Thing to Remember#

Don't think of kubectl as a tool that directly "runs Docker commands."

Think:

                kubectl
                   ↓
             Kubernetes API
                   ↓
              Control Plane
                   ↓
             Desired State
                   ↓
              Controllers
                   ↓
                Scheduler
                   ↓
               Worker Node
                   ↓
                kubelet
                   ↓
            Container Runtime
                   ↓
               Container

That's the complete mental model.

🚀 Next — Chapter 5: Pods#

Now we'll go deep into Pods, including:

• Why Kubernetes has Pods instead of directly managing containers
• Pod lifecycle
• Pod phases
• Restart policies
• Multi-container Pods
• Sidecar containers
• Pod IP addresses
• Pod networking
• Pod YAML
• Creating Pods declaratively
• Why you generally shouldn't create Pods directly in production
• What happens when a Pod crashes

And we'll build several Pods ourselves.