DEV Community: Tejas KP

Kubernetes Demystified: YAML Tutorial for DevOps

Tejas KP — Sat, 29 Aug 2026 14:05:12 +0000

What is YAML?

YAML is a data serialization language, like XML and JSON.

What is a serialization language?

Applications written with different technologies and languages, which have different data structures, can transfer data to each other on a common grid or standard format.

Ex: JSON, YAML, XML.

YAML is not — yet another markup language.

"Human friendly" data serialization standard for all programming languages
Syntax: strict indentation
Store the config file with your code, or in its own git repo.

File extension: .yaml and .yml

YAML Format Compared to Others:

Human readable and intuitive
Line separation & indentation
YAML use cases: Docker Compose files, Docker, Kubernetes, Ansible, Prometheus — a great fit for writing configuration files for all these recent DevOps tools

YAML identification:

Line separation
Indentation

YAML vs XML vs JSON
YAML is a superset of JSON — any valid JSON file is also a valid YAML file.

Basic Syntax of YAML:

Key Value Pairs:

# Comment use
app: user-authentication
port: 9000
version: 1.7

Objects:

By indenting the key value pair and indenting by objects:

microservice:
  app: user-authentication
  port: 9000
  version: 1.7

Lists:

microservice:
  - app: user-authentication
  port: 9000
  version: 1.7

Boolean Values:

microservice:
  - app: user-authentication
  port: 9000
  version: 1.7
  deploy: yes, no, on, off, false, true

More Lists:

microservice:
  - app: user-authentication
    version: [1.7, 2.1, 8.1]   # → string
  port: 9000

Kubernetes YAML Files:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
    - name: nginx-container
      image: nginx
      ports:
        - containerPort: 80
      volumeMounts:
        - name: nginx-vol
          mountPath: /usr/nginx/html

Key value pairs breakdown:

metadata = object
labels = object
spec = object
containers = list of objects
port = list
volumeMounts = list of objects

Kubernetes Demystified: Kubectl & YAML Configuration

Tejas KP — Tue, 25 Aug 2026 14:35:39 +0000

Part 2, we covered the architecture - Control Plane and Worker Nodes. Now let's look at how you actually manage Kubernetes components: through kubectl **and **YAML configuration files.

How to Manage K8s Components:
There are two ways to interact with your cluster's components.

kubectl — the Kubernetes CLI(Imperative):

A very powerful tool that enables direct interaction with the cluster.

kubectl create deployment mydepl
kubectl create statefulset myst
kubectl create service mysvc
kubectl create <objecttype> <instancename>
kubectl delete <objecttype> <instancename>

A very powerful tool that enables direct interaction with the cluster:

kubectl get        (basic information)
kubectl describe    (aggregated detail info)
kubectl logs         (logs of containers)

Limitation:
These commands get unwieldy while creating multiple Pods or components at once.

2. Kubernetes Manifests (Configuration Files-Declarative):

For anything more complex, Kubernetes component files — also called Kubernetes manifests are the better option.

Write the component configuration in a file
Apply the configuration file with kubectl apply
Multiple K8s components can go in one file and be applied with a single apply command
To update: edit the config file and apply again
To delete: delete using the config file

Kubernetes Configuration File: YAML

Kubernetes configuration files are written in YAML, and every one of them has three parts:

metadata
specifications (spec)
status**

A typical flow connects a Deployment → Service → Pod.

Example: Deployment vs Service

Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels: ...
spec:
  replicas: 2
  selector: ...
  template: ...

Service:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector: ...
  ports: ...

Breaking Down the Three Parts:

Declaration — apiVersion and kind tell Kubernetes what type of object this is.
metadata — the object's name and other identifying info (e.g., labels).
spec (specifications) — the desired configuration; attributes here are specific to the kind (a Deployment's spec looks different from a Service's spec).
status — automatically generated and added by Kubernetes; you don't write this yourself

How "status" Actually Works:

This is where Kubernetes' self-healing nature comes from:

If desired state = actual state → all good, pass.
If desired state ≠ actual state → Kubernetes self-heals, working to bring actual state back in line with desired state.
Kubernetes updates this state continuously.
This status information is retrieved from etcd, which holds the current status of every K8s component.

Recap

Use kubectl for quick, one-off, imperative changes.
Use YAML manifests (declarative) for anything real, repeatable, and version-controlled.
Every manifest has metadata, spec, and an auto-managed status.
Kubernetes constantly compares desired vs actual state — that comparison is why self-healing works.

Kubernetes Architecture

Tejas KP — Sun, 23 Aug 2026 03:10:08 +0000

Control Plane (Master) & Worker Nodes

Control Plane components:

API Server
Scheduler
Control Manager
etcd

Worker Node components:

Container Runtime
Kubelet
Kube-proxy

Node Processes

Each node has multiple Pods on it.
3 processes must be installed on every node — used to schedule and manage those Pods.
Nodes are cluster services that actually do the work.

Container Runtime
Examples: Docker, containerd, CRI-O.

containerd is used in worker nodes — it's lightweight in nature.
This should be installed on every node because application Pods need to run containers inside the node.

Kubelet

The process which schedules the Pods and containers underneath is Kubelet.

Kubelet interacts with both the container and the node.
Kubelet starts the Pod with the container inside.
Communication between two nodes is because of Services.
Creation of Pod: Kubelet insures the Pod is always running — if not, it will inform etcd.

Kube-proxy

Kube-proxy forwards the request from Pod to Service.
Makes use of the communication, with load balancing.
Provides networking (container ID, IP address).
Load balancing — basically using IP tables.
It makes sure to send the request to the same machine instead of sending it to others (from same node communications).

So, how do you interact with this cluster?

Schedule the Pod
Monitor
Re-schedule/restart the Pod
Join a new node

Managing processes are done by master nodes (the control plane).

API Server

When you, as a user, want to deploy a new application in a Kubernetes cluster, you interact with the API server using some client — could be UI or CLI.
It's a cluster gateway — it gets the initial request of any update into the cluster, even the queries from the cluster.
It also acts as gatekeeper for authentication.
It means when you want to schedule new Pods, deploy new applications, create new services, or any other components — you have to talk to it first.

Flow: Some request → API server → Validates request → Other processes → Pods

Only one entry point to the cluster.

Scheduler

If you send an API request to schedule a new Pod, it validates the request and hands it over to the Scheduler to start the application Pod on one of the worker nodes.
It's not randomly allocating — Scheduler has an intelligent way of deciding on which specific worker node the Pod will be scheduled.
First it will analyze how much CPU it needs, then which node has the least storage among them — there it will be scheduled.
Scheduler just decides on which node the Pod has to be assigned, but starting the scheduling with containers is done by Kubelet.

Flow: Client → Schedule the Pod → API server → Scheduler → Where to put the Pod → Kubelet

Controller Manager

When Pods die on any node, there must be a way to detect that the node died, then reschedule those Pods as soon as possible.
What Controller Manager does is detect cluster state changes (crashing of Pod) and tries to recover the cluster state as soon as possible.

Flow: Controller manager → Scheduler → Kubelet → Pod recovery

etcd
Only cluster data storage — the cluster brain.

It's a key-value store of a cluster state.
etcd is a cluster brain.
Cluster changes (Pod dies, restarted) get stored.
What resources are available?
Did the cluster state change — cluster health.
Actual application data is not stored here.

Example of Cluster Set-up
2 master nodes
3 worker nodes

Master: much more important, handful of master processes. Worker nodes: higher workload, more resources.

Kubernetes Basics for DevOps Engineers

Tejas KP — Sat, 22 Aug 2026 03:34:13 +0000

Introduction:
Kubernetes can feel overwhelming when you first hear terms like Pods, Services, and Deployments thrown around. In this first post of my Kubernetes series, I’ll break down the fundamentals — what Kubernetes actually solves, and the core building blocks you need to understand before going further.

What is Kubernetes?
Kubernetes is an open-source container orchestration tool, originally developed by Google. It helps manage containerized applications across different environments — physical machines, virtual machines, and cloud environments — which makes it a great fit for hybrid deployment setups.

Why Kubernetes? The Problem It Solves
To understand why Kubernetes exists, look at the trend that led to it:

Applications moved from monolith to microservices.
That shift drastically increased the number of containers teams had to manage.
Managing hundreds of containers by hand became unsustainable — teams needed a proper way to orchestrate them.

Key Features

High Availability — no downtime
Scalability — scale up or down based on load and performance needs
Disaster Recovery — backup and restore built into the ecosystem

Main Kubernetes Components

Pods: Abstraction over containers
Services: Stable networking & communication
Ingress: Routes external traffic into the cluster
ConfigMaps & Secrets: External configuration
Volumes : Data persistence
Deployments & StatefulSets: Replication (stateless vs. stateful)
DaemonSets: One Pod per node, auto-scaled with the cluster

Hey Dev Community — New Here!

Tejas KP — Sat, 22 Aug 2026 02:51:40 +0000

Hey Dev Community! 👋

I’m Tejas, a DevOps Engineer from Bangalore, new to this platform. I work mostly with AWS, Kubernetes, Terraform, and Jenkins, and I’ll be sharing what I pick up along the way — CI/CD, Kubernetes in practice, IaC patterns, and the occasional “here’s what broke and how I fixed it.”

Still learning every day, but happy to share whatever I know — and even happier to learn from you all. Feel free to connect or drop a comment! 🚀