Demo — Kubernetes PodsCreate, inspect and manage Pods with kubectl

In this demo, we will see how to create and inspect an NGINX Pod inside a Minikube Kubernetes cluster.

In the previous tutorial, we learned what a Kubernetes Pod is, how containers run inside a Pod, and why the Pod is Kubernetes' smallest deployable unit.

Now we will see those concepts in practice.

The core idea of this demo:

We use kubectl to instruct Kubernetes to create a Pod. Kubernetes pulls the container image and runs the container inside the cluster.

We will also look at the difference between kubectl run and kubectl create deployment, and why Deployments matter for real applications.

1. What needs to be ready before starting the demo?

Before starting this demo, we assume:

1. A Minikube cluster is running.
2. kubectl is installed.
3. kubectl is configured to connect to the Minikube cluster.

In other words, we can now run Kubernetes commands from the terminal.

Check the Minikube status

minikube status

Check the Kubernetes node

kubectl get nodes

Expected example:

NAME       STATUS   ROLES           AGE   VERSION
minikube   Ready    control-plane   5m    v1.x.x

A Ready status here means the Kubernetes node is running and ready to run workloads.

2. Creating a Pod with kubectl

Now we will create a Kubernetes Pod using the NGINX container image.

Command:

kubectl run nginx --image=nginx

This command means:

Create a Pod named nginx, and run a container inside that Pod using the nginx container image.

Command breakdown

You can give the Pod any name you need, but it has to follow Kubernetes naming rules.

The image name, on the other hand, has to be a valid and accessible container image reference.

With the default configuration, the nginx image is usually pulled from Docker Hub.

What happens internally?

Developer
    |
    ▼
kubectl run nginx --image=nginx
    |
    ▼
Kubernetes API Server
    |
    ▼
Pod Object Created
    |
    ▼
Kubernetes Scheduler
    |
    ▼
Node Assignment
    |
    ▼
Kubelet
    |
    ▼
Container Runtime
    |
    ▼
NGINX Image Pull
    |
    ▼
NGINX Container Starts

In other words, we are not starting a Docker container directly.

We are creating a Kubernetes Pod, and Kubernetes executes the container through the container runtime.

3. Understanding the Pod name and container image tag

In the previous command, we wrote:

kubectl run nginx --image=nginx

There are two important things here.

Pod name: nginx

Container image: nginx

The Pod name is the name of the Kubernetes object.

The container image name tells Kubernetes which image to run the container from.

The default image tag

If no tag is given with the image name, the latest tag is usually used.

nginx

Usually equivalent to:

nginx:latest

But latest does not guarantee that the most recently published version is used. The behavior can depend on the image pull policy and the local image cache.

Using a specific image tag

kubectl run nginx --image=nginx:1.25

Here we use an image reference for a specific NGINX version.

A version-specific tag makes it easier to know which application version is running.

Tags can be changed, though. For strict reproducibility, pinning the image digest is more reliable.

Using an image from a private registry

Say the application image is stored in a company registry.

Example:

kubectl run myapp --image=myregistry.example.com/myapp:v1

Here, Kubernetes will try to pull the image from that specific registry.

For a private registry, you may need to configure image pull credentials.

Remember

Pod Name
    |
    ▼
The identity of the Kubernetes object

Image Name
    |
    ▼
The image reference used to create the container

The Pod name and the image name are not the same thing.

4. Checking the Pod status

After creating the Pod, we need to check whether it is running successfully.

Command:

kubectl get pods

Expected example:

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

Every column in this output matters.

Here we can see the NGINX Pod is running.

5. What does the READY column mean?

One important column in the output of kubectl get pods is READY.

For a single-container NGINX Pod:

READY
1/1

This means:

one of one containers is ready.

With multiple containers

Say a Pod has two containers.

The output could then be:

READY
2/2

That is, both of the two containers are ready.

When a container is not ready

READY
0/1

This means the Pod has one container defined, but it is not ready yet.

This can be because:

• The container hasn't started yet.
• The image is being pulled.
• There is a problem starting the container.
• The readiness check is not passing.

Example

Pod A → READY 1/1 → Ready
Pod B → READY 2/2 → Both Containers Ready
Pod C → READY 0/1 → Container Not Ready

READY and STATUS are not the same thing.

A Pod can be in the Running phase while its application container shows READY 0/1.

6. Understanding Pod STATUS

The STATUS column is very important for understanding a Pod's current state.

Common displayed status values:

A technical detail worth remembering here:

Pending and Running are actual Kubernetes Pod phases.

But ContainerCreating, Error and CrashLoopBackOff are usually container states or reasons that kubectl displays.

ContainerCreating

NAME    READY   STATUS              RESTARTS
nginx   0/1     ContainerCreating   0

Here, Kubernetes is preparing to start the container.

For example:

• Pulling the image
• Creating the container
• Configuring networking
• Mounting storage

Running

NAME    READY   STATUS    RESTARTS
nginx   1/1     Running   0

Here, the NGINX container is running and ready.

CrashLoopBackOff

NAME    READY   STATUS             RESTARTS
nginx   0/1     CrashLoopBackOff   5

This means the container keeps failing, and Kubernetes waits before restarting it again.

The output we want in this demo:

Running

Together with READY 1/1, it shows even more clearly that the test was successful.

7. Seeing detailed Pod information with kubectl describe

With kubectl get pods, we can see a Pod's basic status.

But if you need more detailed information about a Pod, use kubectl describe.

Command:

kubectl describe pod nginx

This command shows a lot of detailed information about the Pod.

For example:

• Pod name
• Labels
• Start time
• Node assignment
• Node IP address
• Pod IP address
• Container image
• Container state
• Events

Example structure

Name:         nginx
Namespace:    default
Node:         minikube/192.168.49.2
Start Time:   ...
Labels:       run=nginx
Status:       Running
IP:           10.244.0.3

Containers:
  nginx:
    Image:    nginx
    State:    Running

Events:
  ...

This output is only an example. Your actual cluster's IP addresses, timestamps and other details will differ.

kubectl get vs describe

kubectl describe is very useful when troubleshooting.

8. Node assignment — Which node is the Pod running on?

A Kubernetes cluster can have one or more nodes.

After a Pod is created, the Kubernetes scheduler decides which suitable node the Pod will run on.

The node information appears in the output of kubectl describe pod nginx.

Example:

Node: minikube/192.168.49.2

This means the NGINX Pod has been assigned to the minikube node. The part after the / is the node's IP address.

Single-node Minikube

Kubernetes Cluster
        |
        ▼
      Minikube
        |
        ▼
     NGINX Pod

There is usually one node here.

Multi-node Kubernetes cluster

Say the cluster has several worker nodes.

Kubernetes Cluster
        |
    +---+----------------+
    |                    |
    ▼                    ▼
 Worker Node 1       Worker Node 2
                         |
                         ▼
                      NGINX Pod

The scheduler can assign the Pod to any suitable node, based on resource availability and scheduling rules.

Example:

Pod nginx → Node worker-2

Here, the nginx Pod is running on the worker-2 node.

9. What is a Pod IP address?

Inside a Kubernetes cluster, every regular Pod usually gets an internal IP address.

This IP address is used for Pod networking.

You can see the Pod IP in the output of kubectl describe pod nginx.

Example:

IP: 10.244.0.3

Pod networking

Kubernetes Cluster
        |
        ▼
       Node
        |
        ▼
       Pod
        |
        ▼
IP: 10.244.0.3
        |
        ▼
  NGINX Container

Multiple containers in the same Pod usually share the same network namespace and Pod IP.

Can a Pod IP be reached from outside?

A Pod IP is usually part of the cluster's internal networking.

External users usually cannot reach a Pod IP directly.

That is what Kubernetes Services and networking configuration are for.

External User
      |
      ▼
Kubernetes Service
      |
      ▼
    Pod IP
      |
      ▼
NGINX Container

This tutorial focuses on creating and inspecting Pods, not on external networking.

10. Checking container information

kubectl describe pod nginx also shows details about the containers.

Our demo has one NGINX container.

Example:

Containers:
  nginx:
    Image:    nginx
    State:    Running

Here we can confirm:

• There is an NGINX container inside the Pod.
• The container image is nginx.
• The container is running.

If a Pod has multiple containers, you will see each container's details in this section.

Example:

Pod
 |
 ├── NGINX Container
 |
 └── Helper Container

The describe output would then contain information about both containers.

11. The Events section — Understanding a Pod's history

Near the bottom of the kubectl describe pod nginx output there is an Events section.

It is very important for Kubernetes troubleshooting.

The Events section shows a timeline of what happened after the Pod was created.

Example:

Pod Scheduled to minikube Node
           |
           ▼
NGINX Image Pulled
           |
           ▼
NGINX Container Created
           |
           ▼
NGINX Container Started

This way, you can track the different operations in a Pod's lifecycle.

Why do events matter?

Say you created a Pod, but it isn't reaching Running.

kubectl get pods

Output:

NAME    READY   STATUS             RESTARTS
nginx   0/1     ImagePullBackOff   0

What's the problem?

Most likely, Kubernetes cannot pull the container image.

To see detailed information:

kubectl describe pod nginx

You may see an image-pull-related error in the Events section.

For example:

Failed to pull image

With this information, diagnosing the problem becomes much easier.

Checking the Events section is very important when troubleshooting Pods.

12. kubectl get pods -o wide

To see more information alongside a Pod's basic status, you can use the -o wide option.

Command:

kubectl get pods -o wide

This command usually shows:

• Pod name
• Ready status
• Pod status
• Restart count
• Age
• Pod IP
• Node name

Example output

NAME    READY   STATUS    RESTARTS   AGE   IP           NODE
nginx   1/1     Running   0          1m    10.244.0.3   minikube

Here we can easily see:

Pod name: nginx

Pod status: Running

Pod IP: 10.244.0.3

Assigned node: minikube

This is useful for quickly checking a Pod's node assignment and internal IP.

13. The important commands in this demo

14. The complete basic Pod demo — Command flow

All the demo's commands together:

# 1. Create NGINX Pod
kubectl run nginx --image=nginx

# 2. Check Basic Pod Status
kubectl get pods

# 3. Inspect Pod Details
kubectl describe pod nginx

# 4. Check Pod IP and Node
kubectl get pods -o wide

With these four commands, we can create and inspect a Pod.

15. What did we learn from this demo?

From this demo, we learned:

• The Pod is Kubernetes' smallest deployable unit.
• A Pod can be created with the kubectl run command.
• The container image is specified with the --image option.
• Kubernetes can pull images from Docker Hub or another registry.
• kubectl get pods shows a Pod's status.
• kubectl describe pod shows detailed information.
• Each Pod usually gets its own internal IP address.
• kubectl get pods -o wide shows the Pod IP and node information.

Basic Pod workflow

kubectl run
     |
     ▼
Pod Created
     |
     ▼
Container Image Pulled
     |
     ▼
Container Started
     |
     ▼
kubectl get pods
     |
     ▼
kubectl describe pod
     |
     ▼
kubectl get pods -o wide

16. Important note — The kubectl run behavior change

Older Kubernetes tutorials show some different examples of the kubectl run command.

There is an important version-related change here.

In kubectl 1.18 and later, kubectl run creates a Pod by default, not a Deployment.

kubectl run creates a Pod

kubectl run nginx --image=nginx

This command creates:

Pod
 |
 └── NGINX Container

It does not create a Deployment.

Version history

Many tutorials and labs from before Kubernetes 1.18 show examples of creating a Deployment with kubectl run.

But the modern kubectl behavior is:

kubectl run → Pod

This difference is worth remembering, because following an old tutorial can cause confusion.

17. Creating a Deployment with kubectl

If you want to create a Deployment rather than just a standalone Pod, you need a different command.

Command:

kubectl create deployment nginx --image=nginx

This command creates a Deployment.

Through a Deployment, Kubernetes can manage application Pods.

Check the Deployment

kubectl get deployments

To see the Pods the Deployment manages:

kubectl get pods

Deployment architecture

Deployment
    |
    ▼
ReplicaSet
    |
    ▼
   Pod
    |
    ▼
NGINX Container

A Deployment is a higher-level Kubernetes object.

It manages Pods through a ReplicaSet.

18. Pod vs Deployment — What's the difference?

A Pod and a Deployment are not the same thing.

Standalone Pod

kubectl run nginx --image=nginx

This command creates a standalone Pod.

Pod
 |
 └── NGINX Container

Deployment

kubectl create deployment nginx --image=nginx

This command creates a Deployment.

Deployment
    |
    ▼
ReplicaSet
    |
    ▼
Pod
    |
    ▼
NGINX Container

A standalone Pod is useful for simple testing.

But in production, a Deployment is usually preferred for stateless applications.

That is because a Deployment helps maintain the application's desired state.

19. Why do Deployments matter?

A standalone Pod has some limitations.

Say you create a Pod.

kubectl run nginx --image=nginx

If the container now crashes, the kubelet may try to restart it according to the Pod's restart policy.

But if the Pod is deleted, a standalone Pod is not recreated automatically.

With a Deployment, on the other hand, Kubernetes tries to keep a specific number of Pods running.

Key features of a Deployment:

• Replica management
• Self-healing
• Rolling updates
• Rollbacks
• Scaling
• Declarative management

Features explained

Important: Deployments are most commonly used to manage stateless applications.

20. Scaling an application with a Deployment

Say we have created an NGINX Deployment.

kubectl create deployment nginx --image=nginx

Now the application needs three replicas.

Command:

kubectl scale deployment nginx --replicas=3

This command tells Kubernetes:

Maintain three Pod replicas of the NGINX application.

Architecture

                  Deployment
                      |
                      ▼
                   ReplicaSet
                      |
           +----------+----------+
           |          |          |
           ▼          ▼          ▼
         Pod 1      Pod 2      Pod 3
           |          |          |
           ▼          ▼          ▼
         NGINX      NGINX      NGINX

Kubernetes will now try to keep three Pods running.

If a Pod is deleted, the ReplicaSet can create a replacement Pod.

Example

Before:

Deployment nginx
     |
     ▼
   1 Pod

After scaling:

Deployment nginx
     |
     ▼
   3 Pods

This mechanism is important for application availability and scaling.

21. A Deployment YAML example

Kubernetes resources can be created not only with commands but also with YAML manifests.

Say we want to maintain three NGINX Pods.

Then we create a deployment.yaml file.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.25
          ports:
            - containerPort: 80

YAML breakdown

Applying the Deployment

kubectl apply -f deployment.yaml

This command submits the YAML manifest to the Kubernetes API server.

Kubernetes then manages the Deployment, ReplicaSet and Pods according to the desired state.

Verifying

kubectl get deployments

Then:

kubectl get pods

Expected example:

NAME                     READY   STATUS
nginx-xxxxxxxxxx-aaaaa   1/1     Running
nginx-xxxxxxxxxx-bbbbb   1/1     Running
nginx-xxxxxxxxxx-ccccc   1/1     Running

Three NGINX Pods are running here.

22. Does kubectl always work through a Deployment?

No.

You don't need a Deployment to use kubectl.

kubectl can create, update, delete and inspect many kinds of Kubernetes resources.

For example:

• Pods
• Deployments
• Services
• ConfigMaps
• Secrets
• Jobs
• StatefulSets
• DaemonSets

In other words, kubectl is a general-purpose Kubernetes management CLI.

How kubectl and Deployments relate

kubectl
   |
   ▼
Kubernetes API Server
   |
   ├── Pod
   |
   ├── Deployment
   |
   ├── Service
   |
   ├── ConfigMap
   |
   ├── Secret
   |
   └── Other Resources

kubectl itself is not a Deployment.

A Deployment is one type of Kubernetes resource.

A simple rule

kubectl    = Command-Line Tool
Deployment = Desired Application State
ReplicaSet = Maintains the Desired Number of Pods
Pod        = Runs the Container

23. When to use a Pod and when to use a Deployment

Understanding this difference is important.

For a quick test

kubectl run nginx --image=nginx

For proper application management

kubectl create deployment nginx --image=nginx

For real stateless applications, a Deployment is usually the better fit.

24. Pod vs Deployment — A simple mental model

A simple example helps you remember the whole concept.

Imagine a Pod is a worker.

And a Deployment is a manager who wants to keep a specific number of workers.

Standalone Pod

Pod
 |
 ▼
Worker

If this worker is removed, there is no higher-level controller to replace them.

Deployment

Deployment Manager
        |
        ▼
     ReplicaSet
        |
        +---------+---------+
        |         |         |
        ▼         ▼         ▼
      Pod 1     Pod 2     Pod 3
        |         |         |
      Worker    Worker    Worker

Now, if one Pod is deleted, the ReplicaSet will try to maintain the desired replica count.

That is the core idea of a Deployment's self-healing and replica management.

25. Complete hands-on commands — Pod and Deployment

All the important commands from this tutorial together:

# ==========================================
# PART 1: STANDALONE POD
# ==========================================

# Check Kubernetes Cluster
kubectl get nodes

# Create NGINX Pod
kubectl run nginx --image=nginx

# List Pods
kubectl get pods

# Get Detailed Pod Information
kubectl describe pod nginx

# Show Pod IP and Node
kubectl get pods -o wide

# Delete Standalone Pod
kubectl delete pod nginx

# ==========================================
# PART 2: DEPLOYMENT
# ==========================================

# Create NGINX Deployment
kubectl create deployment nginx --image=nginx

# List Deployments
kubectl get deployments

# List Deployment Pods
kubectl get pods

# Scale Deployment to 3 Replicas
kubectl scale deployment nginx --replicas=3

# Verify Deployment
kubectl get deployments

# Verify Pods
kubectl get pods

# Delete Deployment
kubectl delete deployment nginx

26. Important commands summary

27. Final takeaway — Kubernetes Pods & Deployments

The most important things in this demo are creating a Pod, inspecting it, and understanding the difference between a Pod and a Deployment.

To create a Pod:

kubectl run nginx --image=nginx

To check the Pod status:

kubectl get pods

To see detailed information:

kubectl describe pod nginx

To see the Pod IP and node information:

kubectl get pods -o wide

And to create a Deployment:

kubectl create deployment nginx --image=nginx

To scale the application:

kubectl scale deployment nginx --replicas=3

The complete Kubernetes workload architecture

Developer
    |
    ▼
  kubectl
    |
    ▼
Kubernetes API Server
    |
    ▼
 Deployment
    |
    ▼
 ReplicaSet
    |
    +-----------+-----------+
    |           |           |
    ▼           ▼           ▼
   Pod 1       Pod 2       Pod 3
    |           |           |
    ▼           ▼           ▼
 Container   Container   Container
    |           |           |
    ▼           ▼           ▼
 Application Application Application

The final memory rule

kubectl run
     |
     ▼
    Pod


kubectl create deployment
     |
     ▼
 Deployment
     |
     ▼
 ReplicaSet
     |
     ▼
    Pod
     |
     ▼
 Container

The most important point: you don't need a Deployment to use kubectl. But for real stateless applications, a Deployment is usually preferred, because it provides replica management, scaling, self-healing, rolling updates and rollback support.

Official Documentation

• Kubernetes — Pods
• Kubernetes — Deployments
• Kubernetes — ReplicaSets
• kubectl run
• kubectl create deployment
• Kubernetes — Workload Management

One-line summary

In Kubernetes, kubectl run creates a standalone Pod, and kubectl create deployment creates a Deployment. A Deployment manages Pods through a ReplicaSet, so that the application's desired number of replicas keeps running.