A Student Analogy

Kubernetes can seem complex at first, but by using relatable analogies, we can make it easier to understand. In this blog post, we’ll use the analogy of students (Pods), classrooms (ReplicaSets), and schools (Deployments) to explain Kubernetes concepts. We’ll also explore why the declarative approach (writing down rules) is better than the imperative approach (giving quick commands) for managing your Kubernetes resources.

1. Pods: The Students

In Kubernetes, a Pod is the smallest unit, like a single student in a school. A Pod represents a running process (or a group of tightly coupled processes) in your cluster. Just like a student can carry a backpack with books and supplies, a Pod can run one or more containers that share resources like storage and network.

Example:

Imagine a student named Alice who is part of a classroom. Alice is like a Pod running a single container (her brain) that performs tasks (learning). Here’s what Alice’s Pod definition might look like in YAML:

apiVersion: v1
kind: Pod
metadata:
  name: alice
spec:
  containers:
  - name: brain
    image: student:1.0
    ports:
    - containerPort: 80

This YAML file defines Alice as a Pod running the student:1.0 image (her brain) and listening on port 80 (her ability to communicate).

2. ReplicaSets: The Classrooms

A ReplicaSet ensures that a specific number of identical Pods (students) are always running. Think of a ReplicaSet as a classroom that must always have a certain number of students. If a student leaves (a Pod crashes), the ReplicaSet replaces them with a new student to maintain the desired number.

Example:

Imagine a classroom that must always have 5 students. The ReplicaSet ensures this by monitoring the students and replacing any who leave. Here’s what the ReplicaSet definition might look like:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: classroom-rs
spec:
  replicas: 5
  selector:
    matchLabels:
      role: student
  template:
    metadata:
      labels:
        role: student
    spec:
      containers:
      - name: brain
        image: student:1.0
        ports:
        - containerPort: 80

This ReplicaSet ensures that 5 students (Pods) are always running in the classroom. If one student leaves, the ReplicaSet adds a new one.

3. Deployments: The School

A Deployment is like a school that manages multiple classrooms (ReplicaSets). It ensures that the desired state of the school is maintained, such as upgrading classrooms or rolling back to a previous configuration if something goes wrong.

Example:

Imagine a school that wants to upgrade its students from student:1.0 to student:2.0. The Deployment handles this upgrade by creating a new classroom with the updated students and gradually replacing the old classroom. Here’s what the Deployment definition might look like:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: school-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      role: student
  template:
    metadata:
      labels:
        role: student
    spec:
      containers:
      - name: brain
        image: student:2.0
        ports:
        - containerPort: 80

This Deployment ensures that 3 students (Pods) are running with the student:2.0 image. If the upgrade fails, the Deployment can roll back to the previous version (student:1.0).

4. Imperative vs. Declarative Approaches

Now, let’s talk about how you manage your school (Kubernetes cluster). You can either give quick commands (imperative) or write down rules (declarative). Here’s why the declarative approach is better:

Imperative Approach (Quick Commands):

Imagine you’re the principal of the school, and you shout, “Add a new student to Classroom A!” This is quick but doesn’t leave a record of what you did. If you forget, you might end up with too many or too few students.

Example:

kubectl run alice --image=student:1.0 --port=80

This command creates a Pod imperatively, but it doesn’t document the desired state of your cluster.

Declarative Approach (Writing Down Rules):

Instead of shouting commands, you write down the rules for your school. For example, “Classroom A must always have 3 students.” This ensures that the desired state is documented and reproducible.

Example:

Save the following YAML to student.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: alice
spec:
  containers:
  - name: brain
    image: student:1.0
    ports:
    - containerPort: 80

Apply the rule:

kubectl apply -f student.yaml

This approach ensures that the desired state is version-controlled and easy to reproduce.

5. Why the Declarative Approach is Important

Using the declarative approach is like having a well-documented school policy. Here’s why it’s better:

a. Desired State Management:

Kubernetes is designed to maintain the desired state of your cluster. Writing down rules ensures that the desired state is explicitly defined.

b. Reproducibility:

YAML files can be stored in version control systems (e.g., Git), making it easy to reproduce the same environment across different clusters or teams.

c. Scalability:

As your school grows, managing students with quick commands becomes chaotic. Declarative configurations make it easier to manage complex setups.

d. Rollbacks and Auditing:

If something goes wrong, you can easily roll back to a previous state by reapplying an older YAML file. This is not possible with imperative commands.

e. Collaboration:

YAML files can be shared and reviewed by team members, fostering collaboration and reducing the risk of misconfigurations.

6. Example: Declarative Workflow

Let’s walk through a declarative workflow for managing your school:

1. Create a Classroom (ReplicaSet): Save the following YAML to classroom.yaml:

    apiVersion: apps/v1
    kind: ReplicaSet
    metadata:
      name: classroom-rs
    spec:
      replicas: 3
      selector:
        matchLabels:
          role: student
      template:
        metadata:
          labels:
            role: student
        spec:
          containers:
          - name: brain
            image: student:1.0
            ports:
            - containerPort: 80
   

   Apply the rule:

    kubectl apply -f classroom.yaml
   

2. Upgrade the Students (Deployment): Change the image version in classroom.yaml to student:2.0 and reapply:

    kubectl apply -f classroom.yaml
   

   Kubernetes will perform a rolling update to replace the old students with new ones.

3. Rollback the Upgrade: If something goes wrong, you can rollback to the previous version:

    kubectl rollout undo deployment/school-deployment
   

7. Conclusion

By thinking of Pods as students, ReplicaSets as classrooms, and Deployments as schools, we can better understand how Kubernetes works. While the imperative approach (quick commands) is tempting, the declarative approach (writing down rules) is the best way to manage your Kubernetes resources. It ensures that your infrastructure is version-controlled, reproducible, and easy to manage as it grows.

So, embrace the declarative approach, and let Kubernetes handle the rest. Happy Kuberneting! 🚀

References:

https://kubernetes.io/docs/concepts/workloads/pods/

https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/

https://kubernetes.io/docs/concepts/workloads/controllers/deployment/

https://github.com/aireddy73/Kubernetes