DEV Community: Anushree GM

Kubernetes Made Simple: How It Works Using Real-World Analogies

Anushree GM — Tue, 17 Feb 2026 16:16:25 +0000

What is Kuberenetes?
Kubernetes (often called K8s) is a system for automatically managing applications running in containers.

Let’s understand this using a simple real-world analogy.

Imagine you run a large restaurant chain:

You have many kitchens (servers).
Each kitchen must prepare many dishes (applications).
You want orders to be cooked reliably, even if a cook gets sick (failure).
You want extra cooks added during busy hours (scaling).

Kubernetes is like a smart restaurant manager that:
✔ Assigns orders (workloads) to kitchens
✔ Makes sure dishes are cooked correctly
✔ Adds extra cooks when needed
✔ Reassigns work if a kitchen goes down

So: Kubernetes = container orchestrator + self-healing + auto-scaling + load balancing

Architecture
Kubernetes has two main sides:

1) Control Plane (Brain / Manager)

This is the decision-maker layer.

Using our analogy: Think of it as the CEO and Operations Board Room. They don’t cook — they make decisions.

Control Plane’s jobs:
✔ Decide where containers should run
✔ Monitor application health
✔ Scale apps up/down
✔ Manage configuration

Key components:

API Server — main entry point for commands
Scheduler — decides where workload runs
Controller Manager — ensures desired state
etcd — configuration database

2) Data Plane (Workers / Executors)

This is the execution layer.

Analogy: The chefs in kitchens who actually cook the food following the manager’s instructions

Data Plane’s jobs:
✔ Run containers
✔ Report health
✔ Communicate with Control Plane

Key Components:

Nodes — machines (physical/virtual)
Kubelet — agent on each node
Container Runtime — e.g., Docker
Kube-Proxy — network traffic handler

If you'd like to go deeper into Kubernetes architecture and its components, check out this article: Detailed K8S Architecture

How Control Plane and Data Plane Work Together?

1) Control Plane decides what needs to be cooked and how.
2) Data Plane (chefs) cook the meals.
3) Each chef reports status back to the head manager:

"Dish done"
"Ingredients missing"
"Recipe failed"

4) Manager fixes problems automatically.

In Kubernetes:

Control Plane tells nodes:

“Start these containers”
“Keep these alive”
“Scale more replicas”
“Move them if needed”

Data Plane/Nodes (via Kubelet):

Constantly check if containers are healthy
Report to Control Plane
Execute commands

Kubernetes removes the need for manual infrastructure management.
It ensures applications are always:
Running
Scalable
Resilient
Highly available

This is why Kubernetes has become the industry standard for modern cloud applications.

Kubernetes and it's Architecture

Anushree GM — Fri, 09 Jan 2026 09:47:04 +0000

Kubernetes
Kubernetes is an orchestration system for containers. It doesn’t replace Docker; it manages many Docker containers (or other container runtimes) across multiple machines.

Problems using Docker

Single Host - Imagine 100 containers running, 1 container uses more memory, it affects other container maybe 50th 99th or any because this container does not get enough resources, it may also kill that container based on the priority.
Docker does not provide auto-healing - If container is killed app becomes inaccessible and container has to be started manually
It does not have auto scaling.
Docker does not provide Enterprise support

These issues can be fixed by Kubernetes

Kubernetes Architecture

There are 2 parts
1) Control Plane - API Server, Scheduler, etcd, Control manager, Cloud control manager
2) Data Plane - Kubelet, Kube-proxy, Container Runtime

We'll start with Data plane

1) Container runtime - It is necessary to run containers like java runtime is required to run java applications
Container runtimes for Kubernetes include containerd and CRI-O (Dockershim was deprecated).
2) Kube-proxy - It handles the networking between the containers and services, like sending or distributing requests to pods/nodes i.e., load balancing, it also does assignment of IP addresses
3) Kubelet - It ensures Pods assigned to its node are running and healthy. It communicates with the control plane and uses the container runtime to start containers inside Pods.

Control plane

1) API Server - It is the core component of Kubernetes; it is the front door. All commands go through here. It stores objects (like Pods) and exposes them to other components.
2) Scheduler- It decides which node runs which pod. It watches for Pods that don’t have a node yet (unscheduled pods) evaluates all candidate nodes, and picks the best node based on policies and resource availability.
3) etcd - A key-value store for cluster state (like a database for configs). Entire cluster information is stored in it.
4) Controller manager - Ensures desired state (e.g., if you said 3 replicas, it keeps 3 running).

The flow step-by-step
1) You (or a controller like a Deployment) create a Pod → it’s sent to the API Server.
2) The API Server stores the Pod (in etcd) and marks it as unscheduled (no nodeName).
3) The Scheduler notices the unscheduled Pod, filters nodes that can’t run it, scores the remaining nodes, and binds the Pod to the chosen node via the API Server.
4) The Kubelet on that node sees the bound Pod and starts the containers (via the container runtime).

Ansible Fundamentals Beyond the First Playbook

Anushree GM — Tue, 30 Dec 2025 05:38:00 +0000

This blog continues from my previous Ansible basics blog. If you haven't gone through it yet, I recommed reading it first, where I explained Ansible fundamentals inventory, playbooks, and how to write your first playbook.
Ansible Fundamentals

Variables - The basic inputs of Ansible
Variables are values that can change and are used to make playbooks flexible and reusable.

Instead of hard coding information inside a playbook, we store it in variables. Variables are important because one playbook works for multiple servers and changes are easy and safe

Think of it like: When you build a house, you first decide:

How many rooms?
What color paint?
What type of flooring?

These details can change from one house to another.

Similarly, in ansible:

Server name can change
Port number can change
Software version can change
These changing values are stored in variables.

How to Define Variables in Ansible
1) Inside a Playbook

---
- name: Example of Ansible Variables
  hosts: all
  vars:
    app_name: "MyApp"
    app_port: 8080
  tasks:
    - name: Print application details
      debug:
        msg: "Deploying {{ app_name }} on port {{ app_port }}"

Here, vars: defines variables directly in the playbook. You can reference them using {{ variable_name }}.

2) In Inventory File

[webservers]
server1 ansible_host=192.168.1.10 app_port=8080
server2 ansible_host=192.168.1.11 app_port=9090

3) Using vars_files
You can keep variables in a separate file for better organization

# vars.yml
app_name: "MyApp"
app_port: 8080

4) Passing Extra Variables at Runtime

ansible-playbook site.yml --extra-vars "app_name=MyApp app_port=9090"

Ansible Facts
Ansible facts are pieces of information about the target system that Ansible automatically gathers when running a playbook. These include details like:

IP Addresses
Operating system type and version
Hostname
CPU, memory, and disk information
Facts are collected by the setup module and stored in a dictionary called ansible_facts.

How to Gather Facts
By default, Ansible gathers facts at the start of a playbook run. This is controlled by the gather_facts parameter in the playbook:

- name: Example Playbook
  hosts: all
  gather_facts: yes
  tasks:
    - name: Print OS family
      debug:
        msg: "OS Family is {{ ansible_facts['os_family'] }}"

If you set gather_facts: no, Ansible will skip collecting facts, which can speed up execution when facts are not needed.

Ansible roles
Roles in Ansible are a way to organize playbooks into reusable components. Instead of writing large, monolithic playbooks, roles allow you to break them down into smaller, modular pieces.

Benefits of using roles:

Reusability: Use the same code across multiple projects.
Maintainability: Easier to update and manage.
Scalability: Ideal for large environment.
Standardization: Encourages best practices and consistent structure.

Structure of a role

roles/
  └── myrole/
      ├── tasks/        # Main list of tasks to execute
      ├── handlers/     # Handlers triggered by tasks
      ├── templates/    # Jinja2 templates for configuration files
      ├── files/        # Static files to copy
      ├── vars/         # Variables with higher precedence
      ├── defaults/     # Default variables (lowest precedence)
      └── meta/         # Role metadata (dependencies, author info)

Ansible Galaxy
Ansible Galaxy is a community hub and repository for Ansible content like roles, collections, and plugins. It’s essentially a marketplace where you can download pre-built automation content or share your own. This saves time because you don’t have to write everything from scratch.

1) Install a Role from Galaxy

ansible-galaxy role install geerlingguy.nginx

2) Use Installed Roles in Playbooks

---
- hosts: webservers
  roles:
    - geerlingguy.nginx

3) Create your own role

ansible-galaxy init roles/webserver

This creates the folder we need:

roles/
  └── webserver/
      ├── defaults/
      │   └── main.yml
      ├── files/
      ├── handlers/
      │   └── main.yml
      ├── meta/
      │   └── main.yml
      ├── tasks/
      │   └── main.yml
      ├── templates/
      ├── vars/
      │   └── main.yml
      └── README.md

Converting a Simple Playbook into a Role
Original Playbook:

- hosts: webservers
  tasks:
    - name: Install Apache
      yum:
        name: httpd
        state: present

    - name: Start Apache
      service:
        name: httpd
        state: started

Converted into Role:

# roles/webserver/tasks/main.yml
- name: Install Apache
  yum:
    name: httpd
    state: present

- name: Start Apache
  service:
    name: httpd
    state: started

Playbook using role:

- hosts: webservers
  roles:
    - apache

Getting Started with Ansible: A Beginner’s Guide

Anushree GM — Fri, 19 Dec 2025 07:13:20 +0000

What do you think Ansible is? If you’ve ever wished you could control all your servers the way you control your TV with a single remote, that’s exactly what Ansible does for IT infrastructure. Instead of logging into each machine and running commands manually, Ansible lets you automate everything from one place—like magic!

Why Do We Need It?
Imagine you have 10 servers and need to install the same software on all of them. Doing it one by one would take hours. Ansible solves this by letting you write a simple set of instructions (called a playbook) and apply it to all servers at once. No agents, no complicated setup—just automation made easy.

What is Ansible?
Ansible is an open-source automation tool that helps you manage and configure multiple systems at once without having to log into each machine individually. It’s widely used for configuration management, application deployment, and orchestration.

Key Features

Agentless: No need to install software on managed machines.
Uses YAML: Playbooks are written in a human-readable format.
Idempotent: Running the same playbook multiple times without changing the result after the first time.

In the key features we have mentioned managed machines. What does that exactly mean?

Control Node (or Control Machine) This is the system where Ansible is installed and from which you run your automation tasks (playbooks, ad-hoc commands). It acts as the central point of control.
Managed Nodes (or Managed Machine) These are the target systems that Ansible configures or automates. They don’t need Ansible installed—just connectivity (SSH or WinRM) and basic dependencies like Python.

Passwordless Authentication in Ansible
Before Ansible can manage remote servers, it needs a way to login to them automatically.
This is where passwordless authentication becomes essential.

What is Passwordless Authentication?
Passwordless authentication means logging into the remote server without typing a password evertime.

Instead of using passwords, we use SSH key-based authentication.

A private key stays on the Ansible control node
A public key is copied to managed nodes
When ansible connects, SSH checks the key and allows access automatically.

Why does ansible need Passwordless Authentication?
Ansible is an automation tool.

Imagine this situation:
You run an Ansible playbook on 10 servers. SSH asks for a password for each server
That breaks automation.

How does it work?

1) You generate an SSH key pair on the control node

ssh-keygen

This creates:

Private key: ~/.ssh/id_rsa
Public key: ~/.ssh/id_rsa.pub
Never share your private key.

2) Copy SSH Key to managed node
Use ssh-copy-id to copy the public key:

ssh-copy-id user@remote_server_ip

Example:

ssh-copy-id ubuntu@192.168.2.10

You'll be asked for the password one last time (ubuntu user's password on 192.168.2.10).
This allows ssh-copy-id to append you public key to /home/ubuntu/.ssh/authorized_keys
After this, the server trusts your control node.

3) Test Passwordless login

ssh user@remote_server_ip

If you can login without being prompted for a password, passwordless authentication is working.

Note: Make sure remote server has password login disabled in etc/ssh/sshd_config

Ansible inventory
When working with Ansible, the inventory is the backbone of automation. It’s essentially a list of machines (hosts) that Ansible will manage. Think of it as your address book for servers.

Hosts File
In Ansible, the inventory file is often called the "hosts file"
By default, Ansible looks for this file at:

/etc/ansible/hosts

But you can also create your own custom inventory file, for example:

inventory.ini
hosts.ini
production.ini

Then run ansible like this:

ansible -i inventory.ini all -m ping

Inventory file formats

1) Basic Inventory file

192.168.2.13
192.168.2.14

This tells ansible to manage these two servers.

2) Using Hostnames Instead of IPs

web1.example.com
web2.example.com
db1.example.com

As long as DNS works, Ansible can connect using hostnames.

3) Grouped inventory

[webservers]
web1.example.com
web2.example.com

[dbservers]
db1.example.com
db2.example.com

Groups let you organize servers by role or purpose.
Now you can run tasks only on web servers or only on database servers

Example:

ansible -i inventory.ini webservers -m ping

Ansible Ad-hoc commands
Before writing full playbooks, Ansible allows you to run quick, one-line commands called ad-hoc commands.
Ad-hoc commands are perfect for:

Quick checks
Simple tasks
One-time operations

Basic syntax

ansible <hosts> -m <module> -a "<arguments>"

Examples:

#Testing the connectivity with ping
ansible -i inventory.ini all -m ping

ansible -i inventory.ini web -m shell -a "ls -ltr"

For modules please refer the official documentation of Ansible
Builtin modules

Writing your first Ansible Playbook
A playbook is a YAML file that defines which hosts to target, what tasks to run and in what order.

Playbook Structure
A basic playbook has:

Hosts
Become (optional)
Tasks

First Playbook Example
Create a file called first-playbook.yml


---
- name: Install and start Nginx on all servers
  hosts: webservers
  become: true
  tasks:
    - name: Install nginx
      apt:
        name: nginx
        state: present
        update_cache: yes
    - name: Start nginx service
      service:
        name: nginx
        state: started
        enabled: yes

Explanation
hosts: webservers - Targets the webservers group from inventory
become: true - Runs tasks with sudo

Each task has a name, uses a module and defines the desired state

Run the Playbook

ansible-playbook -i inventory.ini first-playbook.yml

This first playbook is just the beginning - automation gets easier and more powerful with every step forward.

Ready to go beyond the basics? I’ve written a follow‑up to this post that dives deeper into Ansible fundamentals. Check it out here:
Ansible Fundamentals Beyond the First Playbook