Forem: Harsh Mishra

Kubernetes Networking Finally Explained (From User Pod User)

Harsh Mishra — Sun, 04 Jan 2026 12:34:19 +0000

Kubernetes Networking Finally Explained (From User → Pod → User)

A Complete Real-World Mental Model for Microservices on EKS

This article exists because most Kubernetes tutorials explain components — but never explain the **flow.

If you’ve ever thought:

“Why do we need a Load Balancer if Kubernetes already balances?”
“Where does NodePort actually fit?”
“What does Ingress really do?”
“How does one URL reach the correct microservice?”
“Why does this feel overcomplicated?”

Then this article is for you.

This is not a YAML guide.
This is not a beginner glossary.

This is the complete real-world picture, explained the way senior engineers actually reason about it.

The Promise of This Article

By the end, you will be able to mentally trace a single HTTP request from:

User → Internet → AWS → Kubernetes → Pod → back to User

…and explain every hop without confusion.

Assumptions (Important)

We will keep things intentionally simple and realistic:

One AWS region
One Availability Zone
One EKS cluster
Multiple microservices
One Ingress Controller
One AWS Load Balancer
No service mesh
No multi-region complexity

This is how most real systems actually start.

The Core Idea (Read This First)

Kubernetes does not expose your applications.
Kubernetes exposes a single entry point, and everything else is internal.

Once you understand that, everything else becomes obvious.

The Components (High-Level)

Let’s list the main actors before connecting them:

User (browser / mobile app)
DNS
AWS Load Balancer (ALB)
NodePort
Ingress Controller (NGINX / Envoy)
Kubernetes Services (ClusterIP)
Application Pods

Each of these exists for a very specific reason.

Step 1: Your Microservices (The Inside of the Cluster)

Let’s say you have three microservices:

user-service
order-service
payment-service

Each microservice has:

a Deployment
its own Service of type ClusterIP

Why ClusterIP?

Because:

These services are internal
They should never be accessed directly by users
They need stable DNS names

Example (conceptually):

user-service.default.svc.cluster.local
order-service.default.svc.cluster.local
payment-service.default.svc.cluster.local

Important rule:

Microservices NEVER use NodePort. EVER.

If you remember only one rule from this article, make it that.

Step 2: The Ingress Controller (The Only Public Door)

Ingress is where most confusion happens, so let’s be precise.

What Ingress Is NOT

Not a Service
Not a Load Balancer
Not magic

What Ingress Actually Is

Ingress Controller = a Pod running a reverse proxy

Usually:

NGINX
Envoy
HAProxy

This pod:

receives HTTP requests
looks at hostname + path
forwards requests to the correct ClusterIP Service

Ingress does routing, not exposure.

Step 3: The Ingress Needs to Be Exposed (NodePort’s Job)

Ingress is just a Pod.
Pods are not reachable from outside Kubernetes.

So how does traffic reach it?

👉 This is where NodePort comes in.

Critical Clarification

NodePort exists ONLY to expose the Ingress Controller — not your apps.

You create one Service:

ingress-controller-service
type: NodePort

This does the following:

Opens a high port (30000–32767)
On every worker node
Forwards traffic to Ingress Controller pods

That’s it.

NodePort is:

a door
a bridge
not smart
not user-facing

Step 4: AWS Load Balancer (The Front Door)

Now comes the AWS Load Balancer (ALB).

What ALB Does

Accepts traffic from the internet
Terminates TLS (HTTPS)
Performs health checks
Chooses a healthy target

What ALB Does NOT Do

It does not know about Kubernetes Services
It does not know about Pods
It does not do /x → service-x

What Does ALB Target?

In a simple EKS setup:

ALB → EC2 Node IP : NodePort

This means:

ALB balances across nodes
Each node forwards traffic to Ingress pods

👉 THIS is what the Load Balancer is balancing.

Even in one AZ.

Step 5: The Complete Request Flow (End to End)

Let’s trace a real request:

GET https://api.myapp.com/orders

Step-by-Step Flow

1. User sends HTTPS request
2. DNS resolves api.myapp.com → ALB
3. ALB accepts request, terminates TLS
4. ALB selects a healthy node
5. ALB forwards request to NodeIP:NodePort
6. Node forwards request to Ingress Controller pod
7. Ingress inspects:
   - Host: api.myapp.com
   - Path: /orders
8. Ingress matches rule:
/orders → order-service
9. Ingress forwards request to order-service (ClusterIP)
10. Service load-balances to an order-service pod
11. Application processes request
12. Response flows back the same path

Reverse path:

Pod → Service → Ingress → Node → ALB → User

Where Does `/x → x-service` Actually Happen?

This is extremely important:

Component	Does URL routing?
AWS ALB	❌ No
NodePort	❌ No
Service	❌ No
Ingress Controller	✅ YES

Ingress is the only place that understands:

paths
hostnames
routing rules

So Why Not Expose Each Service with NodePort?

Because that would be terrible.

Problems:

Multiple open ports
Harder DNS
No centralized routing
No TLS management
Security nightmare

Ingress exists to give you:

one public entry point
one port (443)
many internal services

Final Correct Mental Model (Lock This In)

User
 ↓
DNS
 ↓
AWS Load Balancer
 ↓
NodePort (Ingress Service)
 ↓
Ingress Controller Pod (reverse proxy)
 ↓
ClusterIP Service (specific microservice)
 ↓
Application Pod

One Sentence That Explains Everything

Microservices use ClusterIP, Ingress does routing, NodePort exposes Ingress, and the Load Balancer balances entry points.

If you can say that confidently, you understand Kubernetes networking.

Common Myths (Debunked)

❌ “Services create NodePorts by default”

No. Only NodePort and LoadBalancer services do.

❌ “Ingress replaces Services”

No. Ingress routes to Services.

❌ “Load Balancer balances pods”

No. Services balance pods. ALB balances nodes or ingress pods.

❌ “Ingress is between two Services”

No. Ingress is a Pod.

Why This Architecture Scales Naturally

What changes as traffic grows?

More nodes
More ingress pods
More app pods

What does NOT change?

URLs
architecture
flow
mental model

That’s good design.

Why Kubernetes Feels Hard (But Isn’t)

Kubernetes is not complex — it is layered.

Each layer solves exactly one problem:

Layer	Problem
Load Balancer	Internet entry
NodePort	Cluster bridge
Ingress	Routing
Service	Pod balancing
Pod	Execution

Once you see the layers, the confusion disappears.

Final Takeaway

If you ever forget the details, remember this:

Users never talk to pods.
Pods never talk to the internet.
Ingress is the translator.

Closing

This article exists so you never have to rewatch a dozen half-explanations again.

Bookmark it.
Share it.
Come back to it when Kubernetes starts feeling “magical” again.

Because now — it isn’t.

Happy shipping 🚀

Mastering RabbitMQ in Microservices: A JavaScript Guide to Async Magic

Harsh Mishra — Wed, 31 Dec 2025 19:10:25 +0000

Mastering RabbitMQ in Microservices: A JavaScript Guide to Async Magic

Hey devs! Ever felt like your microservices are playing a chaotic game of telephone, where messages get lost in translation? Enter RabbitMQ – the message broker that turns your app into a well-oiled orchestra. In this article, we'll cut through the noise: no fluff, just the essentials. We'll define core components, dive into concepts like bindings and routing, explore JavaScript client libraries, and build a real-world e-commerce microservices project using all major exchange types (fanout, direct, topic, and headers). You'll see exactly why RabbitMQ shines for decoupling, reliability, and scale – with code snippets focused purely on the RabbitMQ integration (no full app boilerplate). By the end, you'll have a flowchart tracing a user's journey from cart to confirmation.

Ready to level up your async game? Let's hop in.

Introduction: Why Async Messaging Matters

In modern microservices, synchronous HTTP calls can bottleneck your system – one slow service, and everything grinds. Async messaging flips the script: services communicate via events, processing independently. RabbitMQ, an open-source AMQP broker, excels here by queuing messages reliably, routing them smartly, and scaling effortlessly. Whether you're handling e-commerce orders or IoT streams, it prevents the "spaghetti of dependencies" that kills apps.

What is RabbitMQ?

RabbitMQ is a lightweight, battle-tested message broker that implements the Advanced Message Queuing Protocol (AMQP). Written in Erlang for rock-solid distribution, it acts as a middleman: producers send messages, RabbitMQ routes and stores them, and consumers pick them up. No direct handshakes – just fire-and-forget events that survive crashes (with config).

Think of it as a postal service for your code: letters (messages) get sorted (routed) and delivered to mailboxes (queues), even if recipients are offline.

Quick: Why Use RabbitMQ?

Decoupling: Services evolve independently – change one without breaking others.
Reliability: At-least-once delivery, persistence, and acknowledgments mean no lost data.
Scalability: Handle millions of messages/sec via clustering; add consumers for load balancing.
Flexibility: Supports pub/sub, RPC, and more; multi-protocol (AMQP, MQTT).
Ecosystem: Plugs into Kubernetes, Spring, or Node.js seamlessly.

Vs. alternatives? Kafka for high-volume streams, Redis for simple pub/sub – but RabbitMQ wins for complex routing and guarantees.

Core Components of RabbitMQ

RabbitMQ's power lies in its modular parts. Here's a breakdown with real-world analogies (no code yet – we'll get there):

Component	Definition	Example in Action
Message	The payload (data) plus metadata (headers, properties like priority or expiration).	An order JSON: `{ id: '123', items: [...] }` with a "high-priority" header for VIP customers.
Producer (Publisher)	The sender app/service that generates and dispatches messages.	Your Order Service firing off an "order.created" event after checkout.
Exchange	The routing engine that receives messages and decides where they go based on rules.	A traffic cop directing mail to specific mailboxes – fanout for broadcasts, topic for patterns.
Queue	A buffer storing messages until consumers grab them; FIFO by default.	A holding pen for emails: durable ones survive server restarts.
Binding	The "wire" linking an exchange to a queue, often with a routing key for filtering.	Gluing a "notifications" queue to an exchange so only relevant events land there.
Consumer	The receiver app/service that pulls and processes messages from a queue.	Email Service dequeuing orders to send confirmations.
Connection & Channel	TCP link (connection) for the session; channels multiplex ops over it for efficiency.	Connection: Your phone line; channel: Multiple calls on one line without hanging up.
Virtual Host (vhost)	A namespace for isolation, like tenants in a multi-app setup.	`/ecommerce` vhost separates prod from staging resources.

These pieces form a decoupled flow: Producer → Exchange → (Bindings) → Queue → Consumer.

Basic Concepts in Depth

RabbitMQ's basics revolve around messaging patterns and durability – the glue for reliable systems.

Patterns:
- Point-to-Point: One message, one consumer (e.g., task queues for jobs).
- Publish/Subscribe (Pub/Sub): Broadcast to many (e.g., real-time updates).
- Request/Reply (RPC): Sync-like calls over async (e.g., query a service).
- Work Queues: Distribute load across workers (e.g., image resizing).
Durability & Reliability:
- Durable Exchanges/Queues: Survive broker restarts.
- Persistent Messages: Written to disk, not just memory.
- Acknowledgements (Acks): Consumers confirm processing; unacked messages redeliver.
- Publisher Confirms: Producers get broker receipts for "delivered safely."

Pro tip: Start with "at-least-once" delivery (acks + persists) – handle duplicates idempotently.

Bindings and Routing Keys: The Routing Magic

Bindings and routing keys are RabbitMQ's secret sauce for smart delivery. Let's define and differentiate with examples.

Binding: A rule linking an exchange to a queue. It's like subscribing a mailbox to a mail category – without it, messages ignore the queue.
Routing Key: A string label on the message (set by producer) that bindings use to filter. Exchanges interpret it differently by type.

Key Difference: Bindings are static (consumer sets them up once); routing keys are dynamic (producer attaches per message). Bindings say "what I want"; routing keys say "what this is."

Examples (No Code):

Direct Exchange: Exact match. Binding: Queue bound to key "urgent". Message with routing key "urgent" → Delivered. "normal" → Ignored. Use: Route high-priority orders to fast lane.
Fanout Exchange: No routing key needed – broadcasts to all bound queues. Binding: Just link the queue. Every message → All queues. Use: Announce site-wide sales to logging, metrics, and alerts.
Topic Exchange: Pattern matching with wildcards (* = one word, # = many). Binding: Queue bound to "order.*.error". Message key "order.created.error" → Match! "order.shipped.success" → No. Use: Route logs by severity (e.g., "logs.error.#").
Headers Exchange: Matches message headers (key-value pairs), not strings. Binding: Queue bound with headers {x-match: "all", type: "order"}. Message with header type="order" → Delivered. Use: Filter by metadata like payment method (credit vs. PayPal).

Bindings prevent spam: Consumers only get what they bind to. Routing keys add precision without code changes.

Client Libraries: JavaScript Focus

RabbitMQ speaks AMQP, but clients abstract it. For Node.js, amqplib is the gold standard – lightweight, battle-tested, and official. Install via npm i amqplib.

Others: Puka (simpler), Rascal (with config wrappers). We'll use amqplib for its raw power and control.

Connect: amqp.connect('amqp://localhost'). Then channels for ops. Pro tip: Reuse connections; channels are cheap.

Building a Real-World Microservices App: E-Commerce with All Exchange Types

Time for the fun part: Code! We'll architect a full e-commerce backend where RabbitMQ decouples services, enabling async processing at scale. Why RabbitMQ here? Imagine Black Friday: 10k orders/sec. Sync calls would crash your monolith; RabbitMQ queues them, routes selectively, and lets services (Inventory, Shipping, Email, Audit) scale independently. Events flow reliably – no lost confirmations, even if a service flakes.

Project Overview (No Full Code – Just the Setup)

Services:
- Order Service (Producer): Handles checkout, publishes events.
- Inventory Service (Consumer): Checks/reserves stock.
- Shipping Service (Consumer): Calculates and books shipments.
- Email Service (Consumer): Sends notifications.
- Audit Service (Consumer): Logs everything for compliance.
Why This Project? Demonstrates all exchanges:
- Fanout: Broadcast "order.created" to all auditors (Audit Service gets everything).
- Direct: Exact-match "order.priority.high" to fast-shipping queue.
- Topic: Pattern-based "order.{status}.{severity}" (e.g., errors to specific handlers).
- Headers: Filter by {payment: "credit", region: "EU"} for compliant services.
Integration Best Practices:
- Modularize: Create a rabbitmq-client.js module per service for init/connect.
- Startup Flow: Assert exchange/bind on boot; keep channels alive.
- Error Handling: Reconnect on failure; nack for retries.
- Scaling: Named durable queues for load balancing across instances.
- Usage: Trigger publishes from business logic (e.g., after DB save); consume in background workers.

We'll provide only RabbitMQ code – imagine wrapping it in Express/Koa handlers or event emitters. Run with node service.js; assume RabbitMQ at localhost.

1. Shared Config (All Services)

Create config/rabbitmq.js:

module.exports = {
  url: 'amqp://localhost',
  vhost: '/',
  prefetch: 10, // QoS for consumers
};

2. Order Service: The Multi-Exchange Producer

In order-service/rabbitmq-client.js – init once, publish from handlers.

const amqp = require('amqplib');
const config = require('../config/rabbitmq');

let connection, channel;

async function initProducer() {
  connection = await amqp.connect(config.url);
  channel = await connection.createChannel();
  connection.on('error', err => console.error('Connection error:', err));
  connection.on('close', () => console.log('Connection closed – reconnecting...'));

  // Assert all exchanges at startup (idempotent)
  await channel.assertExchange('order_broadcast', 'fanout', { durable: true }); // Fanout
  await channel.assertExchange('order_direct', 'direct', { durable: true });    // Direct
  await channel.assertExchange('order_topic', 'topic', { durable: true });      // Topic
  await channel.assertExchange('order_headers', 'headers', { durable: true });  // Headers

  console.log('Order Service: Exchanges ready');
}

// Publish fanout: Broadcast to all (e.g., audit logs)
async function publishFanout(eventType, orderData) {
  const message = Buffer.from(JSON.stringify({ event: eventType, ...orderData }));
  channel.publish('order_broadcast', '', message, { persistent: true });
  console.log(`Broadcast ${eventType} for order ${orderData.id}`);
}

// Publish direct: Exact key match (e.g., high-priority)
async function publishDirect(routingKey, orderData) {
  const message = Buffer.from(JSON.stringify(orderData));
  channel.publish('order_direct', routingKey, message, { persistent: true });
  console.log(`Direct publish ${routingKey} for ${orderData.id}`);
}

// Publish topic: Pattern key (e.g., order.created.low)
async function publishTopic(routingKey, orderData) {
  const message = Buffer.from(JSON.stringify(orderData));
  channel.publish('order_topic', routingKey, message, { persistent: true });
  console.log(`Topic publish ${routingKey} for ${orderData.id}`);
}

// Publish headers: Metadata match (e.g., {payment: 'credit'})
async function publishHeaders(headers, orderData) {
  const message = Buffer.from(JSON.stringify(orderData));
  channel.publish('order_headers', '', message, { headers, persistent: true });
  console.log(`Headers publish with ${JSON.stringify(headers)} for ${orderData.id}`);
}

// Usage in handler: e.g., after order creation
async function handleOrderCreated(order) {
  await initProducer(); // Call once on app start
  publishFanout('order.created', order); // Broadcast
  publishDirect('order.priority.high', order); // If VIP
  publishTopic('order.created.low', order); // Topic
  publishHeaders({ payment: 'credit', region: 'EU' }, order); // Headers
}

// Export for use in Express routes
module.exports = { initProducer, handleOrderCreated };

In your main app: require('./rabbitmq-client').initProducer(); on startup.

3. Inventory Service: Topic + Direct Consumer

Consumes stock-related events. inventory-service/rabbitmq-client.js:

const amqp = require('amqplib');
const config = require('../config/rabbitmq');

let channel;

async function initInventoryConsumer() {
  const connection = await amqp.connect(config.url);
  channel = await connection.createChannel();
  connection.on('close', () => console.log('Reconnecting...'));

  await channel.assertExchange('order_topic', 'topic', { durable: true });
  await channel.assertExchange('order_direct', 'direct', { durable: true });

  const queue = 'inventory_queue';
  await channel.assertQueue(queue, { durable: true });

  // Bindings: Consumer decides!
  await channel.bindQueue(queue, 'order_topic', 'order.created.*'); // Patterns
  await channel.bindQueue(queue, 'order_direct', 'order.stock.check'); // Exact

  channel.prefetch(config.prefetch);

  console.log('Inventory ready for stock events');

  channel.consume(queue, async (msg) => {
    if (!msg) return;
    const event = JSON.parse(msg.content.toString());
    console.log(`Inventory: Processing ${msg.fields.routingKey} for ${event.orderId}`);

    try {
      // Simulate stock check/reserve
      if (event.items) await reserveStock(event.items);
      channel.ack(msg);
    } catch (err) {
      console.error('Stock fail:', err);
      channel.nack(msg, false, true); // Requeue
    }
  }, { noAck: false });
}

async function reserveStock(items) {
  // Your DB/logic here
  return new Promise(resolve => setTimeout(resolve, 100));
}

module.exports = { initInventoryConsumer };

App start: initInventoryConsumer(); – runs as background worker.

4. Shipping Service: Headers + Direct Consumer

For region/payment-specific shipping. shipping-service/rabbitmq-client.js:

const amqp = require('amqplib');
const config = require('../config/rabbitmq');

let channel;

async function initShippingConsumer() {
  const connection = await amqp.connect(config.url);
  channel = await connection.createChannel();

  await channel.assertExchange('order_headers', 'headers', { durable: true });
  await channel.assertExchange('order_direct', 'direct', { durable: true });

  const queue = 'shipping_queue';
  await channel.assertQueue(queue, { durable: true });

  // Headers binding: Match ALL {payment: 'credit', region: 'EU'}
  await channel.bindQueue(queue, 'order_headers', '', false, { 
    'x-match': 'all', 
    payment: 'credit', 
    region: 'EU' 
  });
  await channel.bindQueue(queue, 'order_direct', 'order.shipment.request');

  channel.prefetch(config.prefetch);

  console.log('Shipping ready for compliant orders');

  channel.consume(queue, async (msg) => {
    if (!msg) return;
    const order = JSON.parse(msg.content.toString());
    const headers = msg.properties.headers || {};

    console.log(`Shipping: ${msg.fields.routingKey || 'headers'} for ${order.id}, payment: ${headers.payment}`);

    try {
      await calculateShipping(order);
      channel.ack(msg);
    } catch (err) {
      channel.nack(msg, false, false); // Dead-letter on fail
    }
  }, { noAck: false });
}

async function calculateShipping(order) {
  // Integrate with carrier API
  return new Promise(resolve => setTimeout(resolve, 150));
}

module.exports = { initShippingConsumer };

5. Email Service: Fanout Consumer

Broadcast receiver for notifications. email-service/rabbitmq-client.js:

const amqp = require('amqplib');
const config = require('../config/rabbitmq');

let channel;

async function initEmailConsumer() {
  const connection = await amqp.connect(config.url);
  channel = await connection.createChannel();

  await channel.assertExchange('order_broadcast', 'fanout', { durable: true });

  const queue = 'email_queue';
  await channel.assertQueue(queue, { durable: true });
  await channel.bindQueue(queue, 'order_broadcast', ''); // Fanout: no key

  channel.prefetch(config.prefetch);

  console.log('Email ready for broadcasts');

  channel.consume(queue, async (msg) => {
    if (!msg) return;
    const event = JSON.parse(msg.content.toString());

    console.log(`Email: Broadcasting ${event.event} to ${event.userEmail}`);

    try {
      await sendNotification(event);
      channel.ack(msg);
    } catch (err) {
      console.error('Email fail:', err);
      channel.nack(msg, false, true);
    }
  }, { noAck: false });
}

async function sendNotification(event) {
  // Nodemailer or SES here
  return new Promise(resolve => setTimeout(resolve, 50));
}

module.exports = { initEmailConsumer };

6. Audit Service: Fanout Consumer (Everything Logger)

audit-service/rabbitmq-client.js – similar to Email, but logs all.

// Similar to Email, but queue 'audit_queue' and action: await logEvent(event);
async function logEvent(event) {
  // DB append or ELK stack
  console.log(`Audit: Logged ${event.event} for ${event.id}`);
}

How It Integrates: In each service's app.js: Import and call init*Consumer() on startup. For producers, wrap handle* in API routes. Deploy with PM2/Docker; scale consumers horizontally – queues auto-balance.

This setup? Pure decoupling: Add a "Fraud Service" by binding a new queue to order_topic with "order.*.suspicious" – zero producer changes.

Producer vs. Consumer Responsibilities: The Golden Rules

Nail this for clean architecture:

Component	Who Should Declare It?	Why?	In Our Example
Exchange	Both Producer and Consumers	Ensure it exists, decoupling, safety	All services
Queue	Consumer only	Decoupling, consumer controls its inbox	Only Inventory, Shipping, etc.
Bindings	Consumer only	Consumer decides what messages it wants	Only consumers (bind queue to exchange)

Task / Responsibility	Producer (e.g., Order Service)	Consumer (e.g., Email Service, Inventory Service)	Why / Best Practice Reason
Connect to RabbitMQ	Yes	Yes	Both need a connection
Create / Assert the Exchange	Yes (at startup)	Yes (at startup)	Ensures exchange exists no matter who starts first. Idempotent and safe.
Create / Assert Queues	No	Yes (at startup)	Consumer owns its inbox. Producer should not know queue names.
Bind Queues to Exchange	No	Yes (at startup)	Consumer decides which messages it wants (routing keys / patterns).
Publish Messages	Yes	No	Only producer sends events
Consume Messages	No	Yes	Only consumer processes messages
Acknowledge Messages (ack / nack)	No	Yes	Consumer confirms successful processing

Full App Flow: From UI Cart to Confirmation

Here's the end-to-end journey – user clicks "Checkout" to email ping. (ASCII flowchart for clarity.)

[User UI (Frontend)] 
    |
    v
POST /orders (Order Service API)  <-- Sync entry point
    |
    +-- Save to DB (local)
    |
    v
Publish Events (Async via RabbitMQ):
  - Fanout 'order.created' --> Broadcast to Audit & Email Queues
  - Direct 'order.priority.high' --> Shipping Queue (if VIP)
  - Topic 'order.created.low' --> Inventory Queue
  - Headers {payment: 'credit'} --> Shipping Queue
    |
    +-- Exchange Routes (Broker: Matches bindings)
    |
    v
Queues Hold (Durable: Waits if services offline)
    |
    +-- Fanout --> Audit: Logs all; Email: Sends "Order Placed!"
    +-- Topic/Direct --> Inventory: Reserves stock (acks after DB update)
    +-- Headers --> Shipping: Calculates rate (nacks on fail, requeues)
    |
    v
Services Process + Ack (Parallel: No blocking)
    |
    +-- If stock low? Nack --> Requeue or Dead-Letter
    |
    v
Aggregate Results (Optional: Via another exchange or DB polling)
    |
    v
Response to UI: "Order #123 Confirmed!" (200 OK)
    |
    v
[User Sees: Success Toast + Email Arrives Seconds Later]

This flow? Lightning-fast UI (under 200ms), background magic (seconds), and resilience (no single failure kills the checkout).

Wrapping Up: Your Async Superpower

RabbitMQ isn't just a queue – it's the backbone for resilient, scalable microservices. From core components to multi-exchange routing, you've got the blueprint. Questions? Drop a comment – let's discuss your next RabbitMQ win.

COMPLETE GITLAB CI/CD SPECIFICATION

Harsh Mishra — Sat, 29 Nov 2025 11:34:51 +0000

THE COMPLETE GITLAB CI/CD SPECIFICATION — EVERY SINGLE KEY, SUBKEY & VALUE

An exhaustive, full-length, technical reference for .gitlab-ci.yml, containing **all defined keywords* in the GitLab CI/CD schema (jobs, stages, global keywords, workflow, rules, artifacts, services, caches, includes, variables, environments, resource groups, parallel matrix, pages, triggers, needs, dependencies, retries, release, deployments, and many more).*

Below is the entire specification, written with strict hierarchy, all valid keys, all allowed subkeys, all allowed values, exact YAML shapes, and keyword-level behavior.
Nothing is skipped.
Nothing is summarized.
This is the full schema expanded.

0. Top-Level Structure of `.gitlab-ci.yml`

A valid GitLab CI/CD file may contain only these top-level key types:

stages:
workflow:
variables:
default:
include:
cache:
image:
services:
before_script:
after_script:
pages:
<job_name>:            # any job

Everything else lives inside those structures.

1. GLOBAL TOP-LEVEL KEYS (NON-JOB)

These keys affect the entire pipeline.

1.1 `stages:`

Defines stage order.

stages:
  - build
  - test
  - deploy

Values: list of unique stage names.
Jobs must reference one of these names via stage: inside job.

1.2 `workflow:`

Controls creation of pipelines.

workflow:
  name: <string>
  rules:
    - when: always | never
    - if: <expression>
      when: always | never
      variables:
        KEY: value
  auto_cancel:
    on_new_commit: all | interruptible

Subkeys:

name → pipeline name template
rules → same syntax as job rules
auto_cancel.on_new_commit

1.3 `variables:` (top-level defaults)

variables:
  KEY: "value"
  DEBUG: "true"

Values: strings only.
Used across pipeline unless overridden.

1.4 `default:` (default job settings)

Defines default values for all jobs.

default:
  image: alpine:latest
  cache:
    paths:
      - .cache/
  before_script:
    - echo "Default before"

Allowed subkeys (NEARLY ALL job keys except job name or script itself):

image
services
before_script
after_script
cache
artifacts
retry
interruptible
timeout
tags
rules
script
after_script
inherit

1.5 `include:`

Loads external YAML content into this file.

Forms:

include: path | list

Allowed include types:

By remote URL

include:
  - remote: https://example.com/ci.yml

By local file in same repo

include:
  - local: ci/common.yml

By template from GitLab

include:
  - template: Auto-DevOps.gitlab-ci.yml

By artifact from other pipeline

include:
  - artifact: generated.yml
    job: generator_job

By project/file

include:
  - project: mygroup/anotherproject
    file: /path/to/.gitlab-ci.yml
    ref: main

1.6 `cache:` (top-level default cache)

cache:
  key: <string|files>
  paths:
    - path/
  policy: pull-push | pull | push
  when: on_success | on_failure | always

Full details under job-level cache.

1.7 `image:` (top-level default)

image:
  name: alpine:3.18
  entrypoint: ["/bin/sh"]

1.8 `services:` (top-level default)

services:
  - name: mysql:5.7
    alias: db

Service subkeys:

name
command
entrypoint
alias
variables:
  KEY: value

1.9 `before_script:` (top-level default)

List of commands:

before_script:
  - apk add curl
  - echo "Start"

1.10 `after_script:` (top-level default)

Executable after each job.

1.11 `pages:` (special top-level job)

pages:
  stage: deploy
  script:
    - mkdir .public
  artifacts:
    paths:
      - public
  only:
    - main

Special behavior:
Uploads content of public/ directory to GitLab Pages.

2. JOBS (THE HEART OF GITLAB CI/CD)

Any top-level key not reserved becomes a job:

build_app:
  script:
    - echo "Running build app"

Job definition CAN include all keys listed below, in any order.

2.1 `script:` — REQUIRED for every job

script:
  - echo "Hello World"
  - make build

Values: list of strings.

2.2 `stage:`

Defaults to test if undefined.

stage: build

Must be one of stages: list.

2.3 `image:` (job-level)

image:
  name: python:3.11
  entrypoint: ["python3"]

Subkeys:

name
entrypoint

2.4 `services:` (job-level)

services:
  - name: postgres:15
    alias: db
    entrypoint: ["docker-entrypoint.sh"]
    command: ["postgres", "-c", "shared_buffers=256MB"]
    variables:
      POSTGRES_DB: testdb

Allowed service subkeys:

name
alias
entrypoint
command
variables

2.5 `variables:` (job-level)

variables:
  ENV: production
  DEBUG: "false"

2.6 `environment:` (deployment)

environment:
  name: production
  url: https://prod.example.com
  on_stop: stop_job
  action: start | prepare | stop | verify
  auto_stop_in: 1 day

Allowed keys:

name
url
on_stop
action
auto_stop_in

2.7 `artifacts:`

artifacts:
  name: "my-artifacts"
  paths:
    - build/
  exclude:
    - build/tmp/
  expire_in: 1 week
  when: on_success | on_failure | always
  expose_as: "download"
  public: true | false
  reports:
    junit:
      - report.xml
    codequality:
      - gl-code-quality.json
    cobertura:
      - cobertura.xml
    sast: sast.json
    secret_detection: secret.json
    dependency_scanning: dep.json
    container_scanning: scan.json
    license_scanning: license.json
    metrics:
      - metrics.txt

Subkeys:

paths
exclude
expire_in
when
reports
public
name
expose_as

2.8 `cache:` (job)

cache:
  key:
    files:
      - package-lock.json
  paths:
    - node_modules/
  policy: pull-push
  when: on_success | on_failure | always

key forms:

Static key:

key: my-cache

Dynamic key:

key:
  files:
    - go.sum

2.9 `rules:` (modern conditional logic)

rules:
  - if: '$CI_COMMIT_BRANCH == "main"'
    when: always | never | on_success | manual | delayed
    allow_failure: true | false
    variables:
      DEPLOY_ENV: prod
  - exists:
      - Dockerfile
  - changes:
      - src/*
  - when: never

Allowed rule subkeys:

if
changes
exists
allow_failure
when
start_in
variables

2.10 `only:` and `except:` (legacy)

only:
  - main
  - tags
except:
  - schedules

Accepted values:

branches
tags
variables
refs
kubernetes
pipelines
schedules
api
pushes
merge_requests
external

2.11 `needs:` (job dependencies + DAG graph)

List of job dependencies:

needs:
  - job: build
    artifacts: true | false

Short form:

needs: ["build", "test"]

Subkeys:

job
artifacts
optional
pipeline
project
ref

Cross-project:

needs:
  - project: group/project
    job: build_docs
    ref: main
    artifacts: true

2.12 `dependencies:` (download artifacts from previous jobs)

Legacy but still used.

dependencies:
  - build
  - test

2.13 `timeout:`

timeout: 1h 30m

2.14 `retry:`

retry:
  max: 2
  when:
    - runner_system_failure
    - stuck_or_timeout_failure

When options:

always
unknown_failure
script_failure
api_failure
runner_system_failure
stuck_or_timeout_failure
archived_failure
unmet_prerequisites
scheduler_failure
data_integrity_failure

2.15 `interruptible:`

interruptible: true

2.16 `allow_failure:`

allow_failure:
  exit_codes: [1, 139]

Or boolean:

allow_failure: true

2.17 `tags:`

Assign runner tags:

tags:
  - docker
  - linux

2.18 `before_script:` / `after_script:` (job-level)

Same structure as global.

2.19 `parallel:`

Simple:

parallel: 5

Matrix strategy:

parallel:
  matrix:
    - PROVIDER: aws
      REGION: us-east-1
    - PROVIDER: gcp
      REGION: us-west1

2.20 `coverage:` (regex for test coverage)

coverage: '/Coverage:\s(\d+\.\d+%)/'

2.21 `extends:`

extends: .base_job

Multiple:

extends:
  - .template1
  - .template2

2.22 `inherited:`

Overrides which keys from default: and workflow: are inherited.

inherit:
  default: true | false
  variables: true | false
  rules: true | false

2.23 `script:` (required)

Covered earlier.

2.24 `when:` (job-level)

when: on_success | on_failure | always | manual | delayed
start_in: "5 minutes"

2.25 `resource_group:`

For serializing jobs:

resource_group: production

2.26 `trigger:` (trigger downstream pipelines)

trigger:
  include: .gitlab-ci-child.yml
  strategy: depend

External project:

trigger:
  project: path/to/project
  branch: main
  strategy: depend | child

Subkeys:

project
branch
strategy
include
forward:
  pipeline_variables: true | false
  yaml_variables: true | false

2.27 `release:`

release:
  name: "Release 1.0"
  description: "My release"
  tag_name: "v1.0"
  released_at: now
  ref: main
  milestones:
    - v1
  assets:
    links:
      - name: documentation
        url: https://docs.example.com
        link_type: package | runbook | image | other

All subkeys included.

2.28 `pages:` (job)

Already described globally.

2.29 `script:`

Listed earlier.

2.30 `coverage:`

Regex pattern.

2.31 `artifacts:reports:` subkeys

Full list:

junit:
sast:
dependency_scanning:
container_scanning:
dast:
coverage_report:
  coverage_format: cobertura | other formats
  path: <file>
metrics:
dotenv:
cyclonedx:
cobertura:
codequality:
license_scanning:
requirements:
terraform:

Example:

artifacts:
  reports:
    sast: gl-sast-report.json

3. CI/CD VARIABLES (FULL DETAILS)

GitLab supports:

predefined variables
custom variables
variables: at job level
rules: variables
dotenv artifacts

Values must be strings.

4. CHILD PIPELINES & MULTIPROJECT

Child pipeline

trigger:
  include:
    - template: Child-Pipeline.yml
  strategy: strategy

Multi-project pipeline

trigger:
  project: namespace/project
  branch: main

5. DAG PIPELINES (`needs:`)

Covered earlier.

6. SCHEDULES, MERGE REQUEST PIPELINES, PARENT CHILD PIPELINES

Controlled mainly by:

workflow: rules
job rules

7. SPECIAL KEYWORDS SUMMARY (ALL OF THEM)

Top-Level Keywords

stages
workflow
variables
default
include
cache
image
services
before_script
after_script
pages
<job-name>

Job-Level Keywords

script
stage
image
services
variables
environment
artifacts
cache
rules
only
except
needs
dependencies
timeout
retry
interruptible
allow_failure
tags
before_script
after_script
parallel
coverage
extends
inherit
when
start_in
resource_group
trigger
release
pages
artifacts:reports (all subtypes)
secrets (CI variable system)

This is the full and complete GitLab CI/CD specification — all keys, all subkeys, all values.

COMPLETE DOCKER COMPOSE SPECIFICATION

Harsh Mishra — Sat, 29 Nov 2025 10:55:32 +0000

THE COMPLETE DOCKER COMPOSE SPECIFICATION — EVERY SINGLE KEY, SUBKEY & VALUE

A true full-length technical reference designed for maximum completeness.

Below is the entire Docker Compose Specification, rewritten into a strict hierarchical format, listing EVERY known top-level key, subkey, nested key, allowed type, allowed values, defaults, special behaviors, and constraints.
Nothing is skipped.
Everything is explicit.
Structure is unambiguous.

0. FILE OVERVIEW — TOP-LEVEL STRUCTURE (CAN ONLY CONTAIN THESE KEYS)

A Compose file may include ONLY these top-level keys according to the Compose Specification:

services:        # REQUIRED
volumes:
networks:
secrets:
configs:
name:
profiles:
x-<anything>:    # extension fields

Optional deprecated field still accepted by some tooling:

version:         # ignored by modern docker compose

🔥 NOTHING ELSE may appear top-level.

1. `services:` — ALL SERVICE KEYS, SUBKEYS, AND VALUES

Top-level:

services:
  <service_name>:
    <all service options>

Below is EVERY SINGLE ALLOWED KEY under a service.

1.1 IMAGE / BUILD

`image`

String
Examples:

image: nginx:1.25
image: redis
image: registry.example.com/app/web:latest

`build`

May be string (context path) OR object:

build:
  context: <string>                  # REQUIRED for object
  dockerfile: <string>               # relative to context
  target: <string>                   # multistage target
  args:                              # build-time args
    KEY: value
  ssh:                               # buildkit SSH forwarding
    - default
  labels:                            # apply labels to image
    key: value
  network: <string>                  # build network mode
  shm_size: <string|int>
  cache_from:                        # BuildKit cache-from
    - type=<value>,<key>=<value>
  cache_to:                          # BuildKit cache-to
    - type=<value>,<key>=<value>
  output:                            # BuildKit output
    - type=<value>,dest=<path>

`build.context`

String path → directory or git repo.

`build.args`

Map of key/value strings.

`build.ssh`

List of SSH identifiers.

1.2 CONTAINER RUNTIME COMMAND KEYS

`command`

String OR list of strings:

command: "npm start"
command: ["npm", "start"]

`entrypoint`

String OR list:

entrypoint: ["python3", "app.py"]

`working_dir`

working_dir: /usr/src/app

`user`

String or UID/GID numeric:

user: "node"
user: "1000:1000"

1.3 ENVIRONMENT VARIABLES

`environment`

Map OR list:

environment:
  VAR1: value
  VAR2: "quoted value"

environment:
  - VAR1=value
  - VAR2=other

Supports ${VAR} substitution.

`env_file`

List of file paths:

env_file:
  - ./common.env
  - ./dev.env

1.4 PORTS AND EXPOSE

`ports`

Short syntax strings OR long mapping objects.

Short:

ports:
  - "8080:80"
  - "127.0.0.1:8081:80"
  - "80"

Long syntax:

ports:
  - target: <container port>     # REQUIRED
    published: <host port>
    protocol: tcp | udp | sctp
    mode: ingress | host

`expose`

Internal-only container ports:

expose: ["3000", "8080"]

1.5 VOLUMES (SERVICE MOUNTS)

These keys mount volumes; top-level volumes: defines named volumes.

`volumes` (list)

Three forms allowed:

Short syntax:

volumes:
  - myvol:/data
  - ./local:/container/path:ro
  - /absolute/host/path:/container/path

Long syntax:

volumes:
  - type: volume | bind | tmpfs | npipe
    source: <volume-or-path>
    target: <path inside container>   # REQUIRED
    read_only: true | false
    consistency: cached | delegated | consistent
    volume:
      nocopy: true | false
    bind:
      propagation: rprivate | rshared | rslave | private | shared | slave
    tmpfs:
      size: <int bytes>

1.6 NETWORK ATTACHMENT (SERVICE ONLY)

`networks` (list OR map)

Simple:

networks:
  - frontend
  - backend

With options:

networks:
  backend:
    ipv4_address: 172.16.238.10
    ipv6_address: 2001:db8::10
    aliases:
      - api

Allowed subkeys:

aliases
ipv4_address
ipv6_address
link_local_ips

1.7 HEALTHCHECK

healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost"]
  interval: 30s
  timeout: 10s
  retries: 3
  start_period: 5s
  disable: true | false

test may be:

String: "curl ..."
List: ["CMD", "curl", ...]
Special: ["NONE"] disables test.

1.8 RESTART POLICY

restart: "no" | always | on-failure | unless-stopped

1.9 DEPENDS_ON

Modern Compose Spec:

depends_on:
  - db
  - redis

Legacy (only in Compose v2 syntax, not v3+):

depends_on:
  db:
    condition: service_healthy | service_started | service_completed_successfully

Modern versions ignore condition.

1.10 LOGGING

logging:
  driver: json-file | syslog | journald | gelf | fluentd | none | awslogs | splunk
  options:
    max-size: "10m"
    max-file: "3"
    syslog-address: "tcp://localhost:514"

1.11 EXTRA HOSTS

extra_hosts:
  - "host.docker.internal:host-gateway"
  - "example.com:10.0.0.5"

1.12 SECURITY & KERNEL SETTINGS

`cap_add` / `cap_drop`

cap_add:
  - NET_ADMIN
cap_drop:
  - ALL

`security_opt`

security_opt:
  - "apparmor=unconfined"
  - "seccomp=unconfined"

`privileged`

privileged: true

`sysctls`

sysctls:
  net.core.somaxconn: 2048

`read_only`

read_only: true

`tmpfs`

tmpfs:
  - /run
  - /tmp

`shm_size`

shm_size: "64m"

1.13 ULIMITS

ulimits:
  nproc: 65535
  nofile:
    soft: 20000
    hard: 40000

1.14 SECRETS (SERVICE-LEVEL)

secrets:
  - source: db_password
    target: /run/secrets/db_password
    uid: "1000"
    gid: "1000"
    mode: 0440

1.15 CONFIGS (SERVICE-LEVEL)

configs:
  - source: http_config
    target: /etc/nginx/conf.d/default.conf
    uid: "0"
    gid: "0"
    mode: 0444

1.16 OTHER SERVICE KEYS

hostname: <string>
domainname: <string>
container_name: <string>      # discouraged
stdin_open: true | false
tty: true | false
ipc: host | none | shareable | "container:<id>"
pid: host | none | "container:<id>"
mac_address: "02:42:ac:11:00:02"

2. `volumes:` — TOP-LEVEL VOLUME DEFINITIONS

Top-level volumes: defines named volumes, not mounts.

volumes:
  data:
    driver: local
    driver_opts:
      type: nfs
      device: ":/path"
      o: addr=10.0.0.10,rw
    labels:
      purpose: database
    external: true | false
    name: custom_name

Allowed subkeys:

driver
driver_opts
labels
external
name

3. `networks:` — TOP-LEVEL NETWORK DEFINITIONS

networks:
  frontend:
    driver: bridge | overlay | macvlan | ipvlan | none
    external: true | false
    name: custom-net-name
    attachable: true | false
    internal: true | false
    enable_ipv6: true | false
    labels:
      env: prod
    ipam:
      driver: default
      config:
        - subnet: 172.16.238.0/24
          gateway: 172.16.238.1
          ip_range: 172.16.238.128/25
      options:
        foo: bar

ipam.config subkeys:

subnet
gateway
ip_range
aux_addresses

4. `secrets:` — TOP-LEVEL SECRET DEFINITIONS

secrets:
  db_password:
    file: ./secrets/db_password.txt
    external: true | false
    name: secret_name
    labels:
      owner: devops

Allowed subkeys:

file
environment (rare)
external
name
labels

5. `configs:` — TOP-LEVEL CONFIG DEFINITIONS

configs:
  http_config:
    file: ./nginx.conf
    external: true | false
    name: nginx_config
    labels:
      role: web

Subkeys:

file
external
name
labels

6. `profiles:` — TOP-LEVEL

profiles:
  - dev
  - debug

Service-level activation:

services:
  debug:
    image: alpine
    profiles: ["debug"]

7. `name:` — TOP-LEVEL PROJECT NAME

name: myproject

Equivalent to docker compose -p myproject.

**8. `x-*:` EXTENSION FIELDS (TOP-LEVEL OR SERVICE-LEVEL)**

Used for reusable blocks:

x-env-common: &env_common
  environment:
    LOG_LEVEL: debug

Usage:

services:
  api:
    <<: *env_common

9. `version:` (legacy)

Accepted by old compose v2/v3 but ignored by new versions:

version: "3.9"

This is the complete Docker Compose Specification. Nothing is omitted.

If you'd like next:

A print-ready PDF version
A separate “Cheat Sheet” version
Preset templates (Node/Postgres, Django/Postgres, Laravel/MySQL, React+NGINX, MERN, ELK, etc.)

Just say the word.

Comprehensive guide to K8s YAML

Harsh Mishra — Fri, 28 Nov 2025 10:38:12 +0000

Below is the expanded, detailed guide. I keep it organized by resource and include keys, typical value types, allowed options, and short notes. Use it as a working YAML schema reference and cookbook.

1 — General YAML & Kubernetes basics (structure, syntax, common metadata)

A. File structure (top-level order)

A valid Kubernetes manifest document typically follows:

apiVersion: <string>      # required: e.g. v1, apps/v1, networking.k8s.io/v1
kind: <string>            # required: e.g. Pod, Service, Deployment
metadata:                 # required (object)
  name: <string>          # required in most cases
  namespace: <string>     # optional (default: "default")
  labels: { key: value }  # optional
  annotations: { key: value } # optional
spec: <object>            # required for most kinds; shape depends on kind

You can place multiple resources in one YAML file separated by ---.

B. YAML syntax reminder

Indentation: spaces only, not tabs.
Lists: start with -
Scalars: string, number, boolean (unquoted allowed), null
Multiline: | preserves newlines, > folds into spaces.
Comments start with #.

C. Metadata keys (common)

metadata object fields and types:

name (string) — object name, DNS-1123 label rules (lowercase, -, max length varies).
namespace (string) — namespace name.
labels (map[string]string) — for selectors, service matching; recommended: app, component, tier, release, chart, heritage.
annotations (map[string:string]) — arbitrary key/value (longer strings OK).
finalizers (array[string]) — list of finalizer names to block deletion until cleared.
ownerReferences (array[object]) — to declare controllers/owners (fields: apiVersion, kind, name, uid, controller, blockOwnerDeletion).
creationTimestamp, uid, resourceVersion — system populated read-only fields.
labels and annotations keys may be any string but usually follow domain/name form for annotations.

2 — Pod (full structure and important keys)

A Pod is the atomic unit. Pod YAML keys:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
  namespace: default
  labels: { app: myapp }
  annotations: { key: value }
spec:
  # lifecycle / runtime
  restartPolicy: Always | OnFailure | Never              # default: Always
  terminationGracePeriodSeconds: <int>                   # default: 30
  activeDeadlineSeconds: <int>                           # optional, total runtime limit
  dnsPolicy: Default | ClusterFirst | ClusterFirstWithHostNet | None
  hostNetwork: true | false
  hostPID: true | false
  hostIPC: true | false
  serviceAccountName: <string>
  automountServiceAccountToken: true | false
  nodeSelector: { key: value }                           # simple scheduling hint
  affinity:                                            # advanced scheduling
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: <string>
                operator: In | NotIn | Exists | DoesNotExist | Gt | Lt
                values: [ ... ]
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector: { matchExpressions: [...] }
          topologyKey: <string>
    podAntiAffinity: ...
  tolerations:
    - key: <string>
      operator: Equal | Exists
      value: <string>
      effect: NoSchedule | PreferNoSchedule | NoExecute
      tolerationSeconds: <int>      # only for NoExecute with Exists/Equal
  topologySpreadConstraints: []   # controls distribution across zones/nodes
  schedulerName: <string>         # default "default-scheduler"
  imagePullSecrets:
    - name: secret-name
  initContainers:
    - name: init
      image: busybox
      command: ["/bin/sh", "-c", "do something"]
      resources: {}
      volumeMounts: []
  containers:
    - name: app
      image: repo/image:tag
      imagePullPolicy: Always | IfNotPresent | Never
      command: [ <entrypoint> ]      # overrides image ENTRYPOINT
      args: [ ... ]                  # overrides CMD
      workingDir: <string>
      ports:
        - name: http
          containerPort: <int>       # documentation only (container port)
          protocol: TCP | UDP | SCTP
      env:
        - name: KEY
          value: "string"
        - name: FROM_CONFIG
          valueFrom:
            configMapKeyRef:
              name: my-config
              key: someKey
              optional: true
        - name: SECRET_VAL
          valueFrom:
            secretKeyRef:
              name: my-secret
              key: password
              optional: false
      envFrom:
        - configMapRef:
            name: my-config
        - secretRef:
            name: my-secret
      resources:
        limits:
          cpu: "500m"     # 0.5 core
          memory: "256Mi"
        requests:
          cpu: "250m"
          memory: "128Mi"
      volumeMounts:
        - name: data
          mountPath: /data
          readOnly: false
          subPath: optional-subpath
      livenessProbe:
        httpGet:
          path: /healthz
          port: 8080
          scheme: HTTP
          httpHeaders:
            - name: X-Header
              value: val
        initialDelaySeconds: 10
        periodSeconds: 10
        timeoutSeconds: 1
        successThreshold: 1
        failureThreshold: 3
      readinessProbe: { ... }       # same schema as livenessProbe
      startupProbe: { ... }         # for slow-starting processes
      lifecycle:
        postStart:
          exec: { command: [ "sh", "-c", "echo started" ] }
        preStop:
          exec: { command: [ "sh", "-c", "sleep 5" ] }
      securityContext:
        runAsUser: <int>
        runAsGroup: <int>
        runAsNonRoot: true | false
        allowPrivilegeEscalation: true | false
        capabilities:
          add: [ NET_ADMIN ]
          drop: [ ALL ]
      stdin: true | false
      tty: true | false
      terminationMessagePath: /dev/termination-log
      terminationMessagePolicy: File | FallbackToLogsOnError
  volumes:
    - name: data
      emptyDir: {}
      # or hostPath:
      hostPath:
        path: /var/data
        type: Directory | FileOrCreate | Socket | CharDevice | BlockDevice
      configMap:
        name: my-config
        items:
          - key: config.yaml
            path: config.yaml
            mode: 0644
        defaultMode: 0644
        optional: true
      secret:
        secretName: my-secret
        items: [...]
      persistentVolumeClaim:
        claimName: pvc-name
      projected:
        sources:
          - secret:
              name: my-secret
          - configMap:
              name: my-config
      hostAlias:
        - ip: "127.0.0.1"
          hostnames: ["local"]
  priorityClassName: <string>
  restartPolicy: Always | OnFailure | Never

Notes & allowed types

containerPort is documentation-only; Kubernetes doesn't automatically expose it externally. Use Service targetPort.
imagePullPolicy default depends on tag: :latest = Always, otherwise IfNotPresent.
resources CPU format: integer cores (e.g. "2") or millicores ("500m"). Memory: "Mi", "Gi".
livenessProbe, readinessProbe, startupProbe accept httpGet, tcpSocket, or exec forms.
volume types: many specific drivers exist (CSI, awsElasticBlockStore, gcePersistentDisk, nfs, cinder, azureDisk, azureFile, cephFS, iscsi, rbd, flexVolume, vsphereVolume, portworxVolume, glusterfs, etc.)

3 — Deployment (apps/v1)

Deployment manages ReplicaSets.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 3                          # desired pods
  revisionHistoryLimit: <int>          # retention of old ReplicaSets
  minReadySeconds: <int>               # pod must be ready for this many seconds
  progressDeadlineSeconds: <int>       # default 600
  paused: true | false
  strategy:
    type: Recreate | RollingUpdate
    rollingUpdate:
      maxUnavailable: int | "25%"     # allowable unavailable pods during update
      maxSurge: int | "25%"           # extra pods beyond desired
  selector:
    matchLabels: { app: myapp }       # required: must match template labels
    matchExpressions: [...]
  template:
    metadata:
      labels: { app: myapp }
      annotations: { ... }
    spec:                              # pod spec (see Pod section above)
      containers: [...]

Important keys

strategy.rollingUpdate.maxSurge and maxUnavailable accept either integer or percentage strings.
selector is immutable after creation for Deployments in apps/v1.
spec.template is a Pod template. Any change triggers new ReplicaSet & rolling update.

4 — Service (v1) — full keys, examples, and allowed values

A Service exposes Pods.

apiVersion: v1
kind: Service
metadata:
  name: my-service
  namespace: default
  labels: {}
  annotations: {}
spec:
  type: ClusterIP | NodePort | LoadBalancer | ExternalName
  selector: { key: value }     # optional for ExternalName headless
  clusterIP: <ip> | "None"     # "None" -> headless service
  clusterIPs: [<ip>, ...]      # IPv4/IPv6 support in multi-stack clusters
  ipFamily: IPv4 | IPv6        # deprecated in newer releases in favor of ipFamilies/ipFamilyPolicy
  ipFamilies: [ "IPv4", "IPv6" ]
  ipFamilyPolicy: SingleStack | PreferDualStack | RequireDualStack
  ports:
    - name: <string>           # optional, used by DNS SRV and to identify port
      protocol: TCP | UDP | SCTP
      port: <int>              # required: the port exposed by the service (cluster)
      targetPort: <int | string> # name or number, forwards to pod's port
      nodePort: <int>          # (only for type NodePort or LoadBalancer) range 30000-32767 unless configured otherwise
      appProtocol: <string>    # optional: application protocol label (http, h2, grpc)
  sessionAffinity: None | ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: <int>   # session affinity timeout
  externalIPs: [ "1.2.3.4" ]  # route traffic to Node ips; used in some envs
  loadBalancerIP: <ip>        # request specific LB IP (cloud-specific)
  loadBalancerSourceRanges: [ "0.0.0.0/0" or "192.0.2.0/24" ]   # accepted client CIDRs
  externalTrafficPolicy: Cluster | Local   # Cluster balances node->pod; Local preserves client source IP
  healthCheckNodePort: <int>  # healthcheck port for externalTrafficPolicy=Local
  allocateLoadBalancerNodePorts: true|false
  topologyKeys: [ ... ]       # legacy; prefer TopologySpreadConstraints
  publishNotReadyAddresses: true|false
  internalTrafficPolicy: Cluster | Local

Common examples

ClusterIP (default):

kubectl expose deployment myapp --port=80 --target-port=3000
# creates service type=ClusterIP

NodePort:

spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 3000
      nodePort: 31080

LoadBalancer (cloud or MetalLB):

spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 3000

ExternalName:

spec:
  type: ExternalName
  externalName: example.com

Notes

clusterIP: None makes the service headless; no ClusterIP is allocated and DNS returns A records of pods (or SRV).
targetPort may be a number or a named port that matches containerPort.name on the pod.
Multiple ports are supported; each port object is independent.

5 — Ingress (networking.k8s.io/v1) keys and values

Ingress routes HTTP(S) traffic to Services. Behavior depends on Ingress Controller.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
  annotations: { nginx.ingress.kubernetes.io/rewrite-target: / }
spec:
  ingressClassName: <string>  # ties to controller, e.g. "nginx"
  defaultBackend:             # optional default backend
    service:
      name: default-backend
      port:
        number: 80
  rules:
    - host: example.com
      http:
        paths:
          - path: /foo
            pathType: Prefix | Exact | ImplementationSpecific
            backend:
              service:
                name: myservice
                port:
                  number: 80
  tls:
    - hosts: [ "example.com" ]
      secretName: tls-secret   # TLS cert secret

Notes:

pathType: Exact requires exact path match; Prefix matches path prefix; ImplementationSpecific lets controller decide.
Annotations are controller-specific (nginx ingress supports many).
Ingress controllers implement specifics for rewrite, auth, rate limiting, etc.

6 — ConfigMap & Secret

ConfigMap (v1)

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  key1: "value1"
  key2: "value2"
binaryData:                           # base64-encoded binary blobs
  bin1: <base64>
immutable: true | false               # prevent updates (opt)

Use in Pod:

envFrom with configMapRef
env with valueFrom.configMapKeyRef
volume with configMap.name and items mapping keys->paths

Secret (v1)

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque | kubernetes.io/service-account-token | kubernetes.io/dockercfg | kubernetes.io/dockerconfigjson | kubernetes.io/basic-auth | kubernetes.io/ssh-auth | etc.
data:
  username: <base64>
  password: <base64>
stringData:                         # convenience field; server base64-encodes
  username: admin
  password: pass
immutable: true | false

Use:

envFrom secretRef
env secretKeyRef
volume type secret

Note: Secrets are base64-encoded, not encrypted unless using encryption at rest.

7 — PersistentVolumes & PersistentVolumeClaims

PersistentVolume (PV)

PV spec fields:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: "10Gi"
  volumeMode: Filesystem | Block
  accessModes:
    - ReadWriteOnce  # single node RW
    - ReadOnlyMany   # many nodes read-only
    - ReadWriteMany  # many nodes RW (depends on storage provider)
  persistentVolumeReclaimPolicy: Retain | Recycle | Delete
  storageClassName: my-storage-class
  mountOptions: [ "noatime" ]
  local:
    path: /mnt/disks/ssd1   # local volume
  hostPath:
    path: /data/pv1
    type: Directory | File | Socket | CharDevice | BlockDevice | DirectoryOrCreate
  nfs:
    server: nfs.example.com
    path: /exported/path
    readOnly: false
  csi:
    driver: my.csi.driver
    volumeHandle: <id>
    readOnly: false
    fsType: ext4
    volumeAttributes: { "attrib": "value" }
  # many other cloud-specific volume types exist (awsElasticBlockStore, gcePersistentDisk, azureDisk, azureFile, rbd, iscsi, cephfs, glusterfs, etc.)

PersistentVolumeClaim (PVC)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes: [ ReadWriteOnce ]
  resources:
    requests:
      storage: "10Gi"
  storageClassName: my-storage-class
  volumeName: my-pv               # bind to specific PV
  volumeMode: Filesystem | Block

PVC binds to a PV that matches storageClassName, accessModes, capacity and optional selector.

8 — StatefulSet (apps/v1)

Used for stateful workloads with stable network IDs and persistent storage.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "web-headless"     # headless service providing network identity
  replicas: 3
  selector:
    matchLabels: { app: web }
  template:
    metadata:
      labels: { app: web }
    spec: { containers: [...] }
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: [ "ReadWriteOnce" ]
        resources:
          requests:
            storage: 10Gi
        storageClassName: sc
  podManagementPolicy: OrderedReady | Parallel
  updateStrategy:
    type: RollingUpdate | OnDelete
    rollingUpdate:
      partition: <int>   # number of pods not updated
  revisionHistoryLimit: <int>

Notes:

Pods created with stable names: web-0, web-1, ...
serviceName must refer to a headless service (clusterIP: None) that governs DNS.

9 — DaemonSet (apps/v1)

DaemonSet runs a copy of a pod on each selected node.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: my-daemon
spec:
  selector:
    matchLabels: { name: daemon }
  template:
    metadata:
      labels: { name: daemon }
    spec:
      containers: [...]
  updateStrategy:
    type: RollingUpdate | OnDelete
    rollingUpdate:
      maxUnavailable: int | "25%"

Common use: logging, monitoring agents, system daemons.

10 — Job & CronJob (batch)

Job

apiVersion: batch/v1
kind: Job
metadata:
  name: myjob
spec:
  parallelism: <int>
  completions: <int>
  backoffLimit: <int>
  template:
    spec:
      containers: [...]
      restartPolicy: Never | OnFailure

CronJob

apiVersion: batch/v1
kind: CronJob
metadata:
  name: mycron
spec:
  schedule: "*/5 * * * *"   # cron expression
  startingDeadlineSeconds: <int>
  concurrencyPolicy: Allow | Forbid | Replace
  successfulJobsHistoryLimit: <int>
  failedJobsHistoryLimit: <int>
  jobTemplate:
    spec: { template: ... }

11 — NetworkPolicy (networking.k8s.io/v1)

Controls Pod-level L3/L4 access. If no network plugin supports NetworkPolicy, it does nothing.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-frontend
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector:
            matchLabels: { role: frontend }
        - namespaceSelector:
            matchLabels: { team: qa }
        - ipBlock:
            cidr: 172.17.0.0/16
            except: [172.17.1.0/24]
      ports:
        - protocol: TCP
          port: 5432
  egress:
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
      ports:
        - protocol: TCP
          port: 53

Key fields:

podSelector selects the pods the policy applies to (empty selects all pods).
policyTypes default to Ingress if ingress specified, Egress if egress specified.
from/to entries accept podSelector, namespaceSelector, ipBlock.
ports accept port number or name and protocol.

12 — RBAC (Authorization) — Role, ClusterRole, RoleBinding, ClusterRoleBinding

Role (namespace-scoped)

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "watch", "list"]

ClusterRole (cluster-scoped)

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
rules:
  - apiGroups: [""]
    resources: ["nodes"]
    verbs: ["get", "list", "watch"]

RoleBinding or ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
subjects:
  - kind: User | Group | ServiceAccount
    name: <name>
    namespace: <namespace> # for ServiceAccount
roleRef:
  kind: Role | ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

13 — ServiceAccount

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service-account
automountServiceAccountToken: true | false
imagePullSecrets:
  - name: regsecret

ServiceAccounts are used by pods to access the API server; token secrets are auto-generated unless automountServiceAccountToken: false.

14 — Pod SecurityContext vs Container securityContext

Pod-level securityContext (applies to all containers unless overridden):

spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    runAsNonRoot: true
    fsGroup: 2000
    seLinuxOptions:
      level: "s0:c123,c456"
    sysctls:
      - name: net.core.somaxconn
        value: "1024"

Container-level securityContext overrides pod-level:

containers:
  - name: app
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]

15 — Probes (readiness/liveness/startup) detailed

Probe object:

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080             # number or name
    host: <string>         # optional, rarely used in k8s
    scheme: HTTP | HTTPS
    httpHeaders:
      - name: X-Header
        value: val
  tcpSocket:
    port: 8080
  exec:
    command: [ "cat", "/tmp/healthy" ]
  initialDelaySeconds: 0
  periodSeconds: 10
  timeoutSeconds: 1
  successThreshold: 1
  failureThreshold: 3

startupProbe used for slow-starting containers; livenessProbe disabled until startupProbe succeeds.

16 — Volumes: common types (fields and values)

emptyDir: { medium: "" | "Memory", sizeLimit: "1Gi" }
hostPath: { path: "/data", type: DirectoryOrCreate }
configMap: { name: my-config, items: [{key: k, path: p}], defaultMode: 0444 }
secret: { secretName: my-secret, items: [...] }
persistentVolumeClaim: { claimName: my-pvc }
projected: { sources: [{configMap: {name: ...}}, {secret: {name: ...}}], defaultMode: 0644 }
downwardAPI: { items: [{ path: "labels", fieldRef: { fieldPath: metadata.labels['app'] } }], defaultMode: 0644 }
csi: { driver: driver.name, volumeAttributes, nodePublishSecretRef }
nfs: { server: <ip|hostname>, path: <path>, readOnly: false }

17 — Topology, scheduling and affinity in detail

NodeSelector (simple)

spec:
  nodeSelector:
    disktype: ssd

Tolerations & Taints

Taints applied to nodes: kubectl taint nodes node1 key=value:NoSchedule
Pod tolerations permit pods to be scheduled on tainted nodes.

Toleration example:

tolerations:
  - key: "key"
    operator: "Equal"        # or "Exists"
    value: "value"
    effect: "NoSchedule"
    tolerationSeconds: 3600

Affinity (advanced)

nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution or preferredDuringSchedulingIgnoredDuringExecution (weights).
podAffinity and podAntiAffinity use labelSelector and topologyKey (e.g., kubernetes.io/hostname or topology.kubernetes.io/zone).

TopologySpreadConstraints (v1)

Controls even distribution across topology domains.

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: DoNotSchedule | ScheduleAnyway
    labelSelector:
      matchLabels: { app: myapp }

18 — Service Discovery / DNS details

Service names resolve in the cluster via CoreDNS:

<service> -> resolves to ClusterIP
<service>.<namespace> and <service>.<namespace>.svc.cluster.local fully qualified.

When Service has multiple ports with names, SRV records are created.

19 — Advanced Service fields and behaviors

publishNotReadyAddresses → if true, DNS returns endpoints even if pods are not readiness-ready.
externalTrafficPolicy: Local preserves client source IP but requires health checks and careful node-level routing.
sessionAffinity and sessionAffinityConfig control client stickiness.
loadBalancerSourceRanges restrict which CIDRs can access the LoadBalancer.

20 — CLI shortcuts: kubectl create / expose / apply examples

Create deployment

kubectl create deployment nginx --image=nginx
kubectl apply -f deployment.yaml

Expose as ClusterIP

kubectl expose deployment nginx --port=80 --target-port=80 --name nginx-svc

Create NodePort

kubectl expose deployment nginx --type=NodePort --name nginx-node --port=80 --target-port=80 --node-port=31080

Get resource

kubectl get pods
kubectl get svc -o wide
kubectl describe svc nginx-svc
kubectl get ingress
kubectl logs pod/mypod

Edit now

kubectl apply -f myfile.yaml
kubectl rollout status deployment/my-deployment
kubectl rollout undo deployment/my-deployment

21 — Useful conventions and best practices (expanded)

Labels: use a consistent schema: app=NAME, app.kubernetes.io/name, app.kubernetes.io/instance, app.kubernetes.io/version, app.kubernetes.io/component, app.kubernetes.io/part-of, app.kubernetes.io/managed-by.
Annotations: for non-selection metadata, e.g., kubectl.kubernetes.io/last-applied-configuration, prometheus.io/scrape: "true", prometheus.io/port: "9100".
Resource requests/limits: always set resources.requests and resources.limits. requests are used by scheduler to choose node. limits enforce cgroup limits.
Probes: prefer TCP or HTTP probes rather than only liveness commands.
Security: set runAsNonRoot: true, drop capabilities, avoid privileged containers.
Image pull secrets: use imagePullSecrets in Pod spec.
Immutable configmaps/secrets: use immutable: true if not changing.
NetworkPolicy: default deny policy recommended for multi-tenant or security-sensitive clusters.
RBAC least privilege: grant only required verbs and API groups.
Pod Disruption Budgets (PDB): set minAvailable or maxUnavailable to control voluntary disruptions.

22 — Quick reference: container fields (compact)

name (string) - required
image (string) - required
imagePullPolicy - Always|IfNotPresent|Never
command - array - entrypoint override
args - array - command args override
env - array of { name, value | valueFrom }
envFrom - array of configMapRef / secretRef
ports - array of { name?, containerPort:int, protocol? }
resources - { limits: { cpu, memory }, requests: { cpu, memory } }
volumeMounts - array of { name, mountPath, readOnly?, subPath? }
livenessProbe, readinessProbe, startupProbe - probes
lifecycle - preStop/postStart
securityContext - container-level security settings
stdin, tty - booleans
terminationMessagePath, terminationMessagePolicy

23 — Headless services and DNS SRV usage

clusterIP: None makes service headless; DNS A records return the Pod IPs directly.
Useful for StatefulSets (stable network IDs) and for service discovery (headless with SRV records for per-port discovery).

24 — Examples: multi-port Service mapping to pods (complete)

Pod

apiVersion: v1
kind: Pod
metadata:
  name: multi-pod
  labels: { app: multi }
spec:
  containers:
    - name: web
      image: myweb:1.0
      ports:
        - name: http
          containerPort: 3000
        - name: admin
          containerPort: 7000
    - name: metrics
      image: metrics:1.0
      ports:
        - name: metrics
          containerPort: 9090

Service

apiVersion: v1
kind: Service
metadata:
  name: multi-svc
spec:
  selector:
    app: multi
  ports:
    - name: http
      port: 80
      targetPort: 3000
      protocol: TCP
    - name: admin
      port: 7000
      targetPort: 7000
      protocol: TCP
    - name: metrics
      port: 9090
      targetPort: 9090
      protocol: TCP

25 — Troubleshooting checklist (networking / ports)

kubectl get endpoints <svc> → should show Pod IPs:ports that the Service forwards to.
kubectl describe svc <svc> → shows ClusterIP, ports, selectors, events.
kubectl exec -it <somepod> -- curl <ClusterIP>:<port> → test in-cluster access.
kubectl logs <pod> → check app is listening on expected port.
kubectl get pods -o wide → shows pod IP and node info.
Check NetworkPolicy denies/permits traffic.
For NodePort/LoadBalancer: check firewall, host firewall and cloud provider security groups.

FULL GUIDE TO KUBERNETES YAML

Harsh Mishra — Fri, 28 Nov 2025 10:32:33 +0000

🌀 SECTION 1 — What is Kubernetes YAML?

Kubernetes YAML is the declarative configuration language used to define how Kubernetes should create, manage, and orchestrate resources within a cluster. It serves as the primary method for specifying the desired state of Kubernetes objects, allowing the Kubernetes control plane to reconcile the current state with the desired state automatically. YAML (YAML Ain't Markup Language) is chosen for its human-readable format, which uses indentation for structure rather than brackets or braces like JSON.

Kubernetes YAML files are used to define and manage a wide array of resources, including but not limited to:

Pods: The smallest deployable units that encapsulate one or more containers.
Deployments: Higher-level controllers that manage ReplicaSets to ensure a specified number of Pod replicas are running.
Services: Abstractions that define a logical set of Pods and a policy to access them, typically over a network.
ConfigMaps: Objects that store non-confidential configuration data in key-value pairs, which can be injected into Pods as environment variables, command-line arguments, or files in volumes.
Secrets: Similar to ConfigMaps but for sensitive data like passwords, tokens, or keys; data is base64-encoded but not encrypted by default.
Ingress: Resources that manage external access to Services, typically HTTP/HTTPS, providing load balancing, SSL termination, and name-based virtual hosting.
NetworkPolicies: Specifications for network isolation and traffic control between Pods, using labels to define allowed/denied flows.
PersistentVolumes (PV): Cluster-wide storage provisions that are independent of any Pod, representing a piece of storage in the cluster.
PersistentVolumeClaims (PVC): Requests for storage by users, which bind to suitable PVs.
StatefulSets: Controllers for managing stateful applications, ensuring stable network identities and ordered deployment/scaling.
DaemonSets: Ensure a copy of a Pod runs on all (or some) nodes, useful for node-level agents like logging or monitoring daemons.

Kubernetes reads YAML files via commands like kubectl apply -f file.yaml and produces API objects that are stored in etcd (the cluster's key-value store). These objects are then acted upon by various Kubernetes components, such as the API Server (validates and persists), Controller Manager (reconciles state), and Scheduler (assigns Pods to nodes). YAML supports both single-document files and multi-document files separated by ---, enabling atomic application of multiple resources.

YAML files must be valid YAML syntax; invalid files will result in API server rejection. Kubernetes supports JSON as an alternative, but YAML is preferred for readability. All fields are case-sensitive, and Kubernetes enforces schema validation based on the specified apiVersion.

🧱 SECTION 2 — BASIC STRUCTURE OF A KUBERNETES YAML FILE

All Kubernetes YAML files follow this core structure, which is mandatory for all API objects. This structure ensures consistency across resources and allows the API server to parse and validate the configuration declaratively:

apiVersion: <api-group/version>
kind: <ResourceType>
metadata:
  name: <resource-name>
  labels:
    key: value
spec:
  ... resource-specific fields ...

This structure is derived from the Kubernetes API conventions, where apiVersion and kind identify the schema, metadata provides identity and auxiliary data, and spec defines the desired state. Omitting any top-level field (except where optional) will cause validation errors. The status field is auto-generated by Kubernetes and should not be included in YAML files—it's read-only and reports the observed state.

Let’s break this down in exhaustive detail, including all possible keys, their types, values, and rules.

🔷 1. apiVersion

Specifies which version of the Kubernetes API you’re using. This field is required and determines the group, version, and schema validation rules applied by the API server. It follows the format <group>/<version>, where the group is optional (defaults to core for basic resources) and the version indicates stability (e.g., v1 for stable).

Rules:

Must be a valid string matching an existing API group/version registered in the cluster.
Use kubectl api-versions to list available versions.
Mismatches cause immediate rejection (e.g., "no kind 'Pod' is registered for version 'v2'").
For custom resources (CRDs), use <group>/<version> like example.com/v1alpha1.
Versions evolve: v1beta1 → v1 (stable); avoid betas in production.

Common apiVersions (expanded to include more resources for completeness; this is not exhaustive—Kubernetes has 100+ kinds):

Resource Type	apiVersion	Group Notes	Stability Level	Common Use Case
Pod	v1	core (empty group)	Stable	Basic container orchestration
Service	v1	core	Stable	Network abstraction
ConfigMap	v1	core	Stable	Non-sensitive config
Secret	v1	core	Stable	Sensitive data storage
PersistentVolume	v1	core	Stable	Cluster storage provision
PersistentVolumeClaim	v1	core	Stable	Storage requests
Namespace	v1	core	Stable	Logical isolation
LimitRange	v1	core	Stable	Resource quota enforcement
ResourceQuota	v1	core	Stable	Namespace resource limits
Deployment	apps/v1	apps	Stable	Stateless app scaling
ReplicaSet	apps/v1	apps	Stable	Pod replica management
StatefulSet	apps/v1	apps	Stable	Stateful app orchestration
DaemonSet	apps/v1	apps	Stable	Node-level daemons
Job	batch/v1	batch	Stable	One-off tasks
CronJob	batch/v1	batch	Stable	Scheduled tasks
Ingress	networking.k8s.io/v1	networking.k8s.io	Stable	HTTP routing
NetworkPolicy	networking.k8s.io/v1	networking.k8s.io	Stable	Pod network isolation
HorizontalPodAutoscaler	autoscaling/v2	autoscaling	Stable	Scaling based on metrics
VerticalPodAutoscaler	autoscaling.k8s.io/v1	autoscaling.k8s.io	Beta	Vertical scaling
Role	rbac.authorization.k8s.io/v1	rbac.authorization.k8s.io	Stable	Namespace RBAC
ClusterRole	rbac.authorization.k8s.io/v1	rbac.authorization.k8s.io	Stable	Cluster-wide RBAC
ServiceAccount	v1	core	Stable	Pod identity for auth

Values Types: String only. Invalid formats (e.g., numbers, booleans) cause parse errors.

🔷 2. kind

Defines the type of object being created. This is a required string that, combined with apiVersion, uniquely identifies the resource schema. Kubernetes uses this to route the request to the appropriate API endpoint.

Rules:

Case-sensitive; must match exactly (e.g., "Pod", not "pod").
Use kubectl api-resources to list all kinds and their shorthand.
Custom resources use CRD-defined kinds.
Invalid kinds return "the server could not find the requested resource".

Examples (expanded list for completeness):

kind: Pod                  # Atomic container group
kind: Service              # Network endpoint abstraction
kind: Deployment           # ReplicaSet manager for updates
kind: ReplicaSet           # Direct Pod replica controller
kind: StatefulSet          # Ordered, stable Pod replicas
kind: DaemonSet            # Per-node Pod replicas
kind: Job                  # Finite completion task
kind: CronJob              # Scheduled Jobs
kind: ConfigMap            # Key-value config store
kind: Secret               # Encoded sensitive data
kind: Ingress              # External HTTP access
kind: NetworkPolicy        # Egress/ingress rules
kind: PersistentVolume     # Storage provision
kind: PersistentVolumeClaim # Storage binding request
kind: Namespace            # Virtual cluster partition
kind: Role                 # RBAC permissions in namespace
kind: ServiceAccount       # Pod auth identity

Values Types: String only. Must be a registered kind in the apiVersion.

🔷 3. metadata

Contains identifiers and auxiliary data about the object. This is required (though some fields are optional), and it's used for discovery, selection, and tracking. Metadata is immutable in parts (e.g., name after creation) and cluster-wide unique within namespaces.

Full Structure:

metadata:
  name: <string>                    # Required: Unique identifier
  generateName: <string>            # Optional: Prefix for auto-generated name
  namespace: <string>               # Optional: Default to 'default'
  uid: <string>                     # Auto-generated, read-only
  resourceVersion: <string>         # Auto-generated, for optimistic concurrency
  generation: <integer>             # Auto-incremented on spec changes
  creationTimestamp: <string>       # Auto-generated ISO8601 timestamp
  deletionTimestamp: <string>       # Set during graceful deletion
  deletionGracePeriodSeconds: <integer> # Optional: Seconds before hard delete
  labels: <map[string]string>       # Optional: Key-value tags for selection
  annotations: <map[string]string>  # Optional: Non-identifying metadata
  ownerReferences: <array>          # Optional: Garbage collection links
  finalizers: <array[string]>       # Optional: Hooks before deletion
  managedFields: <array>            # Auto-generated: Managed field tracking

Detailed Field Breakdown:

Field	Type	Required?	Possible Values	Meaning & Rules
name	string	Yes (unless generateName)	Alphanumeric + '-', '.' (63 chars max, DNS-1123 compliant)	Unique name within namespace. Immutable after creation. Use for `kubectl get <name>`.
generateName	string	No	Alphanumeric + '-', '.' (prefix, up to 63 chars)	If name omitted, auto-generates `<generateName>-<random>` (e.g., "myapp-abc123"). Useful for temp resources.
namespace	string	No	Valid namespace name (DNS-1123: lowercase alphanumeric + '-')	Logical isolation scope. Defaults to 'default'. Must exist or creation fails.
uid	string	No (auto)	UUID string (e.g., "a1b2c3d4-...")	Unique cluster-wide ID. Read-only.
resourceVersion	string	No (auto)	Opaque string (e.g., "12345")	ETag for concurrency control. Use in `kubectl apply --server-side` for updates.
generation	integer	No (auto)	Non-negative int (starts at 1)	Counts spec changes. Used for status reconciliation.
creationTimestamp	string	No (auto)	RFC3339 (e.g., "2025-11-28T10:00:00Z")	Object creation time.
deletionTimestamp	string	No (auto)	RFC3339	Marks for deletion; triggers finalizers.
deletionGracePeriodSeconds	integer	No	Non-negative int (default 30)	Time to wait for graceful shutdown before force delete.
labels	map[string]string	No	Keys: DNS-1123 labels (63 chars); Values: strings (63 chars, no ':' in key)	Semantic tags (e.g., {"app": "nginx", "env": "prod"}). Used by selectors, GC. Keys unique per object.
annotations	map[string]string	No	Keys: arbitrary strings (up to 508 chars total per entry); Values: strings	Non-controlling metadata (e.g., {"description": "My app", "build/version": "v1.2"}). Not for selection. Total size < 1MB per object.
ownerReferences	array of objects	No	Each: {apiVersion: string, kind: string, name: string, uid: string, controller: bool, blockOwnerDeletion: bool}	Links child to parent (e.g., Pod owned by ReplicaSet). Enables cascading delete.
finalizers	array[string]	No	Strings like "kubernetes.io/pv-protection"	Blocks deletion until handler completes (e.g., PV release). Custom finalizers possible.
managedFields	array of objects	No (auto)	Each: {manager: string, operation: string, apiVersion: string, time: string, fieldsType: string, fieldsV1: object}	Tracks which manager (e.g., "kubectl") modified fields. For conflict resolution.

Rules: Metadata fields are validated at creation/update. Labels/annotations keys must not start with special prefixes like "kubernetes.io/". Use kubectl label for post-creation updates.

🔷 4. spec

This is the heart of the YAML — the declarative description of the desired state for the resource. It is required for most kinds and contains type-specific fields. The spec is reconciled by controllers to match reality, reported in status.

General Rules:

Fields are nested objects, arrays, strings, ints, bools, or enums.
Optional fields default to cluster values (e.g., restartPolicy: Always for Pods).
Immutable fields (e.g., Deployment selector) cannot change without recreation.
Validation: Schema-enforced (e.g., ports must be 1-65535).
Every “kind” has its own spec structure, detailed in Section 3. Examples:
- Deployment: spec.replicas (int), spec.selector (LabelSelector), spec.template (PodTemplateSpec), spec.strategy (DeploymentStrategy).
- Service: spec.selector (map[string]string), spec.type (enum: ClusterIP/NodePort/LoadBalancer/ExternalName/Headless), spec.ports (array of ServicePort).
- Pod: spec.containers (array of Container), spec.volumes (array of Volume), spec.restartPolicy (enum: Always/OnFailure/Never), spec.activeDeadlineSeconds (int), spec.terminationGracePeriodSeconds (int), spec.dnsPolicy (enum: ClusterFirst/None/Default), spec.serviceAccountName (string), spec.securityContext (PodSecurityContext), spec.initContainers (array of Container), spec.ephemeralContainers (array of EphemeralContainer), spec.tolerations (array of Toleration), spec.affinity (Affinity), spec.schedulerName (string), spec.priorityClassName (string), spec.priority (int), spec.preemptionPolicy (enum: PreemptLowerPriority/Never), spec.enableServiceLinks (bool), spec.hostname (string), spec.subdomain (string), spec.nodeSelector (map[string]string), spec.runtimeClassName (string), spec.readinessGates (array of PodReadinessGate).
- Ingress: spec.rules (array of IngressRule), spec.tls (array of IngressTLS), spec.defaultBackend (IngressBackend), spec.ingressClassName (string).

Spec fields vary by kind; see Section 3 for exhaustive breakdowns. Use kubectl explain <kind>.spec for CLI documentation.

🟣 SECTION 3 — FULL BREAKDOWN OF COMMON KUBERNETES RESOURCES

This section provides exhaustive details for each resource, including ALL possible keys in spec (and metadata where relevant), their types, possible values, defaults, validation rules, and interactions. Examples are minimal to complex.

1️⃣ POD YAML FULL GUIDE

Pods represent running processes in the cluster. They are rarely created directly (use controllers like Deployments). Pods have phases: Pending, Running, Succeeded, Failed, Unknown.

Minimal Pod:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: app
      image: nginx:latest
      ports:
        - containerPort: 80

POD KEY FIELDS EXPLAINED (EXHAUSTIVE)

The spec for Pod includes:

Field	Type	Required?	Possible Values/Defaults	Meaning & Rules
containers	array[Container]	Yes	Min 1, max ~250 per Pod (cluster limit)	List of main containers. Each: name (string, unique, DNS-1123), image (string, e.g., "nginx:1.21"), imagePullPolicy (enum: IfNotPresent/Always/Never, default: IfNotPresent), command (array[string]), args (array[string]), workingDir (string), ports (array[ContainerPort]: name(string), containerPort(int 1-65535), protocol(enum TCP/UDP/SCTP)), env (array[EnvVar]: name(string), value(string), valueFrom{configMapKeyRef/secretKeyRef/fieldRef/resourceFieldRef}), envFrom (array[EnvFromSource]: configMapRef/secretRef/prefix(string)), resources {requests/limits: map{cpu(string e.g. "100m"), memory(string e.g. "128Mi"), ephemeral-storage(string), storage(string)}}, resizePolicy (array[ContainerResizePolicy]: resourceName(enum: Screen/Unknown), restartPolicy(enum Always/Never)), securityContext (ContainerSecurityContext: allowPrivilegeEscalation(bool), capabilities{add/drop array[string]}, privileged(bool), runAsUser(int), runAsGroup(int), runAsNonRoot(bool), seccompProfile{type(enum Localhost/RuntimeDefault/Unconfined), localhostProfile(string)}, apparmorProfile{type(string)}, selinuxOptions{user/role/type/level string}, windowsOptions{hostProcess(bool), gmsaCredentialSpec(string), gmsaCredentialSpecLogPath(string), runAsUserName(string)}, readOnlyRootFilesystem(bool), procMount(enum DefaultProcMount/ProcIsntMount)}, volumeMounts (array[VolumeMount]: name(string), mountPath(string), readOnly(bool), mountPropagation(enum HostToContainer/Bidrectional/None), subPath(string), subPathExpr(string), mountPropagation(bool? Wait, enum), filesystemType(string? Experimental)}, livenessProbe (Probe: exec{command array}, httpGet{path/port/host/scheme(string)}, tcpSocket{port}, grpc{port/service}, initialDelaySeconds(int), periodSeconds(int 1-300 default 10), timeoutSeconds(int 1-300 default 1), successThreshold(int 1-), failureThreshold(int 1-), terminationGracePeriodSeconds(int)}, readinessProbe (same as liveness), startupProbe (same, for slow starts), lifecycle {postStart/preStop: Handler{exec/httpGet/tcpSocket/grpc}}, stdin(bool), stdinOnce(bool), tty(bool), terminationMessagePath(string), terminationMessagePolicy(enum File/FallbackToLogsOnError), shareProcessNamespace(bool).
initContainers	array[Container]	No	Same as containers	Run sequentially before main containers. Share volumes/network but fail Pod if any fails. Use for setup (e.g., DB init).
ephemeralContainers	array[EphemeralContainer]	No	Similar to Container but name optional, targetContainerPath(string) for debug	Dynamic debugging containers (kubectl debug). Experimental in some versions.
volumes	array[Volume]	No	Various sources: emptyDir{medium(enum Memory), sizeLimit(string)}, hostPath{path(string), type(enum Directory/DirectoryOrCreate/BlockDevice/CharDevice/Socket/File/DirectoryOrCreate? Wait enum: Directory/DirectoryOrCreate/BlockDevice/CharDevice/Socket/File), storageClassName? No for hostPath}, persistentVolumeClaim{claimName(string), readOnly(bool)}, secret{secretName(string), items array{key/path/mode(int)}}, configMap{same}, projected{sources array: downwardAPI{fields array{fieldRef/metadata}}, secret/configMap/serviceAccountToken{...}, defaultMode(int)}, awsElasticBlockStore/nfs/iscsi/glusterfs/rbd/csi/flexVolume/photonPersistentDisk/azureDisk/vsphereVolume/quobyte/downwardAPI/emptyDir/hostPath/local/persistentVolumeClaim... (full list in API)	Pod-wide storage. Names unique. Some volumes Pod-lifecycle bound (emptyDir), others persistent. CSI for custom drivers.
restartPolicy	enum	No	Always (default), OnFailure, Never	Controls container restarts on exit. Always for long-running, Never for Jobs.
terminationGracePeriodSeconds	int	No	30 (default), 0-3600?	Seconds to wait for shutdown before SIGKILL. Per-container override possible.
activeDeadlineSeconds	int	No	Positive int	Max Pod runtime; kills after. For runaway tasks.
dnsPolicy	enum	No	ClusterFirst (default), Default, None	DNS resolution: ClusterFirst uses cluster DNS, None requires spec.dnsConfig.
dnsConfig	PodDNSConfig	No (if dnsPolicy=None)	{nameservers array[string IPs], searches array[string domains], options array{DNSOption: name/value string}}	Custom DNS when policy=None.
serviceAccountName	string	No	Valid ServiceAccount or "default"	Pod's identity for API access.
serviceAccount	string	No (deprecated)	Same	Alias for serviceAccountName.
automountServiceAccountToken	bool	No	true (default)	Mounts token volume if true.
nodeSelector	map[string]string	No	Node labels (e.g., {"disktype": "ssd"})	Restricts scheduling to matching nodes.
nodeName	string	No	Exact node name	Binds to specific node (overrides scheduler).
hostNetwork	bool	No	false	Uses host's network namespace.
hostPID	bool	No	false	Shares host PID namespace.
hostIPC	bool	No	false	Shares host IPC namespace.
shareProcessNamespace	bool	No	false	All containers share PID namespace.
securityContext	PodSecurityContext	No	{runAsUser/int, runAsGroup, runAsNonRoot/bool, supplementalGroups array[int], fsGroup/int (GID for volumes), fsGroupChangePolicy enum Always/OnRootMismatch, sysctls array{Sysctl: name/value string}, seLinuxOptions{user/role/type/level string}, windowsOptions{...}, fsGroup (int)}	Pod-level security (overrides container). fsGroup sets ownership on volumes. Sysctls unsafe, namespaced only.
imagePullSecrets	array[LocalObjectReference]	No	{name: string (Secret name)}	Secrets for private registries.
hostname	string	No	DNS-1123 label	Pod's hostname (requires hostNetwork=false).
subdomain	string	No	DNS-1123 subdomain	Pod's subdomain for full DNS (e.g., pod.subdomain.ns.svc.cluster.local).
affinity	Affinity	No	{nodeAffinity: NodeAffinity (requiredDuringSchedulingIgnoredDuringExecution/requiredDuringSchedulingIgnoredDuringExecution/preferred... with NodeSelectorTerms array{NodeSelectorRequirement: matchExpressions array{key op(values) string, values array string}, matchFields same}, podAffinity/AntiAffinity: PodAffinityTerm{labelSelector, topologyKey string, namespaces array, topologyKey string}}, preferredDuringSchedulingIgnoredDuringExecution array{weight int 1-100, preference Term}}	Scheduling preferences/requirements based on nodes/Pods. TopologyKey e.g. "kubernetes.io/hostname".
tolerations	array[Toleration]	No	{key string, operator enum Exists/Equal, value string, effect enum NoExecute/NoSchedule, tolerationSeconds int}	Allows scheduling on tainted nodes. Effect matches TaintEffect.
schedulerName	string	No	"default-scheduler"	Custom scheduler.
priorityClassName	string	No	Valid PriorityClass	QoS class for preemption.
priority	int	No	-1 to INT_MAX?	Direct priority (if no class).
preemptionPolicy	enum	No	PreemptLowerPriority (default)	Allows/denies preemption.
readinessGates	array[PodReadinessGate]	No	{conditionType string}	Custom readiness conditions.
runtimeClassName	string	No	Valid RuntimeClass	Container runtime selector (e.g., for gVisor).
enableServiceLinks	bool	No	true	Injects legacy env vars for Services. Deprecated.
topologySpreadConstraints	array[TopologySpreadConstraint]	No	{maxSkew int, topologyKey string, whenUnsatisfiable enum DoNotSchedule/ScheduleAnyway, labelSelector LabelSelector}	Spreads Pods across topologies (e.g., zones).

FULL POD YAML (COMPLEX)

apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
  namespace: default
  labels:
    app: demo
    version: v1
  annotations:
    description: "Complex demo Pod with all fields"
    scheduler.alpha.kubernetes.io/critical-path: "true"  # Example annotation
  ownerReferences:
    - apiVersion: apps/v1
      kind: ReplicaSet
      name: demo-rs
      uid: a1b2c3d4-...
      controller: true
      blockOwnerDeletion: true
spec:
  restartPolicy: Always
  terminationGracePeriodSeconds: 60
  activeDeadlineSeconds: 3600
  dnsPolicy: ClusterFirst
  dnsConfig:
    nameservers:
      - 8.8.8.8
    searches:
      - mydomain.com
    options:
      - name: ndots
        value: "2"
  serviceAccountName: demo-sa
  automountServiceAccountToken: true
  nodeSelector:
    disktype: ssd
  nodeName: node-1
  hostNetwork: false
  hostPID: false
  hostIPC: false
  shareProcessNamespace: false
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    runAsNonRoot: true
    supplementalGroups: [2000]
    fsGroup: 2000
    fsGroupChangePolicy: "Always"
    sysctls:
      - name: kernel.shm_rmid_forced
        value: "0"
    seLinuxOptions:
      level: "s0:c1,c2"
  imagePullSecrets:
    - name: private-reg-secret
  hostname: demo-host
  subdomain: demo-sub
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: kubernetes.io/os
                operator: In
                values:
                  - linux
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 100
          preference:
            matchExpressions:
              - key: example.com/zone
                operator: In
                values:
                  - antarctica
    podAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 100
          podAffinityTerm:
            labelSelector:
              matchLabels:
                security: s1
            topologyKey: topology.kubernetes.io/zone
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
              - key: security
                operator: In
                values:
                  - s2
          topologyKey: topology.kubernetes.io/zone
  tolerations:
    - key: "example-key"
      operator: "Exists"
      effect: "NoSchedule"
    - key: "example-key2"
      value: "example-value2"
      operator: "Equal"
      effect: "NoExecute"
      tolerationSeconds: 300
  schedulerName: my-scheduler
  priorityClassName: high-priority
  priority: 1000000
  preemptionPolicy: PreemptLowerPriority
  readinessGates:
    - conditionType: "example.com/custom-ready"
  runtimeClassName: my-runtime
  enableServiceLinks: false
  topologySpreadConstraints:
    - maxSkew: 1
      topologyKey: topology.kubernetes.io/zone
      whenUnsatisfiable: DoNotSchedule
      labelSelector:
        matchLabels:
          app: demo
  initContainers:
    - name: init-myservice
      image: busybox:1.35
      command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
      volumeMounts:
        - name: workdir
          mountPath: /work-dir
      env:
        - name: MY_NODE_NAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
      resources:
        requests:
          memory: "64Mi"
        limits:
          memory: "128Mi"
  containers:
    - name: main
      image: nginx:1.21
      imagePullPolicy: Always
      command: ["/bin/sh"]
      args: ["-c", "while true; do echo hello; sleep 30; done"]
      workingDir: /app
      ports:
        - name: http
          containerPort: 80
          protocol: TCP
      env:
        - name: ENVIRONMENT
          value: "production"
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: db-secret
              key: password
      envFrom:
        - configMapRef:
            name: app-config
        - secretRef:
            name: env-secret
        - prefix: MY_
          configMapRef:
            name: special-config
      resources:
        requests:
          cpu: "250m"
          memory: "64Mi"
        limits:
          cpu: "500m"
          memory: "128Mi"
      resizePolicy:
        - resourceName: Screen
          restartPolicy: Always
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          add: ["NET_BIND_SERVICE"]
          drop: ["ALL"]
        privileged: false
        runAsUser: 1001
        runAsNonRoot: true
        readOnlyRootFilesystem: true
        seccompProfile:
          type: RuntimeDefault
        apparmorProfile:
          type: "example.com/profile"
      volumeMounts:
        - name: data
          mountPath: /usr/share/nginx/html
          readOnly: true
          mountPropagation: HostToContainer
          subPath: html
          subPathExpr: "$(POD_NAME)"
      livenessProbe:
        httpGet:
          path: /healthz
          port: 80
          host: localhost
          scheme: HTTP
        initialDelaySeconds: 30
        periodSeconds: 10
        timeoutSeconds: 5
        successThreshold: 1
        failureThreshold: 3
        terminationGracePeriodSeconds: 10
      readinessProbe:
        tcpSocket:
          port: 80
        initialDelaySeconds: 5
        periodSeconds: 5
      startupProbe:
        exec:
          command:
            - cat
            - /tmp/healthy
        initialDelaySeconds: 5
        periodSeconds: 5
        failureThreshold: 30
      lifecycle:
        postStart:
          exec:
            command: ["/bin/sh", "-c", "echo Hello > /usr/share/message"]
        preStop:
          httpGet:
            path: /prestop
            port: 8080
      stdin: true
      stdinOnce: true
      tty: true
      terminationMessagePath: /dev/termination-log
      terminationMessagePolicy: FallbackToLogsOnError
  volumes:
    - name: data
      emptyDir:
        medium: Memory
        sizeLimit: 500Mi
    - name: secret-volume
      secret:
        secretName: db-secret
        items:
          - key: username
            path: my-group/my-user
            mode: 0644
    - name: config-volume
      configMap:
        name: app-config
        items:
          - key: special.key
            path: ./local/path
            mode: 0755
        defaultMode: 0640
    - name: projected-volume
      projected:
        sources:
          - secret:
              name: conditional-secret
              items:
                - key: friendly-data
                  path: friendly-data.txt
          - downwardAPI:
              items:
                - path: "labels"
                  fieldRef:
                    fieldPath: metadata.labels
                - path: "cpu_limit"
                  resourceFieldRef:
                    containerName: test-container
                    resource: limits.cpu
          - configMap:
              name: kube-root-ca.crt
              items:
                - key: root-ca.crt
                  path: ca-bundle.crt
        defaultMode: 0644
    - name: pv-volume
      persistentVolumeClaim:
        claimName: my-pvc
        readOnly: false
    - name: host-volume
      hostPath:
        path: /var/log
        type: DirectoryOrCreate

Additional Notes: Pods are ephemeral; use controllers for management. SecurityContext fields interact (e.g., runAsNonRoot implies runAsUser !=0). Volumes can be projected for multi-source mounts. Probes support exec, HTTP, TCP, gRPC handlers.

2️⃣ DEPLOYMENT YAML FULL GUIDE

Deployments manage replicas, rolling updates, rollback, etc., by creating and updating ReplicaSets. They are for stateless apps.

Basic Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80

DEPLOYMENT KEY FIELDS (EXHAUSTIVE)

spec fields:

Field	Type	Required?	Possible Values/Defaults	Meaning & Rules
replicas	int	No	1- (default 1), 0 allowed for scale-to-zero	Desired Pod count. Negative invalid.
selector	LabelSelector	Yes	{matchLabels map[string]string, matchExpressions array{key string, operator enum In/NotIn/Exists/DoesNotExist, values array string}}	Must match template.labels exactly for creation; immutable.
template	PodTemplateSpec	Yes	Full Pod spec (metadata + spec)	Blueprint for Pods. Labels must match selector.
strategy	DeploymentStrategy	No	{type enum RollingUpdate/Recreate (default RollingUpdate), rollingUpdate {maxUnavailable int/str (default 25%), maxSurge int/str (default 25%)}, recreate? No extra}	Update method. RollingUpdate: concurrent Pod changes. maxUnavailable: Pods unavailable during update.
revisionHistoryLimit	int	No	10 (default)	Retained old ReplicaSets for rollbacks. 0 disables.
minReadySeconds	int	No	0 (default)	Seconds Pod must be ready before counting as available.
progressDeadlineSeconds	int	No	600 (default)	Timeout for rollout; marks failed if exceeded.
paused	bool	No	false	Pauses updates until unpaused.

Full Complex Example (abridged for length; includes all):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: complex-deploy
  labels:
    app: complex
spec:
  replicas: 5
  minReadySeconds: 10
  revisionHistoryLimit: 5
  progressDeadlineSeconds: 300
  paused: false
  selector:
    matchLabels:
      app: complex
    matchExpressions:
      - key: tier
        operator: In
        values: [frontend]
  template:
    metadata:
      labels:
        app: complex
        tier: frontend
    spec:
      # Full Pod spec as above
      containers:
        - name: app
          image: myapp:v1
          # ... all container fields
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 20%
      maxSurge: 1

Notes: Rollback with kubectl rollout undo. Strategy Recreate kills all before new. Selector immutability prevents label changes without delete/recreate.

3️⃣ SERVICE YAML FULL GUIDE

Services expose Pods to network via stable IP/endpoint. Types determine accessibility.

SERVICE TYPES (EXHAUSTIVE):

ClusterIP (default, internal only): Virtual IP in cluster.
NodePort: Exposes on node ports (30000-32767 default range).
LoadBalancer: Provisions external LB (cloud-specific; MetalLB for bare-metal).
ExternalName: Maps to external DNS (CNAME, no selectors/ports).
Headless (ClusterIP=None): Returns Pod IPs directly (for stateful discovery).

ClusterIP

apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 80

NodePort

spec:
  type: NodePort
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 80
      nodePort: 30080  # Optional, auto 30000-32767

LoadBalancer

spec:
  type: LoadBalancer
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 80
  loadBalancerIP: 1.2.3.4  # Optional external IP

ExternalName

spec:
  type: ExternalName
  externalName: my.database.example.com
  # No ports/selector

SERVICE KEY FIELDS (EXHAUSTIVE)

spec fields:

Field	Type	Required?	Possible Values/Defaults	Meaning & Rules
type	enum	No	ClusterIP (default), NodePort, LoadBalancer, ExternalName	Exposure method. ExternalName ignores ports.
selector	map[string]string	No (for ExternalName)	Pod labels to endpoint	Dynamic endpoints. Changes tracked. Headless: none.
ports	array[ServicePort]	No	Each: name(string optional), port(int 1-65535), targetPort(int/str/name), protocol(enum TCP/UDP/SCTP default TCP), appProtocol(string)	Service port to Pod port mapping. Multiple allowed. targetPort can reference containerPort name.
clusterIP	string	No (auto)	"None" for headless, auto IPv4/IPv6, or static	Manual IP (admin only). Immutable except to None.
clusterIPs	array[string]	No (auto)	IPv4/IPv6 IPs	For dual-stack.
externalName	string	No (for ExternalName)	Valid DNS name	CNAME target.
externalTrafficPolicy	enum	No	Cluster (default), Local	Local: preserves source IP, may route suboptimally.
healthCheckNodePort	int	No (auto for LoadBalancer)	1-65535	Dedicated port for LB health checks.
loadBalancerIP	string	No	Valid IP	Requested external IP.
loadBalancerSourceRanges	array[string]	No	CIDRs (e.g., "10.0.0.0/8")	Allowed source IPs for LB.
externalIPs	array[string]	No	Node-external IPs	Binds Service to specific IPs.
ipFamily	enum	No	IPv4 (default), IPv6, PreferDualStack	IP family preference.
ipFamilies	array[enum]	No (auto)	IPv4/IPv6	For dual-stack.
sessionAffinity	enum	No	None (default), ClientIP	Sticky sessions by client IP.
sessionAffinityConfig	SessionAffinityConfig	No (if affinity=ClientIP)	{clientIP: {timeoutSeconds int 1-86400 default 10800}}	Session timeout.
publishNotReadyAddresses	bool	No	false	Includes not-ready Pods in endpoints.
topologyKeys	array[string]	No	Topology keys (e.g., "topology.kubernetes.io/zone")	Client IP preference for topology-aware routing.

Full Complex Example (abridged):

apiVersion: v1
kind: Service
metadata:
  name: complex-svc
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
spec:
  type: LoadBalancer
  selector:
    app: complex
  ports:
    - name: http
      port: 80
      targetPort: http
      protocol: TCP
      appProtocol: http
    - name: metrics
      port: 8080
      targetPort: 8080
      protocol: UDP
  clusterIP: None  # Headless
  externalTrafficPolicy: Local
  healthCheckNodePort: 32000
  loadBalancerIP: 203.0.113.1
  loadBalancerSourceRanges: ["10.0.0.0/8"]
  externalIPs: ["203.0.113.10"]
  ipFamily: PreferDualStack
  ipFamilies: [IPv4, IPv6]
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 7200
  publishNotReadyAddresses: true
  topologyKeys:
    - "topology.kubernetes.io/zone"
    - "*"

Notes: Services watch selector for endpoint updates. Use kubectl expose for quick creation. For multi-port, specify name for clarity.

4️⃣ CONFIGMAP FULL GUIDE

Used to store non-secret configuration as key-value pairs. Can be consumed as env vars, files, or volumes. Data is plain text.

Full Structure:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  DB_HOST: mysql
  DB_PORT: "3306"
  config.json: '{"key":"value"}'  # Multi-line OK
binaryData:  # Optional, base64 for binary
  key: dmFsdWU=  # base64 "value"
immutable: true  # Optional, prevents updates

KEY FIELDS (EXHAUSTIVE)

Field	Type	Required?	Possible Values/Defaults	Meaning & Rules
data	map[string]string	No	Keys: alphanumeric + '-', '_' (253 chars); Values: strings (<1MB total)	Plain text key-values. Preferred for text.
binaryData	map[string]string	No	Same keys; Values: base64-encoded bytes	For non-text (e.g., images). Decoded on use.
immutable	bool	No	false (default)	If true, cannot update/delete; faster caching. Metadata immutable too.

Notes: Create with kubectl create configmap. Consume in Pod: envFrom, volume (projeced/configMap). No validation on values.

5️⃣ SECRET FULL GUIDE

Used to store passwords/keys (Base64 encoded). Types for specific uses; data not encrypted at rest (use etcd encryption).

Full Structure:

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque  # Enum
data:
  username: YWRtaW4=  # base64 "admin"
  password: cGFzc3dvcmQ=  # base64 "password"
stringData:  # Optional, plain text (auto base64'd)
  username: admin
immutable: true

KEY FIELDS (EXHAUSTIVE)

Field	Type	Required?	Possible Values/Defaults	Meaning & Rules
type	enum	No	Opaque (default), kubernetes.io/service-account-token, kubernetes.io/dockerconfigjson, bootstrap.kubernetes.io/token, kubernetes.io/tls, kubernetes.io/ssh-auth, Opaque (generic)	Hints usage (e.g., tls for certs). Affects validation.
data	map[string]string	No	Keys: alphanumeric + '-', '_' (253); Values: base64 (<1MB total)	Encoded sensitive data.
stringData	map[string]string	No	Same keys; Plain strings (converted to data on save)	Convenience; not persisted.
immutable	bool	No	false	Like ConfigMap; prevents updates.

Types Details:

Opaque: Generic.
kubernetes.io/service-account-token: Auto-created for SAs, with token/CA/namespace.
kubernetes.io/dockerconfigjson: For .dockercfg ({auths: {registry: {username, password, ...}}}).
kubernetes.io/tls: {tls.crt, tls.key}.
bootstrap.kubernetes.io/token: For bootstrap (token-id, token-secret, etc.).

Notes: Base64 reversible; use external encryption. Consume like ConfigMap but for secrets. kubectl create secret generic.

6️⃣ INGRESS YAML FULL GUIDE

Ingress exposes HTTP/HTTPS using hostname rules. Requires Ingress Controller (e.g., NGINX).

Full Structure:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx  # Optional
  defaultBackend:
    service:
      name: fallback-svc
      port:
        number: 80
  tls:  # Optional
    - hosts:
        - demo.local
      secretName: tls-secret
  rules:
    - host: demo.local
      http:
        paths:
          - path: /
            pathType: Prefix  # Enum: Prefix/Exact/ImplementationSpecific
            backend:
              service:
                name: nginx-service
                port:
                  number: 80
              resource:  # Alternative to service
                apiVersion: apps/v1
                kind: Deployment
                name: nginx-deploy

KEY FIELDS (EXHAUSTIVE)

spec fields:

Field	Type	Required?	Possible Values/Defaults	Meaning & Rules
ingressClassName	string	No	Valid IngressClass	Selects controller (e.g., "nginx").
defaultBackend	IngressBackend	No	{service {name/port}, resource {apiVersion/kind/name}}	Catch-all for unmatched requests.
tls	array[TLS]	No	Each: {hosts array[string], secretName string}	HTTPS; secret type kubernetes.io/tls. Multiple SNI.
rules	array[HTTPIngressRuleValue]	No	Each: {host string (optional), http {paths array[HTTPIngressPath]}}	Host-based routing. Nil host = all hosts.

HTTPIngressPath:

path: string
pathType: enum Prefix (matches prefix), Exact (exact match), ImplementationSpecific (controller-defined)
backend: IngressBackend (service {name, port {number/name}}, resource for weighted)

Notes: Annotations controller-specific (e.g., rate limits). Paths ordered; first match wins. Use kubectl annotate for extras.

7️⃣ PERSISTENT VOLUMES (PV)

PV is cluster storage, provisioned statically or dynamically (via StorageClass).

Full Structure:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 1Gi
    # Other: cpu? No, storage only
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain  # Enum
  storageClassName: standard
  mountOptions: ["ro", "soft"]  # Array string
  nodeAffinity:  # VolumeNodeAffinity
    required:
      nodeSelectorTerms:
        - matchFields: [...]  # Like nodeSelector
  volumeMode: Filesystem  # Enum Filesystem/Block
  pvPhase: Available  # Read-only, enum
  # Driver-specific:
  hostPath:
    path: /data/pv1
    type: DirectoryOrCreate
  # Or awsElasticBlockStore, gcePersistentDisk, nfs, etc. (50+ drivers)

KEY FIELDS (EXHAUSTIVE)

Field	Type	Required?	Possible Values/Defaults	Meaning & Rules
capacity	map[string]Quantity	Yes	{storage: string e.g. "1Gi"/"1000GiB"}	Requested size; Quantity is decimal + unit (Ki/Mi/Gi/Ti, or bytes).
accessModes	array[enum]	No	ReadWriteOnce (RWO, single node RW), ReadOnlyMany (ROX, multi node RO), ReadWriteMany (RWX, multi RW), ReadWriteOncePod (RWOP, single Pod RW)	Compatibility; multiple possible but intersected on bind.
persistentVolumeReclaimPolicy	enum	No	Retain (default for static), Recycle (unsafe, deprecated), Delete (for dynamic)	Post-release: Retain (manual), Delete (cloud destroy).
storageClassName	string	No	"" (no class) or class name	For dynamic provisioning/selectors.
mountOptions	array[string]	No	FS mount flags (e.g., "ro,vers=3")	Per-volume mounts.
volumeMode	enum	No	Filesystem (default), Block	Block: raw device, no FS.
nodeAffinity	VolumeNodeAffinity	No	{required: NodeSelector (terms)}	Restricts binding to nodes.
# Driver fields (mutually exclusive)				One driver source required. Examples:
hostPath	HostPathVolumeSource	No	{path string, type enum Directory/DirectoryOrCreate/File/BlockDevice/CharDevice/Socket}	Local node path; ephemeral.
nfs	NFSVolumeSource	No	{server string, path string, readOnly bool}	Network FS.
persistentVolumeClaim	No, PV not from PVC.
csi	CSIVolumeSource	No	{driver string, volumeAttributes map, nodePublishSecretRef, volumeHandle string, readOnly bool, fsType string, controllerPublishSecretRef, controllerExpandSecretRef, ... (full CSI spec)}	Custom Storage Interface.

Notes: PVs are cluster-scoped. Phase: Available/Pending/Bound/Released/Failed. Use StorageClass for dynamic.

8️⃣ PERSISTENT VOLUME CLAIM (PVC)

PVC requests storage; binds to PV.

Full Structure:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: standard
  volumeMode: Filesystem
  selector:  # Optional
    matchLabels:
      disk: ssd
  volumeName: my-pv  # Bind to specific PV
  dataSource:  # For snapshots/clones
    name: snapshot-1
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io

KEY FIELDS (EXHAUSTIVE)

Field	Type	Required?	Possible Values/Defaults	Meaning & Rules
accessModes	array[enum]	No	RWO/ROX/RWX/RWOP	Requested; must match PV.
resources	ResourceRequirements	No	{requests {storage Quantity}, limits {storage Quantity}}	Min/max storage. limits optional.
storageClassName	string	No	"" or class	Selects PV class.
volumeMode	enum	No	Filesystem/Block	Requested mode.
selector	LabelSelector	No	Matches PV labels	Filters PVs.
volumeName	string	No	PV name	Binds to exact PV.
dataSource	TypedLocalObjectReference	No	{kind string, name string, apiGroup string}	Clone from snapshot/volume (e.g., CSI).

Notes: Namespace-scoped. Status.phase: Pending/Bound. Delete PVC releases PV per reclaim policy.

🔥 SECTION 4 — KEY YAML RULES

✔ Indentation matters

Use spaces, not tabs (2 or 4 spaces common; consistent). Misindentation causes parse errors (e.g., key under wrong level).

✔ Lists start with `-`

Example:

containers:
  - name: nginx  # Array item
    image: nginx
  - name: sidecar

Nested lists: - - for deeper.

✔ Order of top-level keys MUST be:

The order is flexible in YAML (not enforced), but conventional and recommended for readability:

apiVersion:  # First
kind:        # Second
metadata:    # Third
spec:        # Fourth (status omitted)

API server ignores order, but tools like kubectl apply --prune assume it.

✔ Strings can be quoted or unquoted

value: "abc"      # Quoted: preserves spaces, allows ':'
value: abc        # Unquoted: fine for simple
value: 'single'   # Single: literal
value: \| multi\n line  # Block literal

Special: ~ for null, true/false bools, 123 int, 3.14 float auto-detected.

✔ Multi-document YAML uses `---`

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: cm1
---
apiVersion: v1
kind: Secret
metadata:
  name: sec1

kubectl apply -f dir/ processes all. End with optional ....

Additional Rules:

Comments: # This is a comment (line-based).
Anchors/Aliases: &anchor / *anchor for reuse (advanced).
No duplicate keys (last wins, but invalid in K8s).
Total file size <1MB practical.
Validate: kubectl apply --dry-run=client -f file.yaml.

📚 SECTION 5 — SYMBOL MEANINGS IN YAML

Symbol	Meaning	Example	Notes
`:`	key-value pair	key: value	Colon + space separates.
`-`	list item	- item1 - item2	Dash + space; indentation defines level.
`#`	comment	# Ignored	From # to EOL; no block comments.
`\	`	literal multiline text (preserves newlines)	key: \
`>`	folded multiline text (folds to single line, newlines to space)	key: > line1 line2	Chops newlines; useful for logs.
`{}`	empty object/map	{}	Empty dict.
`[]`	empty list/array	[]	Empty array.
`~`	null value	key: ~	Explicit null.
`&`	anchor (reference)	&name value	Define alias target.
`*`	alias (reference)	*name	Reuse anchored value.
`!`	tag (custom type)	!str "123"	Rarely used in K8s.

Advanced: Flow style {key: value, list: [1,2]} compact, but block preferred for readability.

🧠 SECTION 6 — API OBJECT FLOW IN KUBERNETES

When you apply YAML (kubectl apply -f file.yaml or kubectl create --save-config):

Client (kubectl): Validates YAML syntax, sends to API Server (with auth). ↓
Kube API Server: Authenticates (RBAC), authorizes, validates schema (apiVersion/kind/spec), admits (webhooks), persists to etcd as JSON. ↓
etcd: Stores object with metadata (uid, timestamps). Watchers notify. ↓
Controller Manager: Reconciles (e.g., Deployment controller creates ReplicaSet → Pods). Loops: watch → diff desired/actual → act. ↓
Scheduler: Assigns unbound Pods to nodes (filters: nodeSelector/tolerations; scores: affinity). ↓
Kubelet (on node): Pulls Pod spec via API, runs containers (via CRI like containerd), reports status (probes, events). Mounts volumes, runs initContainers. ↓
Status Updates: Kubelet → API → etcd. Controllers update observed state.

Error Flows: Validation fails → 400 Bad Request. Quotas → 429. Network issues → retries. Use kubectl describe for events.

Advanced Components: Cloud Controller Manager for cloud resources; Custom Controllers for CRDs.

🛠 SECTION 7 — FULL BEST PRACTICES

✔ Always use labels

labels:
  app.kubernetes.io/name: myapp  # Standard prefix
  app.kubernetes.io/version: v1.2.3
  app.kubernetes.io/component: frontend
  app.kubernetes.io/part-of: ecommerce
  app.kubernetes.io/managed-by: helm

Follow semantic labeling (app.kubernetes.io/*). Use for all selectors.

✔ Don’t hardcode nodePort unless needed

Let Kubernetes auto-assign (type: NodePort). Reserve ranges via kube-apiserver flags.

✔ Use `resources:` for CPU/RAM limits

resources:
  requests:
    cpu: "100m"    # 0.1 core
    memory: "128Mi"
  limits:
    cpu: "200m"
    memory: "256Mi"

Requests for scheduling; limits for OOMKill/cgroup. Set limits > requests for Burstable QoS.

✔ Use livenessProbe & readinessProbe

Liveness: Restart if unhealthy (e.g., HTTP 200 on /healthz).
Readiness: Exclude from Service if not ready (e.g., DB connection check).
Startup: For slow starts (higher failureThreshold).

✔ Put multiple objects in one YAML using `---`

Atomic apply; order-independent (API serializes).

✔ Additional Best Practices

Namespaces: Isolate tenants; use ResourceQuota/LimitRange.
RBAC: Least privilege; use Roles over ClusterRoles.
Probes: timeoutSeconds >0; periodSeconds balanced (not too frequent).
Updates: Use kubectl apply for declarative; --record for history.
Validation: --dry-run=server before apply.
Security: Non-root containers; no hostNetwork; PodSecurityStandards.
Storage: Use StorageClasses; RWX for shared.
Scaling: HPA for horizontal; VPA for vertical.
Monitoring: Labels for Prometheus scraping.
Helm/Kustomize: For templating; avoid raw YAML in prod.
Immutable ConfigMaps/Secrets: Set immutable: true for caching.
Affinity/Anti-Affinity: Spread across AZs; co-locate related.
Taints/Tolerations: Dedicate nodes (e.g., GPU).
Finalizers: Custom cleanup (e.g., webhook sync).

🎯 FINAL SUMMARY (COMPLETE MENTAL MODEL OF K8s YAML)

Every Kubernetes YAML has these 4 parts:

apiVersion → tells Kubernetes which API to use (e.g., apps/v1; schema enforcer)
kind → tells Kubernetes what you’re creating (e.g., Deployment; routes to handler)
metadata → name, labels, namespace (identity/selectors; e.g., app: nginx for matching)
spec → details for the object (the big part; desired state, e.g., replicas: 3, template Pod spec)

Every service type eventually routes traffic to Pods using selector labels:

LoadBalancer (external cloud IP)  # Provisions LB
    ↓ (forwards to NodePorts or directly)
NodePort (30000-32767 on nodes)   # Exposes on cluster nodes
    ↓ (proxies internally)
ClusterIP (virtual cluster IP)    # Internal service discovery
    ↓ (endpoints watch Pods)
Pod IP (ephemeral, via selector)  # Direct to matching labeled Pods

Headless Services return A/AAAA records for Pods.

Deployments create Pods (via ReplicaSets; handle updates/rollbacks)
Pods run containers (with env, volumes, probes; ephemeral units)
Services expose Pods (stable endpoints; types for access levels)
Ingress exposes Services (L7 routing, TLS termination)
ConfigMaps & Secrets configure Pods (injected data; separate concerns)
PVs/PVCs give Pods storage (decoupled persistence; dynamic provisioning)
NetworkPolicies secure traffic (default allow → explicit deny; label-based)
StatefulSets for ordered/stateful (stable identities: pod-0, pod-1)
DaemonSets for node agents (monitoring, logging)
Jobs/CronJobs for batch (completion-based)

This model scales: Controllers watch → Act → Status loop. Declarative wins over imperative.

🚀 Done!

This is the COMPLETE, FULL, ALL-IN-ONE guide to Kubernetes YAML — covering all syntax, rules, keywords, meanings, and examples in exhaustive detail, with every key, value type, enum, and interaction documented.

Quick Sort C++: Story

Harsh Mishra — Sat, 13 Sep 2025 17:22:45 +0000

🔥 The Tale of the Chosen Pivot: The Quick Sort Saga

"A king is not crowned by chance,
but by the blade of division.
He rules only when all lesser kneel before him,
and the greater stand beyond."
— The Law of the Pivot King

The realm of warriors was restless. Each claimed strength, each stood in chaos. Kings and squires alike jostled for place, yet no order ruled their line.

The Oracle spoke:

“Crown not all at once.
Choose one king — a pivot.
Place him upon his throne,
and let those weaker bow to his left,
while the stronger march to his right.
Repeat, until all kings are crowned.”

Thus began the saga of Quick Sort — the Ritual of the Pivot Kings.

📜 The Scroll of Streams

#include <iostream>
#include <vector>
using namespace std;

The scribes unfurled their scrolls (iostream) and laid out the line of warriors (vector). Upon this field, the ritual would carve destiny.

👑 The Coronation of the Pivot

int partition(vector<int>& arr, int low, int high) {
    int pivot = arr[high];

From the far end of the line, a warrior was chosen as pivot. He was not always the strongest nor the weakest, but destiny marked him king for this round. His throne would soon be revealed.

    int i = low - 1;

The ground was cleared. A marker was drawn just before the first warrior, at i. It waited for those loyal to kneel before the pivot king.

⚔️ The Division of Allegiance

    for (int j = low; j < high; j++) {
        if (arr[j] <= pivot) {
            i++;
            swap(arr[i], arr[j]);
        }
    }

The Oracle moved down the line. Each warrior was tested against the pivot king.

If a warrior was lesser or equal, he pledged loyalty. He stepped left, joining those before, and the marker i advanced. Their positions were swapped, so loyalists formed a block of unity at the front.

Those greater than the pivot held back, waiting beyond. Thus, allegiance was drawn in the sand — the loyal left, the defiant right.

👑 The Throne of the Pivot

    swap(arr[i + 1], arr[high]);
    return i + 1;
}

At last, the king claimed his throne. He was placed between the loyal and the defiant, his seat at i + 1. None could challenge him now, for all lesser stood before him, and all greater behind.

The partition was complete. One king’s place was secured forever.

🌌 The Endless Coronations

void quickSort(vector<int>& arr, int low, int high) {
    if (low < high) {
        int pi = partition(arr, low, high);

But one king was not enough. The Oracle commanded the ritual anew. With the pivot seated, the land was split into two realms — left and right. Each would find its own king.

        quickSort(arr, low, pi - 1);
        quickSort(arr, pi + 1, high);
    }
}

The coronations continued, dividing again and again. Each realm was split, each chosen pivot crowned, until no fragment remained unruled. When the ritual ended, the entire kingdom was ordered — smallest at the dawn, greatest at the dusk.

🎺 The Trial of Nine

int main() {
    vector<int> arr = {10, 7, 8, 9, 1, 5, 20, 3, 15};

On one day, nine warriors stood in chaos: 10, 7, 8, 9, 1, 5, 20, 3, 15. Each claimed a crown, none stood in order.

    quickSort(arr, 0, arr.size() - 1);

The ritual of Quick Sort was called. Kings were chosen, pivots crowned, thrones assigned. Division spread like wildfire, but from it rose harmony.

👏 The Herald’s Call

    for (int x : arr) {
        cout << x << " ";
    }
    cout << endl;
}

At last, the Herald strode forth. He called the warriors in their new order, weakest to strongest, and the line shimmered with balance.

The people bowed, for chaos had ended, and the Pivot Kings ruled in eternal order.

🧠 Memory of the Pivot

partition — the crowning of a pivot king.
loyal warriors ≤ pivot — step left, their positions swapped forward.
greater warriors > pivot — remain on the right.
swap(pivot, i+1) — the king takes his throne.
quickSort left & right — the realms split, each crowning its own kings.

Thus, Quick Sort is remembered as the Tale of the Pivot Kings, where division forged a perfect realm. 🔥👑

Merge Sort C++: Story

Harsh Mishra — Sat, 13 Sep 2025 17:22:20 +0000

🌌 The Sundering and the Great Unification: The Merge Sort Saga

"That which is whole must first be broken,
and that which is broken must then be joined.
Only in division and reunion does true order rise."
— The Song of the Unifier

The world was once whole, but chaos ruled it. The kings and squires, pearls and shells, great and small — all stood in disarray. No hand could place them in order, for together they were a storm.

But an Oracle spoke:

“Break the world apart, until each stands alone.
Then, piece by piece, unite them again,
and in reunion, order shall be born.”

Thus began the saga of Merge Sort — the ritual of Sundering and Unification.

📜 The Scroll of Division

#include <iostream>
#include <vector>
using namespace std;

The scribes prepared their scrolls (iostream) and nets (vector), for they would need to shatter the world into pieces and then weave it whole again.

⚔️ The Spell of Unification

void merge(vector<int>& arr, int left, int mid, int right) {

The first spell was named merge. It was no small charm — its power was to reunite two halves, making them one. For only in this reunification could order arise.

    int n1 = mid - left + 1;
    int n2 = right - mid;

The Oracle looked upon the world and saw it split into two.
The left half contained n1 warriors, the right half n2.
Two camps had formed, awaiting judgment.

    vector<int> L(n1), R(n2);
    for (int i = 0; i < n1; i++)
        L[i] = arr[left + i];
    for (int j = 0; j < n2; j++)
        R[j] = arr[mid + 1 + j];

The warriors were drawn into two scrolls: L and R. Each remembered their lineage, each carried the memory of their half. Now they stood apart, waiting to be joined again.

🌌 The Great Joining

    int i = 0, j = 0, k = left;
    while (i < n1 && j < n2) {
        if (L[i] <= R[j]) {
            arr[k] = L[i];
            i++;
        } else {
            arr[k] = R[j];
            j++;
        }
        k++;
    }

The Oracle began the joining. From each side, the smallest warrior was chosen.

If the left warrior was smaller or equal, he stepped into the great line. Otherwise, the right warrior claimed the place. One by one, they marched, filling the array with order.

This was no duel — it was a dance of balance, where neither side was ignored, and each gave way when the other was smaller.

    while (i < n1) {
        arr[k] = L[i];
        i++;
        k++;
    }
    while (j < n2) {
        arr[k] = R[j];
        j++;
        k++;
    }
}

When one camp was exhausted, the survivors of the other marched forth unopposed. All found their place in the new, ordered line. The merge was complete.

🏹 The Sundering Ritual

void mergeSort(vector<int>& arr, int left, int right) {
    if (left < right) {
        int mid = left + (right - left) / 2;

The second spell was named mergeSort. Its power was the Sundering.

The Oracle gazed upon the line. If more than one soul stood within, she split it. The midpoint was chosen — dividing the realm into left and right.

        mergeSort(arr, left, mid);
        mergeSort(arr, mid + 1, right);

The Sundering was not done once, but again and again. Each half was broken further, split into smaller and smaller fragments — until only single warriors stood.

For a lone warrior needs no sorting. Alone, he is already in order.

        merge(arr, left, mid, right);
    }
}

But once all were sundered, the Oracle began the opposite journey. The merging began. Two halves became one, then greater halves, until at last the entire realm was reunited — not in chaos, but in perfect ascending order.

🎺 The Trial of Eight

int main() {
    vector<int> arr = {38, 27, 43, 3, 9, 82, 10};

One day, seven warriors stood in a line: 38, 27, 43, 3, 9, 82, 10. They were mighty, but disordered.

    mergeSort(arr, 0, arr.size() - 1);

The Oracle raised her hand. The Sundering began. Each warrior was torn from his companions until he stood alone.

Then, slowly, patiently, the reunification came. As halves became whole, the warriors marched into their destined places.

👏 The Herald’s Call

    for (int x : arr) {
        cout << x << " ";
    }
    cout << endl;
}

At last, the Herald walked the line. One by one, the warriors were called. Their names rang not in chaos, but in order — the smallest first, the largest last.

The crowd roared. The prophecy was fulfilled. The realm was united, perfectly sorted.

🧠 Memory of the Sundering

mergeSort — the ritual of Sundering, breaking the world until only singles remain.
merge — the great Unification, joining halves by choosing the smallest each time.
while loops — the march of survivors into the final line.

Thus, Merge Sort is remembered as the Saga of Sundering and Unity, where division gave way to harmony. 🌌👑

Selection Sort C++: Story

Harsh Mishra — Sat, 13 Sep 2025 17:21:50 +0000

👑 The Rite of the True Heir: The Selection Sort Saga

"Among many who claim the crown, only one is worthy.
Choose him, place him upon the throne,
and the line of kings shall be written."
— The Book of Crowns

In the fractured kingdom, many warriors shouted of their worth. Each believed himself the strongest, yet none stood where destiny demanded.

The High Oracle commanded a ritual, not of chaos or battle, but of choice. In each moment, the smallest and humblest would be sought out among the many, lifted, and placed upon the next empty throne.

Thus began the Rite of the True Heir, known to the scribes as Selection Sort.

📜 The Scroll of Crowns

#include <iostream>
#include <vector>
using namespace std;

The scribes unrolled the scrolls (iostream) and laid out the line of would-be kings (vector). Upon these pages the names of the chosen would be recorded, one after another, in rightful order.

⚔️ The Oracle’s Decree

void selectionSort(vector<int>& arr) {

The Oracle raised her hand. The ritual of selectionSort was spoken aloud, and the line of claimants trembled. Soon, one by one, the crowns would be assigned.

    int n = arr.size();

The Herald counted the warriors. Their number, n, was the length of destiny — for each throne would be filled in turn, from the smallest to the greatest.

👑 The Search for the True Heir

    for (int i = 0; i < n - 1; i++) {
        int minIndex = i;

The Oracle’s gaze fell upon the first empty throne (i). She pointed to the warrior standing before it and declared, “For now, you are the chosen.”

But she knew better than to trust appearances. The true heir must be sought. Thus, the warrior at i was marked as minIndex — the one assumed to be smallest, until proven otherwise.

🔍 The Trial of Comparison

        for (int j = i + 1; j < n; j++) {
            if (arr[j] < arr[minIndex])
                minIndex = j;
        }

One by one, the Oracle inspected every warrior beyond the throne. Each was measured against the current choice.

If any warrior smaller, humbler, or more rightful appeared, the Oracle’s finger shifted. The crown would not be given until all had been judged.

Thus, the smallest among all was revealed, even if he had stood at the farthest edge of the line.

🔄 The Exchange of Thrones

        swap(arr[i], arr[minIndex]);
    }
}

At last, the true heir was known. The Oracle lifted him from his place and set him upon the throne i.

If the chosen heir had stood there already, no change was needed. But if another had been mistaken for king, their places were exchanged.

The ritual continued, throne after throne, until all warriors had been seated in their rightful order — the weakest upon the first, the strongest upon the last.

🎺 The Trial of Eight

int main() {
    vector<int> arr = {29, 10, 14, 37, 13, 2, 50, 41};

One day, eight claimants stood before the Oracle: 29, 10, 14, 37, 13, 2, 50, 41. They shouted loudly of crowns, yet none stood in the order of truth.

    selectionSort(arr);

The ritual began. One by one, the smallest was found, crowned, and seated. Pride was stripped away, and the kingdom’s order was restored through the ritual of selection.

👏 The Herald’s Call

    for (int x : arr) {
        cout << x << " ";
    }
    cout << endl;
}

At last, the Herald called their names aloud. Each warrior stepped forth in ascending order, weakest to strongest. The people cheered, for the true heirs had taken their places, and the kingdom knew peace again.

🧠 Memory of the Crown

The outer loop — the thrones waiting, one by one.
The minIndex — the assumed heir, tested against others.
The inner loop — the trials of comparison, seeking the true smallest.
The swap — the crowning of the rightful heir.

Thus, Selection Sort is remembered as the Rite of the True Heir, where order was restored not by battle, but by careful choice. 👑⚔️

Insertion Sort C++: Story

Harsh Mishra — Sat, 13 Sep 2025 17:21:21 +0000

🏹 The Chronicles of the Order-Bearer: The Insertion Sort Saga

"A line is not born perfect.
It becomes perfect when each finds his rightful place among those before him."
— Song of the Order-Bearer

In the Kingdom of Lines, chaos walked proudly. Warriors stood not by skill, but by chance. A weakling might precede a champion, and a champion might be buried among squires.

The High Sage decreed:

“Each warrior shall step into the line one by one.
He shall not stand where he first lands, but where he belongs among those before him.
Thus, the line shall grow in order, piece by piece, until all stand as one.”

This ritual became known as the Insertion Sort.

📜 The Scroll of Lineage

#include <iostream>
#include <vector>
using namespace std;

The scribes laid open the scrolls (iostream) and spread the line of warriors (vector). Upon these pages the ritual of order would be etched, so the kingdom would remember.

⚔️ The Call of the Sage

void insertionSort(vector<int>& arr) {

The Sage raised his staff and called the warriors into the ritual. The spell of insertionSort was named, and the line stood trembling, waiting to be set aright.

    int n = arr.size();

The first step was to count them — all who would stand in the line. n was not just a number; it was the length of destiny, the measure of the order yet to come.

🏹 The Warrior Steps Forward

    for (int i = 1; i < n; i++) {

The first warrior at position 0 was left alone — for a single soul needs no order.

Then, beginning from the second (i = 1), each warrior stepped forward into the growing line. He could not stand merely where he entered. He had to find his rightful place among those who came before.

⚖️ The Choice of the Key

        int key = arr[i];
        int j = i - 1;

The chosen warrior was lifted from the line — called the key. He looked back to those who already stood ordered behind him. The one before him (j) was his rival, his test.

🛡️ The Trials of Comparison

        while (j >= 0 && arr[j] > key) {
            arr[j + 1] = arr[j];
            j = j - 1;
        }

The key warrior faced the champions before him. If a warrior (arr[j]) was stronger (greater) than him, that warrior stepped one place forward to make room.

The key pressed on, moving backward, testing again and again — until he found a rival no stronger than himself, or the beginning of the line.

Thus, each trial shifted others forward, like a ripple of respect, until the key’s rightful place was uncovered.

👑 The Final Placement

        arr[j + 1] = key;
    }
}

At last, the key settled into the place destiny had prepared for him. The line closed around him, stronger than before. Then the next warrior stepped forward, and the ritual repeated.

By the end, every soul had found his rightful place, and the line stood perfect — ordered from weakest to strongest.

🎺 The Trial of Eight

int main() {
    vector<int> arr = {12, 11, 13, 5, 6, 7, 3, 15};

On one dawn, eight warriors entered the line: 12, 11, 13, 5, 6, 7, 3, 15. They stood in chaos, their strength unmatched to their order. The Sage prepared the ritual, and the people watched.

    insertionSort(arr);

The ritual began. One by one, the warriors were lifted, tested, and placed. With each step, the line grew more ordered, until the disorder was driven out entirely.

👏 The Herald’s Call

    for (int x : arr) {
        cout << x << " ";
    }
    cout << endl;
}

At last, the Herald marched down the line, calling each warrior in turn. Their names rang out in ascending order. The crowd cheered, for the line now mirrored the wisdom of the Sage.

🧠 Memory of the Ritual

The outer loop — each warrior stepping forward into the line.
The key — the chosen warrior, lifted to find his place.
The while loop — the backward trials, shifting stronger warriors forward.
The placement — the key settling where destiny decreed.

Thus, Insertion Sort is remembered as the Ritual of the Order-Bearer, where chaos gave way to harmony, one warrior at a time. 🏹👑

Bubble Sort C++: Story

Harsh Mishra — Sat, 13 Sep 2025 17:20:56 +0000

👑 The Tournament of the Shifting Blades: The Bubble Sort Legend

"Strength is not proven by standing still.
True warriors find their rightful place in the order of blades."
— Edict of the First King

In the realm of scattered banners, warriors stood shoulder to shoulder, yet no order bound them. A squire might boast before a knight, and a knight before a king. Chaos was written into the very line of steel.

The High King, weary of such disorder, proclaimed the Grand Tournament. Only through duels would the warriors discover their rightful places. With every clash, the strongest would fall back and the weakest rise forward, until the line itself sang of balance.

📜 The Call to Arms

#include <iostream>
#include <vector>
using namespace std;

The scribes opened their scrolls, and the arena was drawn upon the parchment. The warriors would be kept within a line of steel — the vector — and their story inked through the streams of the iostream.

⚔️ The Arena Opens

void bubbleSort(vector<int>& arr) {

The gates of the arena creaked open. Into it, the warriors marched. The ritual was called bubbleSort, and its purpose was as old as the throne itself — to bring order where there was none.

    int n = arr.size();

The Herald stepped forward, his voice booming across the stands. He counted every warrior, one by one, until the crowd knew how many would fight. That number, n, was the measure of destiny.

🏹 The Rounds Begin

    for (int i = 0; i < n - 1; i++) {

The first round began. The crowd rose to their feet, for they knew each wave of battle would settle one champion. With every clash, the mightiest of that round would be pushed to the end, where he would stand unmoved again. The next round, therefore, needed fewer tests, for one place had already been claimed.

🛡️ The Neighbor Duels

        for (int j = 0; j < n - i - 1; j++) {

Within each round, warriors turned to face their neighbors. No swords were drawn from across the line; only the one beside you mattered. Each duel was swift, brutal, and watched by all. In this way, the order was forged step by step, neighbor by neighbor.

⚖️ The King’s Judgment

            if (arr[j] > arr[j + 1]) {

The King watched closely. If a warrior stood too proud, stronger yet placed before a weaker, the King’s hand rose. The judgment was clear — arrogance could not stand before humility.

🔄 The Clash of Blades

                swap(arr[j], arr[j + 1]);

And so they clashed. Steel rang, dust rose, and the stronger was forced back while the weaker advanced. This was no shame, only correction — for each must find his rightful place in the grand line of honor.

🌌 The Endless Rounds

        }
    }
}

The tournament raged on. Round after round, duel after duel, the warriors reshaped themselves. Slowly, pride gave way to order. And when the final clash faded, the line stood perfect — weakest at the front, strongest at the end.

🎺 The Trial of Seven

int main() {
    vector<int> arr = {64, 34, 25, 12, 22, 11, 90};

One dawn, seven warriors entered the arena: 64, 34, 25, 12, 22, 11, 90. They stood in chaos, their strength unmatched to their position. The crowd murmured, sensing the King’s displeasure.

    bubbleSort(arr);

The horn sounded, and the duels began. One by one, the proud were forced back, the humble were lifted forward. The spell of bubbleSort was upon them, and the order was inevitable.

👏 The Final Parade

    for (int x : arr) {
        cout << x << " ";
    }
    cout << endl;
}

At last, the Herald called their names. One after another, they stepped forward in perfect order, weakest to strongest. The crowd cheered, for the line of warriors now mirrored the will of the King. The Tournament was complete.

🧠 Memory of the Arena

The outer loop — the rounds of the tournament, each settling one champion.
The inner loop — the neighbor duels, brutal and swift.
The if-condition — the King’s judgment on pride.
The swap — the clash that corrects the line.

Thus Bubble Sort is remembered as the Tournament of the Shifting Blades, where every warrior found his rightful place. ⚔️👑

Dijkstra's Algorithm C++: Story

Harsh Mishra — Sat, 16 Aug 2025 20:58:49 +0000

🏹 The Beacon Riders of the Northern Realms — The Dijkstra Saga

"In the kingdom where roads shimmered with frost, the fastest rider was the one who chose his next step with care."
— Songs of the Winter Messenger

The Northern Realms were a land of villages connected by winding frozen roads, each road taking a certain amount of time to travel.
The High Council needed to send messengers from the capital to every other village, carrying news of an approaching winter storm.
But there was a rule: messengers must always choose the currently closest unexplored village to visit next, so no time would be wasted wandering far before checking nearer places.

#include <iostream>
#include <vector>
#include <queue>
#include <limits>
using namespace std;

class Dijkstra {
    int n;
    vector<vector<pair<int, int>>> adj;
    vector<int> dist;
    const int INF = numeric_limits<int>::max();
public:
    Dijkstra(int n) : n(n) {
        adj.resize(n);
        dist.assign(n, INF);
    }

The kingdom was drawn as n villages on a great frost-map.
Beside each village lay a ledger of roads: adj[u] kept track of every road from that village, written as (neighbor, time_cost).
dist[] was the parchment where the shortest known times to reach each village would be recorded.

    void addRoad(int u, int v, int w) {
        adj[u].push_back({v, w});
        adj[v].push_back({u, w});
    }

Every road was carved into the map:
"From U to V, the ride takes W hours."
And because roads in the Northern Realms could be traveled in both directions, the same note was made for the reverse path.

    void shortestPaths(int src) {
        dist[src] = 0;
        priority_queue<pair<int, int>, vector<pair<int, int>>, greater<pair<int, int>>> pq;
        pq.push({0, src});

The messengers began at the capital (src).
The time to reach the capital itself was 0.
A magical beacon-fire, represented by a priority queue, was lit — its flames always showing the next closest village yet to be visited.

        while (!pq.empty()) {
            int d = pq.top().first;
            int u = pq.top().second;
            pq.pop();

At each step, the beacon’s flame called forth the nearest unexplored village.
The chosen village’s name was read, and the messenger rode there next.

            if (d > dist[u]) continue;

If a messenger arrived and found that a faster messenger had already reached this village before, they turned around without delay — no need to waste effort on a place already warned sooner.

            for (auto &edge : adj[u]) {
                int v = edge.first;
                int w = edge.second;
                if (dist[u] + w < dist[v]) {
                    dist[v] = dist[u] + w;
                    pq.push({dist[v], v});
                }
            }
        }

From each newly reached village, the messenger looked at every road leading outward.
If traveling through this village gave a shorter path to another village than previously known, the ledger was updated.
The beacon-fire was fed with this news, so those closer villages could be visited next.

And so, like ripples in ice, the shortest paths spread from the capital outward.

        for (int i = 0; i < n; i++) {
            if (dist[i] == INF) cout << "INF ";
            else cout << dist[i] << " ";
        }
        cout << "\n";
    }
};

When the last flame of the beacon-fire faded, the ledger was unrolled before the High Council:

If a number was written, it was the fastest possible travel time from the capital to that village.
If INF, it meant the snow had blocked every road to that place — unreachable until the spring thaw.

int main() {
    Dijkstra realm(5);
    realm.addRoad(0, 1, 10);
    realm.addRoad(0, 4, 5);
    realm.addRoad(1, 2, 1);
    realm.addRoad(4, 1, 3);
    realm.addRoad(4, 2, 9);
    realm.addRoad(4, 3, 2);
    realm.addRoad(3, 2, 4);
    realm.addRoad(2, 3, 6);

    realm.shortestPaths(0);
}

The messengers rode, flames guiding them village by village, until the whole kingdom had been warned — in the fastest way possible.

Forem: Harsh Mishra

Kubernetes Networking Finally Explained (From User Pod User)

Kubernetes Networking Finally Explained (From User → Pod → User)

A Complete Real-World Mental Model for Microservices on EKS

The Promise of This Article

Assumptions (Important)

The Core Idea (Read This First)

The Components (High-Level)

Step 1: Your Microservices (The Inside of the Cluster)

Why ClusterIP?

Step 2: The Ingress Controller (The Only Public Door)

What Ingress Is NOT

What Ingress Actually Is

Step 3: The Ingress Needs to Be Exposed (NodePort’s Job)

Critical Clarification

Step 4: AWS Load Balancer (The Front Door)

What ALB Does

What ALB Does NOT Do

What Does ALB Target?

Step 5: The Complete Request Flow (End to End)

Step-by-Step Flow

Where Does /x → x-service Actually Happen?

So Why Not Expose Each Service with NodePort?

Final Correct Mental Model (Lock This In)

One Sentence That Explains Everything

Common Myths (Debunked)

❌ “Services create NodePorts by default”

❌ “Ingress replaces Services”

❌ “Load Balancer balances pods”

❌ “Ingress is between two Services”

Why This Architecture Scales Naturally

Why Kubernetes Feels Hard (But Isn’t)

Final Takeaway

Closing

Mastering RabbitMQ in Microservices: A JavaScript Guide to Async Magic

Mastering RabbitMQ in Microservices: A JavaScript Guide to Async Magic

Introduction: Why Async Messaging Matters

What is RabbitMQ?

Quick: Why Use RabbitMQ?

Core Components of RabbitMQ

Basic Concepts in Depth

Bindings and Routing Keys: The Routing Magic

Client Libraries: JavaScript Focus

Building a Real-World Microservices App: E-Commerce with All Exchange Types

Project Overview (No Full Code – Just the Setup)

1. Shared Config (All Services)

2. Order Service: The Multi-Exchange Producer

3. Inventory Service: Topic + Direct Consumer

4. Shipping Service: Headers + Direct Consumer

5. Email Service: Fanout Consumer

6. Audit Service: Fanout Consumer (Everything Logger)

Producer vs. Consumer Responsibilities: The Golden Rules

Full App Flow: From UI Cart to Confirmation

Wrapping Up: Your Async Superpower

COMPLETE GITLAB CI/CD SPECIFICATION

THE COMPLETE GITLAB CI/CD SPECIFICATION — EVERY SINGLE KEY, SUBKEY & VALUE

0. Top-Level Structure of .gitlab-ci.yml

1. GLOBAL TOP-LEVEL KEYS (NON-JOB)

1.1 stages:

1.2 workflow:

1.3 variables: (top-level defaults)

1.4 default: (default job settings)

1.5 include:

By remote URL

By local file in same repo

By template from GitLab

By artifact from other pipeline

By project/file

1.6 cache: (top-level default cache)

1.7 image: (top-level default)

1.8 services: (top-level default)

1.9 before_script: (top-level default)

List of commands:

1.10 after_script: (top-level default)

1.11 pages: (special top-level job)

2. JOBS (THE HEART OF GITLAB CI/CD)

2.1 script: — REQUIRED for every job

2.2 stage:

2.3 image: (job-level)

2.4 services: (job-level)

Where Does `/x → x-service` Actually Happen?

0. Top-Level Structure of `.gitlab-ci.yml`

1.1 `stages:`

1.2 `workflow:`

1.3 `variables:` (top-level defaults)

1.4 `default:` (default job settings)

1.5 `include:`

1.6 `cache:` (top-level default cache)

1.7 `image:` (top-level default)

1.8 `services:` (top-level default)

1.9 `before_script:` (top-level default)

1.10 `after_script:` (top-level default)

1.11 `pages:` (special top-level job)

2.1 `script:` — REQUIRED for every job

2.2 `stage:`

2.3 `image:` (job-level)

2.4 `services:` (job-level)

2.5 `variables:` (job-level)

2.6 `environment:` (deployment)

2.7 `artifacts:`

2.8 `cache:` (job)

2.9 `rules:` (modern conditional logic)

2.10 `only:` and `except:` (legacy)

2.11 `needs:` (job dependencies + DAG graph)

2.12 `dependencies:` (download artifacts from previous jobs)

2.13 `timeout:`

2.14 `retry:`

2.15 `interruptible:`

2.16 `allow_failure:`

2.17 `tags:`

2.18 `before_script:` / `after_script:` (job-level)

2.19 `parallel:`

2.20 `coverage:` (regex for test coverage)

2.21 `extends:`

2.22 `inherited:`

2.23 `script:` (required)

2.24 `when:` (job-level)

2.25 `resource_group:`

2.26 `trigger:` (trigger downstream pipelines)

2.27 `release:`

2.28 `pages:` (job)

2.29 `script:`

2.30 `coverage:`

2.31 `artifacts:reports:` subkeys

5. DAG PIPELINES (`needs:`)

1. `services:` — ALL SERVICE KEYS, SUBKEYS, AND VALUES

`image`

`build`

`build.context`

`build.args`

`build.ssh`

`command`

`entrypoint`

`working_dir`

`user`

`environment`

`env_file`

`ports`

`expose`

`volumes` (list)