1 
2If you work in the software development world, you have surely heard of Kubernetes. But what exactly is it, and why has it become the de-facto standard for managing containerized applications? This guide will take you from the basics to the fundamental concepts, with practical examples and diagrams to help you understand.
3 
4## Before Kubernetes: A Bit of History
5 
6To understand why Kubernetes is so revolutionary, let's take a step back.
7 
81.  **Traditional Deployment**: Initially, applications were run on physical servers. This approach was expensive, difficult to scale, and prone to resource conflicts.
92.  **Virtualized Deployment**: Then came Virtual Machines (VMs). VMs allowed multiple isolated applications to run on the same hardware, improving resource utilization and security. However, each VM runs an entire operating system, consuming a lot of resources.
103.  **Containerized Deployment**: Containers (like Docker) are the next evolution. They share the same host operating system but run isolated processes. They are lightweight, fast to start, and portable.
11 
12Containers solved the portability problem but created another one: how to manage hundreds (or thousands) of containers in a production environment? How to ensure they are always running, can communicate with each other, and scale based on load?
13 
14This is where **Kubernetes** comes in.
15 
16## What is Kubernetes?
17 
18Kubernetes (often abbreviated as **K8s**) is an open-source platform for container orchestration. In simple terms, it automates the deployment, scaling, and management of containerized applications. Created by Google and now maintained by the Cloud Native Computing Foundation (CNCF), Kubernetes has become the go-to tool for anyone working with microservices at scale.
19 
20## The Architecture of a Kubernetes Cluster
21 
22A Kubernetes environment is called a **cluster**. A cluster is composed of a set of machines, called **nodes**, that run our applications. The architecture is divided into two main parts: the Control Plane and the Worker Nodes.
23 
24```mermaid
25graph TD
26    subgraph "Control Plane (Master)"
27        A["API Server"]
28        B["etcd"]
29        C["Scheduler"]
30        D["Controller Manager"]
31    end
32 
33    subgraph "Worker Node 1"
34        E["Kubelet"] --- F["Container Runtime"]
35        G["Kube-proxy"]
36        F --- H["Pod"]
37        F --- I["Pod"]
38    end
39 
40    subgraph "Worker Node 2"
41        J["Kubelet"] --- K["Container Runtime"]
42        L["Kube-proxy"]
43        K --- M["Pod"]
44    end
45 
46    A -- "Communicates with" --> E
47    A -- "Communicates with" --> J
48    User -- "kubectl" --> A
49    C -- "Assigns Pods to Nodes" --> E
50    D -- "Maintains state" --> A
51    A -- "Saves/Reads state" --> B
52```
53 
54### Control Plane
55 
56The Control Plane is the "brain" of the cluster. It makes global decisions (like scheduling) and detects and responds to cluster events. Its main components are:
57 
58-   **API Server (`kube-apiserver`)**: It is the gateway to the cluster. It exposes the Kubernetes API, which is used by users (via `kubectl`), cluster components, and external tools to communicate.
59-   **etcd**: A consistent and highly available key-value database. It stores all cluster data, representing the desired and current state of the system.
60-   **Scheduler (`kube-scheduler`)**: Assigns newly created Pods to an available Worker Node, taking into account resource requirements, policies, and other constraints.
61-   **Controller Manager (`kube-controller-manager`)**: Runs controllers, which are control loops that watch the state of the cluster and work to bring it to the desired state. For example, the `Node Controller` manages nodes, while the `Replication Controller` ensures that the correct number of Pods are running.
62 
63### Worker Node
64 
65Worker Nodes are the machines (physical or virtual) where the applications are actually run. Each node is managed by the Control Plane and contains the following components:
66 
67-   **Kubelet**: An agent that runs on each node. It ensures that the containers described in the Pods are running and healthy.
68-   **Kube-proxy**: A network proxy that manages network rules on the nodes. It allows network communication to the Pods from network sessions inside or outside the cluster.
69-   **Container Runtime**: The software responsible for running containers. Docker is the most famous, but Kubernetes also supports other runtimes like `containerd` and `CRI-O`.
70 
71## Fundamental Kubernetes Objects
72 
73In Kubernetes, everything is represented by **objects**. These objects are "records of intent": once you create an object, Kubernetes constantly works to ensure that it exists and matches the desired state.
74 
75Here are the most important ones:
76 
77### Pod
78 
79The **Pod** is the smallest execution unit in Kubernetes. It represents one or more containers that are run together on the same node, sharing resources like the network and storage.
80 
81Generally, you run only one container per Pod, but in advanced scenarios (like "sidecar containers" for logging or monitoring), you can have more.
82 
83You almost never create Pods directly. You use higher-level abstractions like Deployments.
84 
85### Deployment
86 
87A **Deployment** is the object you will use most often. It describes the desired state for a group of identical Pods. The Deployment controller is responsible for:
88 
89-   Creating and managing a **ReplicaSet** (another object that ensures a specific number of replicas of a Pod are always running).
90-   **Scaling** the number of Pods up or down.
91-   Managing application **updates** in a controlled manner (e.g., *Rolling Update*), without downtime.
92 
93Here is an example YAML file for a Deployment that runs 3 replicas of an NGINX server:
94 
95```yaml
96# nginx-deployment.yaml
97apiVersion: apps/v1
98kind: Deployment
99metadata:
100  name: nginx-deployment
101spec:
102  replicas: 3
103  selector:
104    matchLabels:
105      app: nginx
106  template:
107    metadata:
108      labels:
109        app: nginx
110    spec:
111      containers:
112      - name: nginx
113        image: nginx:1.14.2
114        ports:
115        - containerPort: 80
116```
117 
118### Service
119 
120Pods in Kubernetes are ephemeral: they can be created and destroyed at any time. Each Pod has its own IP address, but this IP is not stable. So, how do we reliably expose our application?
121 
122With a **Service**. A Service is an abstraction that defines a logical set of Pods and a policy for accessing them. It provides a **stable access point** (a virtual IP address and a DNS name) for a group of Pods.
123 
124```mermaid
125graph TD
126    subgraph "Service (nginx-service)"
127        A["ClusterIP: 10.96.0.10"]
128    end
129 
130    subgraph "Pods"
131        B("Pod 1 - IP: 192.168.1.2")
132        C("Pod 2 - IP: 192.168.1.3")
133        D("Pod 3 - IP: 192.168.1.4")
134    end
135 
136    A -- "Selector: app=nginx" --> B
137    A -- "Selector: app=nginx" --> C
138    A -- "Selector: app=nginx" --> D
139 
140    Client -- "Request to nginx-service" --> A
141```
142 
143The Service uses a `selector` based on `labels` to find the Pods to which it should forward traffic.
144 
145Here is how to create a Service for our NGINX Deployment:
146 
147```yaml
148# nginx-service.yaml
149apiVersion: v1
150kind: Service
151metadata:
152  name: nginx-service
153spec:
154  selector:
155    app: nginx
156  ports:
157    - protocol: TCP
158      port: 80
159      targetPort: 80
160  type: ClusterIP # Default - exposes the service only within the cluster
161```
162 
163There are different types of Services:
164- `ClusterIP`: Exposes the service on a cluster-internal IP (default).
165- `NodePort`: Exposes the service on a static port on each Worker Node.
166- `LoadBalancer`: Creates an external load balancer in the cloud provider (e.g., AWS, GCP) and assigns a public IP to the service.
167 
168### Ingress
169 
170A `LoadBalancer` Service is great, but creating one for each service can be expensive. To expose multiple HTTP/HTTPS services to the outside world, you use an **Ingress**.
171 
172An Ingress acts as an "intelligent router" for external traffic. It allows you to define routing rules based on host (e.g., `api.mysite.com`) or path (e.g., `mysite.com/api`).
173 
174```mermaid
175graph LR
176    User -- "mysite.com/api" --> Ingress
177    User -- "mysite.com/ui" --> Ingress
178 
179    subgraph "Cluster"
180        Ingress -- "/api" --> ServiceA("api-service")
181        Ingress -- "/ui" --> ServiceB("ui-service")
182 
183        ServiceA --> PodA1("API Pod 1")
184        ServiceA --> PodA2("API Pod 2")
185 
186        ServiceB --> PodB1("UI Pod 1")
187        ServiceB --> PodB2("UI Pod 2")
188    end
189```
190 
191Here is an example of an Ingress:
192```yaml
193# example-ingress.yaml
194apiVersion: networking.k8s.io/v1
195kind: Ingress
196metadata:
197  name: example-ingress
198spec:
199  rules:
200  - host: mysite.com
201    http:
202      paths:
203      - path: /api
204        pathType: Prefix
205        backend:
206          service:
207            name: api-service
208            port:
209              number: 8080
210      - path: /ui
211        pathType: Prefix
212        backend:
213          service:
214            name: ui-service
215            port:
216              number: 3000
217```
218 
219### Other Useful Objects
220 
221-   **Namespace**: Allows you to create "virtual clusters" inside a physical cluster. Useful for isolating environments (e.g., `development`, `staging`, `production`) or teams.
222-   **ConfigMap and Secret**: To manage configuration data and secrets (like passwords or API keys) decoupled from the container image.
223-   **StatefulSet**: Similar to a Deployment, but specific for stateful applications (like databases) that require stable network identities and persistent storage.
224-   **PersistentVolume (PV) and PersistentVolumeClaim (PVC)**: To manage persistent storage in the cluster.
225 
226## Conclusion
227 
228Kubernetes is an incredibly powerful tool, but its learning curve can be steep. This guide has only scratched the surface, but we hope it has given you a solid understanding of the basic concepts.
229 
230**What to do now?**
231- **Experiment locally**: Install [Minikube](https://minikube.sigs.k8s.io/docs/start/) or [Kind](https://kind.sigs.k8s.io/docs/user/quick-start/) to create a Kubernetes cluster on your computer.
232- **Use `kubectl`**: Familiarize yourself with the `kubectl` command, your main tool for interacting with the cluster. Try creating the NGINX Deployment and Service from this article.
233- **Explore the official tutorials**: The [Kubernetes documentation](https://kubernetes.io/docs/tutorials/) is a fantastic resource full of examples.
234 
235Container orchestration is a fundamental skill in the cloud-native world, and mastering Kubernetes will open up a world of possibilities. Have fun!