Chapter 1

Welcome to your foundational guide to Kubernetes. We will go through the essential concepts in a structured, chapter-by-chapter format. The goal is to give you a solid practical understanding, enabling you to take your own application, containerize it, and deploy it on a Kubernetes cluster. Let’s begin with the absolute fundamentals.

The Core Concepts: Pods and Nodes

Before we can talk about deploying an application, we need to understand the most basic building blocks of a Kubernetes cluster: Nodes and Pods. Everything in Kubernetes is built upon this foundation.

What is a Node?

Think of a Node as a single server or machine in your cluster. It can be a physical machine in a data center or a virtual machine (like a Google Cloud VM or an AWS EC2 instance). Each Node provides the necessary computing resources—CPU, memory, and networking—to run your applications.

A Kubernetes cluster is simply a collection of these Nodes. One Node is typically designated as the Control Plane (or Master Node), which acts as the brain of the cluster, making decisions about where to run things. The other Nodes are called Worker Nodes, and their job is to actually run your applications. For our purposes, you just need to know that your app runs on a Worker Node.

What is a Pod?

This is the most crucial concept to grasp. In the world of Docker, the smallest unit you manage is a container. In Kubernetes, the smallest and most basic deployable object is a Pod.

A Pod is a wrapper around one or more containers.

Smallest Deployable Unit: You don’t deploy containers directly in Kubernetes; you deploy Pods that contain those containers.
Holds Your Application: For a simple web server, you would typically have a Pod that contains a single container running your web server image (e.g., Nginx, or your custom Node.js/Python app).
Shared Environment: All containers within the same Pod share the same network space (they can talk to each other on localhost) and can share the same storage volumes. This is useful for “sidecar” patterns, where a helper container might assist the main application container (e.g., a logging agent).

The most important thing to remember about Pods is that they are ephemeral or mortal. They are not designed to be long-lasting. A Pod can be destroyed for many reasons: the Node it’s on fails, the cluster needs to reschedule it elsewhere, or it simply completes its task. This transient nature is a key reason we need higher-level objects like Deployments, which we’ll cover in the next chapter.

How They Fit Together

It’s a simple relationship: Kubernetes schedules Pods to run on Nodes.

The Control Plane looks at the requirements of a Pod (e.g., “I need 1 CPU and 256MB of RAM”) and finds a Node that has enough available resources to run it.

Here is a simple diagram illustrating this relationship:

+--------------------------------------------------+
|                   KUBERNETES CLUSTER             |
|                                                  |
|  +---------------------+    +------------------+ |
|  |   Control Plane     |    |    Worker Node 1 | |
|  | (The Brain)         |    | +--------------+ | |
|  +---------------------+    | |    Pod A     | | |
|                             | | +----------+ | | |
|                             | | |Container1| | | |
|                             | | +----------+ | | |
|                             | +--------------+ | |
|                             |                  | |
|                             | +--------------+ | |
|                             | |    Pod B     | | |
|                             | | +----------+ | | |
|                             | | |Container2| | | |
|                             | | +----------+ | | |
|                             | +--------------+ | |
|                             +------------------+ |
|                                                  |
|                             +------------------+ |
|                             |    Worker Node 2 | |
|                             | +--------------+ | |
|                             | |    Pod C     | | |
|                             | | +----------+ | | |
|                             | | |Container3| | | |
|                             | | +----------+ | | |
|                             | +--------------+ | |
|                             +------------------+ |
|                                                  |
+--------------------------------------------------+

Check Your Cluster’s Node:

A Minikube cluster has one node which acts as both the control plane and a worker. See it for yourself:
Terminal window
```
    # This command lists all nodes in your cluster
    kubectl get nodes
```
You should see an output like this, with one node named minikube:
```
NAME       STATUS   ROLES           AGE   VERSION
minikube   Ready    control-plane   2m    v1.28.3
```
Create Your First Pod: We will create a simple Pod running the Nginx web server. First, create a file named pod.yaml and paste the following content into it.
pod.yaml
```
apiVersion: v1
kind: Pod
metadata:
    name: my-first-pod
spec:
    containers:
    - name: nginx-container
    image: nginx:1.21.6
```
Now, apply this configuration to your cluster:
Terminal window
```
kubectl apply -f pod.yaml
```

List and Inspect the Pod: You can now see the Pod you created.

# List all pods in the current namespace
kubectl get pods

# See more details about your pod, including which node it's on and its internal IP address
kubectl describe pod my-first-pod

Clean Up: Since Pods are meant to be managed by higher-level objects (as we’ll see in Chapter 2), let’s delete this one manually to finish the exercise.
Terminal window
```
kubectl delete -f pod.yaml
```

This exercise demonstrates the basic workflow of defining a Kubernetes object in a YAML file and applying it to the cluster.

Key Takeaways for Chapter 1

Nodes are the worker machines (VMs or physical servers) that make up the cluster.
Pods are the smallest units that you create and manage in Kubernetes. They run on Nodes.
A Pod contains one or more containers, which share a network and storage environment.
Pods are ephemeral. You should never rely on a single Pod to be available permanently.

This covers the absolute basics of where your code runs. Once you’re comfortable with the idea of Nodes and Pods, let me know you’re ready, and we’ll move on to Chapter 2, where we’ll learn how to reliably run and scale our application using Deployments.