Creating Pods with kubectl in Kubernetes - Mechanics & Internals

Overview - Creating Pods with kubectl

What is it?

Creating Pods with kubectl means using a command-line tool to tell Kubernetes to start one or more containers grouped together as a Pod. A Pod is the smallest unit in Kubernetes that can run an application. Using kubectl, you can create Pods directly by specifying their configuration in a file or command. This lets you run your app inside Kubernetes easily.

Why it matters

Without the ability to create Pods, you cannot run any applications on Kubernetes. Pods are the basic building blocks that hold your containers. If you had no simple way to create Pods, managing and deploying apps would be very slow and error-prone. Kubectl makes it fast and consistent to launch Pods, so your apps can run reliably in the cloud or on servers.

Where it fits

Before learning to create Pods, you should understand what containers are and have basic knowledge of Kubernetes concepts like nodes and clusters. After mastering Pod creation, you can learn about managing Pods with deployments, scaling, and networking. This is an early step in the Kubernetes learning path.

Mental Model

Core Idea

Creating Pods with kubectl is like giving Kubernetes a precise recipe to start one or more containers together as a single unit.

Think of it like...

Imagine you want to bake a cake. The Pod is the cake, and kubectl is the recipe you give to the baker (Kubernetes) to make it exactly how you want. Without the recipe, the baker doesn't know what to make or how.

┌─────────────┐
│ kubectl CLI │
└──────┬──────┘
       │  create Pod
       ▼
┌─────────────┐
│ Kubernetes  │
│ Control     │
│ Plane       │
└──────┬──────┘
       │ schedules
       ▼
┌─────────────┐
│ Node(s)     │
│ ┌─────────┐ │
│ │ Pod     │ │
│ │(Containers)│
│ └─────────┘ │
└─────────────┘

Build-Up - 7 Steps

1

Foundation

What is a Pod in Kubernetes

Concept: Introduce the basic unit called Pod that holds one or more containers.

A Pod is the smallest deployable unit in Kubernetes. It can hold one or more containers that share storage, network, and specifications. Pods run on nodes inside the Kubernetes cluster. They are ephemeral and can be created or destroyed by Kubernetes as needed.

Result

You understand that Pods are the basic units where your app containers run inside Kubernetes.

Understanding Pods as the smallest unit helps you grasp how Kubernetes organizes and runs your applications.

2

Foundation

Introduction to kubectl Command

Concept: Learn about kubectl as the command-line tool to interact with Kubernetes.

kubectl is the main tool to communicate with Kubernetes clusters. You use it to create, update, delete, and inspect Kubernetes resources like Pods. It sends commands to the Kubernetes API server, which manages the cluster state.

Result

You can run basic kubectl commands to see cluster info and resources.

Knowing kubectl is essential because it is your direct way to control Kubernetes resources.

3

Intermediate

Creating a Pod with kubectl run

🤔Before reading on: do you think 'kubectl run' creates a Pod directly or a Deployment? Commit to your answer.

Concept: Use the kubectl run command to create a simple Pod quickly from the command line.

The command 'kubectl run my-pod --image=nginx --restart=Never' creates a Pod named 'my-pod' running the nginx container. This is a quick way to start a Pod without writing a file. However, newer kubectl versions create a Deployment by default unless you specify '--restart=Never' to create a Pod directly.

Result

A Pod named 'my-pod' runs nginx on the cluster node.

Knowing the default behavior of 'kubectl run' prevents confusion between Pods and Deployments.

4

Intermediate

Creating Pods Using YAML Files

🤔Before reading on: do you think YAML files are mandatory or optional for creating Pods? Commit to your answer.

Concept: Learn to define Pods declaratively using YAML files and create them with kubectl apply.

You write a YAML file describing the Pod's metadata, containers, and specs. For example: apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: nginx image: nginx Then run 'kubectl apply -f pod.yaml' to create the Pod. This method is preferred for version control and repeatability.

Result

The Pod described in the YAML file is created and running in the cluster.

Using YAML files makes Pod creation transparent, repeatable, and easy to manage in teams.

5

Intermediate

Checking Pod Status After Creation

🤔Before reading on: do you think a Pod is immediately ready after creation or takes time? Commit to your answer.

Concept: Learn to verify if the Pod is running and healthy using kubectl commands.

Run 'kubectl get pods' to see Pod status. It shows if the Pod is Pending, Running, or Failed. Use 'kubectl describe pod my-pod' for detailed info and events. This helps you confirm your Pod started correctly or troubleshoot issues.

Result

You can see the Pod's current state and diagnose problems if it is not running.

Knowing how to check Pod status is crucial for managing app health and debugging.

6

Advanced

Pod Lifecycle and Restart Policies

🤔Before reading on: do you think Pods restart automatically by default or not? Commit to your answer.

Concept: Understand how Pod restart policies affect container restarts and Pod behavior.

Pods have a restartPolicy field with values like Always, OnFailure, or Never. By default, it is Always for Deployments but Always for standalone Pods as well. This controls if containers restart on failure. Knowing this helps design reliable apps and avoid unexpected restarts.

Result

You can control Pod restart behavior to match your app needs.

Understanding restart policies prevents surprises in app availability and resource use.

7

Expert

Direct Pod Creation vs Using Controllers

🤔Before reading on: do you think creating Pods directly is recommended for production or only for testing? Commit to your answer.

Concept: Learn why experts avoid creating Pods directly in production and prefer controllers like Deployments.

Directly created Pods are not managed by controllers, so if they fail or are deleted, Kubernetes won't recreate them. Controllers like Deployments manage Pods automatically, ensuring desired state and scaling. Experts use direct Pod creation mainly for debugging or simple tests.

Result

You understand the risks of direct Pod creation and when to use controllers.

Knowing the limits of direct Pod creation helps maintain stable, self-healing production systems.

Under the Hood

When you run 'kubectl create' or 'kubectl apply', kubectl sends a request to the Kubernetes API server. The API server validates the Pod specification and stores it in etcd, the cluster's database. The scheduler then assigns the Pod to a suitable node based on resource availability. The kubelet on that node receives the Pod spec and starts the container runtime to launch the containers inside the Pod. The kubelet continuously monitors the Pod's health and reports status back to the API server.

Why designed this way?

Kubernetes separates control and data planes for scalability and reliability. The API server centralizes cluster state, while nodes handle actual container execution. This design allows declarative management, where users specify desired state and Kubernetes ensures it. Direct Pod creation is simple but lacks self-healing, so controllers were introduced to automate management.

┌───────────────┐
│ kubectl CLI   │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ API Server    │
│ (Validates & │
│  stores Pod)  │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Scheduler     │
│ (Assigns Pod  │
│  to Node)     │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Node (kubelet)│
│ (Runs Pod &   │
│  containers)  │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does 'kubectl run' always create a Pod directly? Commit to yes or no.

Common Belief: Many believe 'kubectl run' always creates a Pod directly.

Reality: By default, 'kubectl run' creates a Deployment, not a Pod, unless '--restart=Never' is specified.

Why it matters: Assuming it creates a Pod can cause confusion when multiple Pods appear or when scaling behavior is unexpected.

Quick: Do Pods automatically restart forever by default? Commit to yes or no.

Common Belief: People often think Pods always restart containers automatically on failure.

Reality: Standalone Pods have restartPolicy 'Always' by default, so containers do restart unless specified otherwise.

Why it matters: This can lead to apps stopping unexpectedly if restart policies are not set correctly.

Quick: Is creating Pods directly recommended for production? Commit to yes or no.

Common Belief: Some believe creating Pods directly is fine for production workloads.

Reality: Direct Pod creation lacks self-healing and scaling; controllers like Deployments are recommended for production.

Why it matters: Using direct Pods in production risks downtime and manual recovery.

Quick: Does deleting a Pod always delete the application? Commit to yes or no.

Common Belief: Many think deleting a Pod deletes the whole application permanently.

Reality: If a Pod is managed by a controller, deleting it causes Kubernetes to recreate it automatically.

Why it matters: Misunderstanding this can cause panic or unnecessary manual intervention.

Expert Zone

1

kubectl run's behavior changed over versions; knowing your kubectl version avoids surprises.

2

Pod specs can include init containers that run before main containers, useful for setup tasks.

3

Labels and selectors on Pods are critical for controllers and services to manage and route traffic properly.

When NOT to use

Direct Pod creation is not suitable for production apps needing high availability or scaling. Instead, use controllers like Deployments, StatefulSets, or DaemonSets that manage Pods automatically and ensure desired state.

Production Patterns

In production, teams use YAML manifests stored in version control and apply them via CI/CD pipelines. Pods are rarely created directly; instead, Deployments manage Pods with rolling updates and scaling. Debugging may involve creating temporary Pods directly.

Connections

Infrastructure as Code (IaC)

Creating Pods declaratively with YAML files is a form of IaC.

Understanding declarative Pod creation helps grasp how infrastructure can be managed as code for repeatability and automation.

Process Management in Operating Systems

Pods group containers like processes grouped in a job or session.

Knowing how OS manages processes helps understand how Kubernetes manages container lifecycles inside Pods.

Project Management

Using kubectl to create Pods is like assigning tasks to team members with clear instructions.

Clear, declarative instructions (YAML) ensure predictable outcomes, similar to good project task definitions.

Common Pitfalls

#1 Creating a Pod with 'kubectl run' without specifying restart policy causes unexpected Deployment creation.

Wrong approach:

kubectl run my-pod --image=nginx

Correct approach:

kubectl run my-pod --image=nginx --restart=Never

Root cause:

Not knowing that 'kubectl run' defaults to creating a Deployment unless restart policy is set.

#2 Applying a Pod YAML file with syntax errors causes creation failure.

Wrong approach:

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

Correct approach:

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

Root cause:

Missing colon ':' after 'image' causes YAML parsing error.

#3 Deleting a Pod manually in production expecting it to stay deleted.

Wrong approach:

kubectl delete pod my-pod

Correct approach:

kubectl scale deployment my-deployment --replicas=0

Root cause:

Not understanding that controllers recreate Pods automatically; scaling down the controller is needed to stop Pods.

Key Takeaways

Pods are the smallest units in Kubernetes that run containers together sharing resources.

kubectl is the command-line tool to create and manage Pods by sending instructions to Kubernetes.

You can create Pods quickly with 'kubectl run' or declaratively with YAML files and 'kubectl apply'.

Direct Pod creation is useful for testing but production workloads should use controllers like Deployments for reliability.

Understanding Pod lifecycle, restart policies, and status checks is essential for managing applications effectively.