Intro to Kubernetes

This guide is aimed for people who do not know what kubernetes is, but know what a container and what a virtual machine is.
We will go through the why to kubernetes, and core concepts you need to know, along with a few commands and code snippets to put things into perspective.

Quickstart

Before kubernetes was created, containers were managed within a virtual machine, and one operating system had multiple virtual machines running, each with its own operating system and multiple containers, this method works, but it’s imperative and has its own limitations when we want to handle millions of containers. Google created kubernetes exactly for this usecase.

Kubernetes is used to manage containers, it was mainly created to orchestrate how multiple containers are being handled (networking / run / down..), it does this via multiple abstraction layers, these abstractions follow a hierarchy and are designed to simplify managing containers.

Kubernetes vs. Traditional Virtual Machines (VMs)

Before Kubernetes and containers, the standard for isolation was the Virtual Machine. While both allow you to run multiple applications on a single physical server, they operate at different layers of the stack.

1. Architectural Difference

• Virtual Machines: Each VM includes a full copy of an operating system, the application, and necessary binaries/libraries. This runs on a Hypervisor (like VMware or Hyper-V).
• Kubernetes (Containers): Containers share the host's OS kernel. They only package the application and its dependencies, making them significantly lighter.

2. Side-by-Side Comparison

3. Why the Shift?

In Kubernetes, If a pod fails (we will get to what a pod is), Kubernetes doesn't try to "heal" it; it simply kills it and starts a brand new one. This Self-Healing is the core power of Kubernetes.

Scalability

Scaling a VM-based app usually involves spinning up an entire new server, which is slow. Scaling in Kubernetes involves telling the Deployment to run more replicas, which happens almost instantly.

Resource Utilization

With VMs, you often pay for CPU/RAM that isn't being used because the OS itself is idling. Kubernetes allows you to "bin-pack" containers, squeezing the maximum value out of your AWS EC2 instances by filling up every available gap of memory and CPU.

Core and Abstractions

A simplified Kubernetes abstractions hierarchy looks like this: clusters are the parent component; they contain nodes and nodes contain pods and pods contain containers, but they also contain one special component called the control plane.

Within a cluster we find a control plane and one or multiple nodes, and for each node we have a special component called a kubelet that makes sure every pod within the node is running fine, as for the control plane it’s what we can access via kubectl: a CLI that allows us to access the control plane of kubernetes

Pods are the atomic unit that kubernetes handles, If we make an equivalent to the old model, pods are the equivalent of virtual machines as they have a dedicated IP address.

Within a pod we can run one or multiple containers, which share the same network, and can communicate with each other via localhost for example

Pods live and die within nodes, but they cannot come back to life, they can run on only one node and they are unique to it, they cannot for example run across multiple nodes

Kubernetes needs an environment to be run within such as: minikube which is well known and probably most used, kubeadm (most heavy) or kind (most lightweight)

We can use kubernetes imperatively by managing containers via the cli or we can use it declaratively with YAML (the most common way)

this is an example of a pod definition via YAML:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    app: my-app
spec:
  containers:
  - name: my-container
    image: nginx:1.14.2
    ports:
    - containerPort: 80
      ressources:
          requests: #this section checks for ressources in the pod before starting the container
              memory: "64Mi"
              cpu: "100m" #10% of the cpu
            limits:
                memory: "128Mi"
                cpu: "250m" #25% of the cpu

Mandatory commands kit

run a container inside a pod

kubectl run -f file.pod.yml ## will crash if the container already exist
kubectl apply -f file.pod.yml ## creates the container if not running

view running pods

kubectl get all ##gets all pods
kubecet get pod ## gets all pods

inspect a certain pod (gets networking info, running containers inside..)

kubectl describe pod/my-nginx

Check the logs of a certain pod

kubectl logs pod/my-nginx

shells into a container running inside a pod

kubectl exec pod-name -c container-name -it /bin/sh 

delete a pod

kubectl delete pod/my-nginx

Probes

To ensure a pod is alive, we can check the logs, or use describe, but we can also set this conditionally in the yaml definition of the pod via probes; liveness probes and readiness probes

liveness tells us if the pod is alive and when the pod should restart, and readiness if it’s ready to receive requests

Liveness and readiness probe via http (can be done via other ways such as TCP)

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/e2e-test-images/agnhost:2.40
    args:
    - liveness
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3
    readinessProbe:
        ##same as liveness probe for http

Deployments & ReplicaSets:

Until now, we have focused on Pods. While pods are the smallest unit in Kubernetes, they are "mortal." If a standalone pod crashes or a node fails, the pod is gone. In a production environment, you don't manually recreate pods; you use Deployments.

1. The Updated Hierarchy

Kubernetes uses a layered abstraction to manage your containers:

Cluster → Nodes → Deployment → ReplicaSet → Pods → Containers

• Deployment: The high-level object. It handles updates, rollbacks, and the desired state of your application.
• ReplicaSet: The "enforcer" under the hood. Its only job is to ensure that the exact number of pod replicas you requested are running at all times.

2. Declarative "Magic" (Self-Healing)

Kubernetes is declarative. You don't tell the cluster to "start a pod." You tell the Deployment: "I want 3 replicas of this pod."

If you manually delete a pod belonging to a ReplicaSet, Kubernetes notices the gap (e.g., only 2 pods are running when 3 were requested) and instantly spins up a new one to match your Desired State.

3. Understanding the Deployment YAML

The syntax for a Deployment introduces Selectors and Templates, which act as the "glue" between the deployment and the pods.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: http-echo-app
spec:
  replicas: 2           # Desired number of pod units
  selector:             # How the Deployment finds its Pods
    matchLabels:
      app: http-echo-app
  template:             # The Blueprint for the Pods to be created
    metadata:
      labels:           # These MUST match the selector above
        app: http-echo-app
    spec:
      containers:
        - name: http-echo
          image: hashicorp/http-echo:0.2.3
          args:
            - "-text=Hello from the app!"
            - "-listen=:8080"
          ports:
            - containerPort: 8080

          # ---------- HEALTH CHECKS ----------
          # Liveness: Is the container alive? If not, restart it.
          livenessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5

          # Readiness: Is the app ready to receive traffic?
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            initialDelaySeconds: 3
            periodSeconds: 5

ZERO DOWNTIME DEPLOYMENTS

this is probably kube’s most powerful feature, the ability to rollout older images and create new ones with zero downtime, if you had to do this manually, it’s far more challenging as you will taking down the older release images and manually creating the new ones which will probably cause an outage in the updated service while this process is done, kubernetes does this automatically, via aliases, you can create multiple versions of the app, as long as we have the same alias in common between these files, when using apply, kubectl will terminate the older pods, and create new ones, here is a sample deployment file of our new version of the app that bumps the image to latest

apiVersion: apps/v1
kind: Deployment
metadata:
  name: http-echo-app
  labels:
    app: http-echo-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: http-echo-app
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  template:
    metadata:
      labels:
        app: http-echo-app
    spec:
      containers:
        - name: http-echo
          image: hashicorp/http-echo:latest
          args:
            - "-text=Hello from Kubernetes v2!"
            - "-listen=:8080"
          ports:
            - containerPort: 8080

          readinessProbe:
            httpGet:
              path: /
              port: 8080
            initialDelaySeconds: 2
            periodSeconds: 5

          livenessProbe:
            httpGet:
              path: /
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5

we now only have to run:

kubectl apply -f *echo-v2.deployment.yml*

this will terminate older pods and create new ones with the newer version.

Up until now, all of these deployments are not exposed, we are just checking them running or not, well it’s time to expose these pods and start poking on with http, this can be done via services.

Services: Connecting to your Pods

In Kubernetes, Pods are ephemeral (they die and are replaced). If you tried to connect directly to a Pod's IP address, your connection would break the moment that Pod was recreated.

Services act as a stable "Entry Point" (or a tunnel) that routes traffic to a set of Pods using labels.

1. Service Types: Finding the Right Entry Point

2. Anatomy of a Service

The most important part of a Service is the Selector—this is how the Service knows which Pods to send traffic to.

Example: LoadBalancer

This is ideal for exposing your app to the internet.

apiVersion: v1
kind: Service
metadata:
  name: http-echo-service
spec:
  type: LoadBalancer
  selector:
    app: http-echo-app # Finds Pods with this label
  ports:
    - protocol: TCP
      port: 80         # Port accessible on the LoadBalancer IP
      targetPort: 8080 # Port your Go/Node/Python app is listening on

Now that we have setup our app and exposed it via the service, we have one more thing to worry about: storage. For now if we take down a pod, we loose all the data, since pods are ephemeral, we need a way to link pods to some sort of storage, this can be done via Volumes.

Volumes: Orchestrating Storage in Kubernetes

In Kubernetes, a Volume is a directory accessible to the containers within a pod. Unlike a container's local writable layer—which is destroyed if the container crashes or restarts—volumes allow data to persist and be shared across the pod's lifecycle.

1. Storage Lifecycles

Kubernetes handles the lifecycle of data in two primary ways:

• Ephemeral Storage: Tied strictly to the Pod's lifetime. If the pod is deleted, the data is gone forever.
  • Core Example: emptyDir. Often used as a "scratch pad" for temporary computation or as a shared space between containers in the same pod.
• Persistent Storage: Decoupled from the Pod. If the pod dies or is moved to another node, the volume remains and can be re-attached to a new pod.
  • Core Examples: hostPath (storing data on the node's disk), NFS, or cloud-specific storage like AWS EBS.

2. The Persistence Workflow: PV vs. PVC

To manage persistent storage efficiently, Kubernetes uses an abstraction layer that separates the physical storage from the developer's request.

• PersistentVolume (PV): This is a "physical" resource in the cluster (e.g., a 10GB SSD on AWS). It is provisioned by an administrator or a StorageClass and exists independently of any pod.
• PersistentVolumeClaim (PVC): This is a "request" for storage by a developer. You define the size and access mode, and Kubernetes automatically "binds" it to a matching PV.

Analogy: A PV is a physical hard drive sitting on a shelf. A PVC is a request form for a drive of a certain size. Once the request is fulfilled, the drive is "plugged into" your Pod.

3. Access Modes

When configuring persistent volumes, you must define how they can be mounted:

4. Implementation Example

To use persistent storage, the Pod points to the Claim, not the disk itself. This ensures the application remains portable.

# 1. The Claim: "I need 1GB of storage"
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-storage-claim
spec:
  accessModes: [ "ReadWriteOnce" ]
  resources:
    requests:
      storage: 1Gi
---
# 2. The Pod: "Use the claim named app-storage-claim"
apiVersion: v1
kind: Pod
metadata:
  name: app-server
spec:
  volumes:
    - name: data-volume
      persistentVolumeClaim:
        claimName: app-storage-claim
  containers:
    - name: app-container
      image: nginx
      volumeMounts:
        - mountPath: "/var/www/html"
          name: data-volume