DEV Community: SHARON SHAJI

Why Kubernetes Docs Prefer Headlamp Over the Kubernetes Dashboard

SHARON SHAJI — Sat, 31 Jan 2026 05:34:43 +0000

When people hear “Kubernetes UI”, the first thing that comes to mind is the Kubernetes Dashboard.

It used to be the default choice.

But if you read the official Kubernetes documentation carefully, you’ll notice a shift:

For detailed insight and troubleshooting, tools like Headlamp are preferred.

This isn’t hype. It’s architectural reality.

What Is Headlamp?

It is an open-source Kubernetes UI originally developed by Kinvolk (now part of Microsoft).

It is not a replacement for kubectl.
It is a visual layer on top of the kubectl mental model.

Think of Headlamp as:

kubectl + context
resource relationships
RBAC awareness
CRD visibility

Why Kubernetes Dashboard Is No Longer Enough

Let’s be blunt.

The Kubernetes Dashboard is:

Object-centric
Shallow in insight
Designed for basic operations

It answers:

Is the pod running?
Can I delete this deployment?

It does not answer:

Why is the pod restarting?
Which controller owns this resource?
What RBAC rule is blocking this action?
How do these objects relate to each other?

Modern Kubernetes clusters are systems, not collections of objects.

Why Headlamp Is Preferred

1. Resource Relationships (The Most Important Reason)

Headlamp shows ownership and flow:

Pod → ReplicaSet → Deployment
Service → Endpoints → Pods
Ingress → Service → Workload

This directly matches how Kubernetes works internally.

The Dashboard treats resources as isolated items.

Headlamp treats them as a reconciled system.

2. Matches How Engineers Actually Use Kubernetes

Experienced engineers think in terms of:

namespaces
contexts
YAML
controllers
CRDs

Headlamp:

Shows full YAML
Allows inspection without hiding complexity
Treats CRDs as first-class citizens

The Dashboard tries to abstract YAML away.

That abstraction becomes a problem in real clusters.

3. CRDs and Operators Work Properly

Modern Kubernetes is operator-driven:

Argo CD
Prometheus Operator
Cert-Manager
Istio
KServe

Headlamp:

Auto-discovers CRDs
Displays status fields correctly
Understands custom schemas

Kubernetes Dashboard often:

Ignores CRDs
Renders them poorly
Breaks with non-core resources

That alone disqualifies it for production use.

4. Security Model That Aligns with Kubernetes

Dashboard:

Runs inside the cluster
Requires long-lived service accounts
Encourages risky RBAC shortcuts

Headlamp:

Runs locally or externally
Uses your kubeconfig
Respects RBAC exactly like kubectl

No extra attack surface.
No privileged dashboard pods.

This matches Kubernetes security best practices.

5. Designed for Insight, Not Click-Ops

Dashboard was built for:

“Click buttons to manage resources”

Headlamp is built for:

“Understand what the cluster is doing”

That difference matters when:

debugging production issues
tracing failures
understanding controller behavior

Why Kubernetes Documentation Leans Toward Headlamp

Kubernetes today assumes:

CRDs are everywhere
Operators manage most workloads
YAML is unavoidable
Security matters more than convenience

Headlamp supports how Kubernetes is actually used today, not how it was used years ago.

That’s why it’s preferred for detailed insight.

When the Kubernetes Dashboard Still Makes Sense

Be honest — it’s not useless.

Use Kubernetes Dashboard if:

You are teaching beginners
You want a quick demo
You need very basic visibility

Use Headlamp if:

You run real workloads
You debug failures
You work with operators and CRDs
You care about RBAC and security

Final Takeaway

Kubernetes is complex by design.

A UI that hides that complexity becomes a liability.

Headlamp doesn’t simplify Kubernetes — it explains it.

That’s why Kubernetes documentation points you in that direction.

If you work with production Kubernetes clusters, Headlamp isn’t optional — it’s practical.

Configuration Management in Kubernetes - ConfigMap & Secrets

SHARON SHAJI — Sun, 18 Jan 2026 06:53:00 +0000

Most Kubernetes failures in real systems are not caused by Pods crashing.

They are caused by bad configuration management.

Wrong URLs, leaked secrets, environment drift, manual edits — these silently break systems.

Kubernetes provides first-class tools to manage configuration properly.

If you ignore them, your cluster will eventually become unmanageable.

This post explains:

What configuration management means in Kubernetes
Why it is critical
What tools Kubernetes provides
Real, simple examples
Common mistakes to avoid

What Is Configuration Management in Kubernetes?

Configuration management is the practice of separating application behavior from application code.

In Kubernetes terms:

Code → container image
Configuration → Kubernetes resources

This allows:

Same image across environments
Config changes without rebuilding images
Safer secret handling
Predictable deployments

Why Configuration Management Is Critical

Without proper configuration management:

You rebuild images for every config change
Secrets leak into Git repositories
Dev, Alpha,UAT,staging, and prod drift apart
Rollbacks become painful
Debugging becomes guesswork

Kubernetes assumes configuration will change often — images should not.

Configuration vs Code (Key Principle)

Images should be immutable

Configuration should be external

If you violate this rule, Kubernetes loses most of its value.

Configuration Tools in Kubernetes

Kubernetes provides multiple ways to manage configuration:

ConfigMaps – non-sensitive configuration
Secrets – sensitive data
Environment variables
Mounted configuration files
Helm values / Kustomize overlays
CRDs (advanced use cases)

This post focuses on the core building blocks.

ConfigMaps: Managing Application Configuration

A ConfigMap stores non-sensitive configuration data as key–value pairs.

Typical use cases:

Environment name
Ports
Feature flags
Service URLs
Log levels

Example: ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_ENV: production
  APP_PORT: "8080"
  LOG_LEVEL: info

Apply it:

kubectl apply -f configmap.yaml
kubectl get configmap app-config

At this point:

Kubernetes stores the configuration
No pod behavior changes yet

Using ConfigMap as Environment Variables

apiVersion: v1
kind: Pod
metadata:
  name: app-pod
spec:
  containers:
    - name: app
      image: nginx
      envFrom:
        - configMapRef:
-

Inside the container:

echo $APP_ENV
echo $APP_PORT

Using ConfigMap as Files (then no restart of service to apply)

apiVersion: v1
kind: Pod
metadata:
  name: config-file-pod
spec:
  containers:
    - name: app
      image: nginx
      volumeMounts:
        - name: config-volume
          mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: app-config

Files created:

/etc/config/APP_ENV
/etc/config/APP_PORT
/etc/config/LOG_LEVEL

Secrets: Managing Sensitive Configuration

A Secret stores sensitive data such as:

Passwords
API keys
Tokens
Certificates

Secrets are base64-encoded, not encrypted by default.

Example: Secret

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  DB_USER: YWRtaW4=
  DB_PASSWORD: cGFzc3dvcmQ=

Create it:

kubectl apply -f secret.yaml
kubectl get secret db-secret

Using Secret in a Pod

apiVersion: v1
kind: Pod
metadata:
  name: secret-pod
spec:
  containers:
    - name: app
      image: nginx
      envFrom:
        - secretRef:
            name: db-secret

Or as files:

volumeMounts:
  - name: secret-volume
    mountPath: /etc/secret
    readOnly: true
volumes:
  - name: secret-volume
    secret:
      secretName: db-secret

ConfigMaps vs Secrets

Feature	ConfigMap	Secret
Sensitive data	❌	✅
Base64 encoded	❌	✅
Access controlled	Limited	Stronger
Git-friendly	✅	❌
Use case	App config	Credentials

Rule of thumb:

If it can hurt you when leaked → use a Secret.

Environment-Based Configuration (Best Practice)

One image, multiple environments:

dev:
  LOG_LEVEL=debug
  DB_HOST=dev-db

prod:
  LOG_LEVEL=info
  DB_HOST=prod-db

Only configuration changes — image stays the same.

Configuration Drift (Real Problem)

Configuration drift happens when:

Someone edits live resources manually
Config differs between environments
No source of truth exists

Solution:

Store manifests in Git
Apply changes declaratively
Avoid kubectl edit in production

Common Configuration Management Mistakes

Hardcoding config inside images
Storing secrets in ConfigMaps
Committing secrets to Git
Rebuilding images for config changes
Treating base64 as encryption

These mistakes will hurt you later.

When ConfigMaps & Secrets Are Not Enough

For complex systems, teams use:

Helm + values.yaml
Kustomize overlays
External secret managers (Vault, AWS Secrets Manager)
CRDs for advanced configuration APIs

But ConfigMaps and Secrets are still the foundation.

Final Takeaway

Good configuration management keeps Kubernetes sane

Bad configuration management breaks everything quietly

If you master:

ConfigMaps
Secrets
Environment-based configuration

You eliminate a massive class of production failures.

Say it clearly.

Kubernetes Custom Resources, Custom Resource Definition (CRD) & Controllers

SHARON SHAJI — Sun, 18 Jan 2026 04:34:43 +0000

Kubernetes is not powerful because of Pods or Services.

It’s powerful because it can be extended without modifying Kubernetes itself.

That extensibility comes from Custom Resources + CRDs + Controllers.

If you don’t understand these three properly, you’re not really using Kubernetes — you’re just deploying YAML.

Why CRDs Exist

Kubernetes solves generic infrastructure problems:

Scheduling
Networking
Storage
Scaling

But real companies have domain-specific problems:

“Deploy a model”
“Provision a database”
“Create a service mesh rule”
“Manage certificates”

Instead of hardcoding these into Kubernetes, Kubernetes gives us a way to define our own APIs.

That framework is:

CRD → defines a new API type
Custom Resource → instance of that API
Controller → logic that makes it real

Mental Model (Important)

Kubernetes itself does nothing with your CRDs

It only stores them.

If you create a CRD without a controller, Kubernetes will happily accept it and do absolutely nothing.

That’s not a bug. That’s the design.

What Is a Custom Resource (CR)?

A Custom Resource is a new object type in Kubernetes.

Just like:

Pod
Service
Deployment

You can create your own:

Database
Application
MLModel
Certificate
Gateway

Example:

kubectl get databases
kubectl apply -f myapp.yaml

Kubernetes doesn’t care what Database means.

What Is a CRD (CustomResourceDefinition)?

A CRD defines a new API schema inside Kubernetes.

Think of a CRD as:

“Hey Kubernetes, here is a new kind of object. Please store it.”

CRD defines:

API group
Version
Kind
Schema (validation)

Simple CRD Example

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: databases.mycompany.io
spec:
  group: mycompany.io
  scope: Namespaced
  names:
    plural: databases
    singular: database
    kind: Database
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                engine:
                  type: string
                version:
                  type: string
                storage:
                  type: string

After applying this:

kubectl get databases

Kubernetes now recognizes Database as a valid object — nothing more.

Creating a Custom Resource (CR)

apiVersion: mycompany.io/v1
kind: Database
metadata:
  name: user-db
spec:
  engine: postgres
  version: "15"
  storage: 20Gi

Apply it:

kubectl apply -f database.yaml

Result:

Stored in etcd
No Pod created
No database started

This is where most beginners get confused.

Why Controllers Are Mandatory

A Controller is the brain.

It:

Watches Custom Resources
Compares desired state vs actual state
Reconciles the difference

Without a controller:

CRD = dead schema
CR = useless YAML

Controller Reconciliation Loop

Every controller follows this loop:

Observe → Compare → Act → Repeat

Or in plain terms:

while true:
  desired_state = CR.spec
  actual_state = cluster_reality
  if desired_state != actual_state:
    fix_it()

This loop never stops.

How CRD + Controller Work Together

User
 |
 | kubectl apply
 v
Kubernetes API Server
 |
 v
etcd (stores CR)
 |
 v
Controller watches CR
 |
 v
Controller creates / updates:
  - Pods
  - Services
  - PVCs
  - ConfigMaps

Real Example: Database Operator

Custom Resource

apiVersion: mycompany.io/v1
kind: Database
metadata:
  name: user-db
spec:
  engine: postgres
  version: "15"
  storage: 20Gi

Controller Logic

IF Database CR is created:
  - Create StatefulSet
  - Create PVC
  - Create Service

IF Database CR is deleted:
  - Cleanup resources

Kubernetes doesn’t know databases.

Your controller does.

Desired vs Actual State

Desired State (CR):
  Database:
    engine: postgres
    replicas: 1

Actual State (Cluster):
  StatefulSet: missing

Controller Action:
  Create StatefulSet

If someone deletes the StatefulSet manually?

➡️ Controller recreates it.

CRDs vs Deployments

Feature	Deployment	CRD
Built-in	Yes	No
Controller included	Yes	Only if you write one
Logic location	Kubernetes	You

A Deployment is just a CRD + controller shipped by Kubernetes.

Istio Uses CRDs

Istio extends Kubernetes using CRDs like:

VirtualService
DestinationRule
Gateway

Example:

kind: VirtualService
spec:
  hosts:
  - myapp
  http:
  - route:
    - destination:
        host: myapp-v2

Istio controllers convert this into:

Envoy config
Traffic routing
Load balancing

Istio doesn’t modify Kubernetes.

It extends it properly.

Why Companies Build Products Using CRDs

CRDs allow:

Kubernetes-native APIs
Declarative behavior
kubectl-first UX
Strong reconciliation guarantees

Used by:

ArgoCD
Crossplane
Cert-Manager
Prometheus Operator
Istio

All follow the same pattern.

Common Mistakes

“CRD automatically creates resources”
Writing logic inside YAML
Ignoring .status fields
Treating CRDs as config files

CRDs are APIs, not configs.

When Should You Use CRDs?

Use CRDs when:

You manage lifecycle, not just deployment
You need reconciliation
You’re building a platform

Do not use CRDs for:

Static configs
One-time jobs
Simple values

Final Takeaway

CRDs define WHAT you want

Controllers define HOW it happens

Kubernetes enforces the loop

If you understand this, you understand Kubernetes beyond YAML.

🔐 TLS Termination Models - SSL Passthrough vs SSL Termination (Offloading) vs SSL Bridging (Re-Encryption)

SHARON SHAJI — Sat, 10 Jan 2026 06:33:29 +0000

Why They Exist, Why They’re Used, and When Each Matters

TLS is not just “turning on HTTPS.”

Where TLS is terminated defines:

👁️ Who can see the traffic
🛡️ What security controls are possible
📈 How scalable your system is
📋 Whether auditors will sign off

That’s why multiple TLS termination models exist.

🌐 Why TLS Termination Models Exist

Because no single model can optimize all of these at once:

🔐 Security
⚙️ Operability
📈 Scalability
🔍 Traffic visibility
💰 Cost efficiency

Each TLS termination model trades one dimension for another.

Understanding these trade-offs prevents:

Over-engineered designs
Weak security assumptions
“Best-practice” architectures that fail in production

1️⃣ SSL Passthrough (End-to-End TLS)

The proxy or load balancer does NOT decrypt TLS.

Encrypted traffic is forwarded directly to the backend.

Architecture Diagram

  Client
    |
    | HTTPS (TLS)
    v
Load Balancer (Layer 4 – no decryption)
    |
    | HTTPS (TLS)
    v
Backend Application (TLS terminates here)

🎯 Why It Exists

Maintain true end-to-end encryption
Enforce zero-trust networking
Keep TLS fully owned by the application

🧪 Examples

gRPC services with mTLS
Banking and healthcare backends
Kubernetes Ingress with SSL Passthrough enabled

✅ Why It Matters

No intermediate system can inspect or modify traffic
Required for strict compliance environments

⚠️ Trade-offs

❌ No path-based routing
❌ No WAF, authentication, or rate limiting
❌ Certificate management per backend

Best when: Security > operability

Avoid when: Traffic inspection is required

2️⃣ SSL Termination / SSL Offloading (Most Common)

TLS is terminated at the proxy or load balancer.

Backend traffic becomes plain HTTP.

Architecture Diagram

    Client
      |
      | HTTPS
      v
Load Balancer / Reverse Proxy (TLS ends here)
      |
      | HTTP
      v
Backend Application

🎯 Why It Exists

Centralized certificate management
Simplified backend services
Enables Layer-7 traffic handling

🧪 Examples

AWS ALB / ELB
Nginx Ingress Controller
HAProxy, Envoy

✅ Why It Matters

TLS must be decrypted to enable:

Path-based routing (/api, /auth)
WAF and rate limiting
Authentication and observability

⚠️ Trade-offs

❌ Backend traffic is unencrypted
❌ Internal network must be trusted

💡 This model powers most production SaaS platforms today.

3️⃣ SSL Bridging / Re-Encryption (Best of Both, Costs More)

TLS terminates at the proxy, and a new TLS session is created to the backend.

Architecture Diagram

    Client
      |
      | HTTPS
      v
Proxy / Load Balancer (TLS #1 terminates)
      |
      | HTTPS (TLS #2 starts)
      v
Backend Application\

🔑 Key Characteristics

Two TLS sessions
Proxy can inspect traffic
Backend still receives encrypted traffic

✅ Pros

End-to-end encryption preserved
Full Layer-7 features at the proxy
Strong compliance posture

❌ Cons

Extra CPU overhead (double TLS)
Certificates required at both proxy and backend
Harder debugging and troubleshooting

🧭 When to Use

Regulated environments (PCI-DSS, HIPAA)
Kubernetes ingress with security mandates
Zero-trust internal networks

❌ Common Misconceptions

SSL termination is insecure.

False, if the internal network is controlled.

SSL passthrough is always better.

False, if routing or inspection is required.

SSL bridging is free security.

False — it costs CPU, latency, and operational effort.

🧭 Practical Recommendation (No BS)

Simple public apps / Maximum simplicity → SSL Termination
Compliance-heavy systems / Security + control → SSL Bridging
Strict zero-trust / mTLS / Maximum secrecy → SSL Passthrough

If you can’t clearly explain why you chose one,

you probably chose the wrong model.

📊 Comparison Table

Feature	SSL Passthrough	SSL Termination	SSL Bridging
TLS decrypted at proxy	❌	✅	✅
Backend traffic encrypted	✅	❌	✅
HTTP routing / WAF	❌	✅	✅
Certificate management	Backend	Centralized	Both
Operational complexity	High	Low	High
Security level	🔒🔒🔒	🔒🔒	🔒🔒🔒

🧠 Final Takeaway

SSL/TLS termination models exist because:

Security, visibility, scalability, and cost cannot all be optimized at once.

There is no universal best practice —

only context-correct architectural decisions.

Kubernetes Ingress Explained — Routing, TLS, and Real Examples

SHARON SHAJI — Fri, 26 Dec 2025 03:47:55 +0000

Kubernetes networking looks confusing until you understand Ingress.
Kubernetes networking looks confusing until you understand Ingress.

Most confusion happens because people mix Service exposure with HTTP routing.
Ingress exists to solve one specific problem — how HTTP/HTTPS traffic enters your cluster.

This post explains Kubernetes Ingress using production-relevant concepts, with text diagrams and real examples.

What Problem Does Ingress Solve?

Without Ingress

Every Service needs its own NodePort or LoadBalancer
- Each application must be exposed individually instead of sharing one entry point.
Costs increase (cloud load balancers are not free)
- If you have 100 Services, you need 100 LoadBalancers.
- That means 100 public IP addresses and 100 separate billing items from the cloud provider.
Routing logic lives outside Kubernetes
- Traffic routing is handled by external load balancers or manual DNS rules.
- Kubernetes has no visibility or control over how traffic is routed.
TLS management becomes messy
- Each Service needs its own TLS certificate.
- Certificates must be renewed, rotated, and configured per Service.
- Managing HTTPS for dozens of Services becomes error-prone and hard to scale.

Ingress solves this by acting as a smart HTTP entry point.

What Is Kubernetes Ingress?

An Ingress is a Kubernetes resource that defines HTTP and HTTPS routing rules.

Ingress can:

Route traffic by host
Route traffic by path
Terminate TLS (HTTPS)
Forward traffic to Services

⚠️ Ingress does NOT handle traffic by itself.

It requires an Ingress Controller.

Ingress Controller (Critical Concept)

An Ingress Controller is the actual component that:

Listens for external traffic
Reads Ingress rules
Routes traffic accordingly

Common controllers:

NGINX Ingress Controller
Traefik
HAProxy
Cloud-specific controllers (AWS ALB Ingress)

Without a controller, Ingress resources do nothing.

How Ingress Works

Client (Browser)
            ↓
Ingress Controller (NGINX / Traefik)
           ↓
Ingress Rules
           ↓
Service
           ↓
Pods (Deployment)

Ingress operates at Layer 7 (HTTP/HTTPS).

Basic Ingress Example (Single Service)

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
spec:
  rules:
    - host: app.sharon.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: app-service
                port:
                  number: 80

What this does

Accepts traffic for app.sharon.com
Routes all requests to app-service(k8s service name)
Service load balances traffic to Pods

Path-Based Routing Example

Ingress can route different paths to different Services.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: multi-app-ingress
spec:
  rules:
    - host: sharon.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 80
          - path: /web
            pathType: Prefix
            backend:
              service:
                name: web-service
                port:
                  number: 80

Routing Behaviour

sharon.com/api  → api-service
sharon.com/web  → web-service

Host-Based Routing Example

Ingress can route traffic by domain name.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: host-ingress
spec:
  rules:
    - host: api.sharon.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 80
    - host: web.sharon.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-service
                port:
                  number: 80

Routing Behaviour

api.sharon.com → api-service
web.sharon.com → web-service

TLS / HTTPS with Ingress

Ingress can terminate TLS using Kubernetes Secrets.

Ingress can handle HTTPS (TLS) termination for your applications using Kubernetes Secrets.

This means HTTPS is handled at the Ingress level, not inside the application Pods.

TLS Secert

kubectl create secret tls app-tls \
  --cert=cert.pem \
  --key=key.pem

Ingress with TLS*

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tls-ingress
spec:
  tls:
    - hosts:
        - app.sharon.com
      secretName: app-tls
  rules:
    - host: app.sharon.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: app-service
                port:
                  number: 80

What this does

Terminates HTTPS at the Ingress Controller
Traffic inside the cluster remains HTTP
TLS certificates are centrally managed

Ingress vs LoadBalancer

Feature	Ingress	LoadBalancer
Layer	L7 (HTTP/HTTPS)	L4
Routing	Host & path based	No
TLS	Yes	Limited
Cost	Low (single load balancer)	High (per Service)
Scalability	High	Limited

Ingress is preferred for HTTP-based applications.

Common Mistakes

Creating Ingress without an Ingress Controller
Using LoadBalancer for every Service
Forgetting DNS configuration
Mixing Service exposure and routing logic
Managing TLS separately for every Service

When You Should Use Ingress

Use Ingress when:

You run HTTP/HTTPS applications
You need routing by domain or path
You want centralized TLS management
You want to reduce cloud load balancer costs

Final Complete Flow

Internet
   |
   v
DNS (Domain → IP)
   |
   v
Ingress Controller (NGINX / Traefik)
   |
   v
Ingress Rules (Host / Path / TLS)
   |
   v
Service (Stable Endpoint)
   |
   v
Pods (Managed by Deployment)

Without Ingress

Every Service needs its own NodePort or LoadBalancer
- Each application must be exposed individually instead of sharing one entry point.
Costs increase (cloud load balancers are not free)
- If you have 100 Services, you need 100 LoadBalancers.
- That means 100 public IP addresses and 100 separate billing items from the cloud provider.
Routing logic lives outside Kubernetes
- Traffic routing is handled by external load balancers or manual DNS rules.
- Kubernetes has no visibility or control over how traffic is routed.
TLS management becomes messy
- Each Service needs its own TLS certificate.
- Certificates must be renewed, rotated, and configured per Service.
- Managing HTTPS for dozens of Services becomes error-prone and hard to scale.

Final Thought

Ingress is not optional in production — it is the control plane for HTTP traffic in Kubernetes.

Stop Memorizing Kubernetes: Pods, Deployments, and Services Explained

SHARON SHAJI — Thu, 18 Dec 2025 05:22:29 +0000

Kubernetes feels complicated mostly because its core concepts are poorly explained.
This post explains Pods, Deployments, Services, and Ingress using only production-relevant details, with real YAML examples.

1️⃣ Kubernetes Pod

What is a Pod?

A Pod is the smallest deployable unit in Kubernetes.

A pod can run one or more containers
Containers inside a pod:
- Share the same IP address
- Communicate using localhost
- Share storage volumes
Kubernetes schedules pods, not containers

Pods are ephemeral by design.

Pod Example

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

What this does

Runs a single NGINX container
Exposes port 80 inside the pod
Assigns a temporary IP address

⚠️ If this pod crashes, Kubernetes will not recreate it automatically.

That is why pods are not used directly in production.

2️⃣ Kubernetes Deployment

What is a Deployment?

A Deployment is a controller that creates, manages, and maintains Pods.

It exists to solve the problems Pods have.

A Deployment provides:

Automatic pod recreation (self-healing)
Horizontal scaling using replicas
Rolling updates with zero downtime
Rollback to a previous version if something breaks

In real systems, you deploy Deployments, not Pods.

Deployment Example

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

What this does

Runs 3 identical Pods
Automatically replaces failed Pods
Ensures the desired state is always maintained

If one Pod crashes, Kubernetes creates a new Pod automatically.

Scaling a Deployment

kubectl scale deployment nginx-deployment --replicas=5

Kubernetes adds or removes Pods without downtime.

3️⃣ Kubernetes Service

Why Services Exist

Pods have fundamental limitations:

Pod IP addresses are not stable
Pods can be destroyed and recreated at any time

Because of this, you should never access Pods directly.

A Service provides:

A stable virtual IP address
Built-in load balancing
DNS-based service discovery

How Services Work

A Service selects Pods using labels
Traffic sent to the Service is distributed across matching Pods
Clients never need to know Pod IP addresses

Common Service Types

Type	Purpose
ClusterIP	Internal cluster communication (default)
NodePort	External access via node IP and port
LoadBalancer	Cloud-managed external access

ClusterIP Service Example

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

What this does

Creates a stable internal endpoint (nginx-service)
Load balances traffic across all matching Pods
Decouples clients from Pod lifecycles

NodePort Service Example

apiVersion: v1
kind: Service
metadata:
  name: nginx-nodeport
spec:
  type: NodePort
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 80
      nodePort: 30080

How to access

http://<node-ip>:30080

NodePort is useful for testing and demos, but not ideal for production.

LoadBalancer Service Type

A LoadBalancer Service exposes an application externally using a cloud provider’s load balancer.

Automatically assigns a public IP
Distributes traffic across Pods
Works only on cloud Kubernetes clusters (AWS, Azure, GCP)

LoadBalancer Example

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

What this does

Creates a cloud-managed external load balancer
Assigns a public IP address
Load balances traffic across Pods

Get the external IP:

kubectl get svc nginx-loadbalancer

LoadBalancer is simple for direct exposure, but Ingress is preferred for large-scale HTTP applications.

Final Summary

Pod → Smallest runtime unit, temporary by nature
Deployment → Manages Pods, ensures availability and scaling
Service → Stable networking and load balancing
Ingress → HTTP/HTTPS routing with a single entry point
LoadBalancer → Cloud-based external exposure

Each component solves a specific problem.

Using the right one at the right place is what makes Kubernetes manageable.

Final Thought

Kubernetes is not complicated — unclear explanations make it look that way.

Once Pods, Deployments, Services, and Ingress are understood as building blocks, the rest of Kubernetes becomes predictable.

Modern Logging with Grafana Alloy + Loki

SHARON SHAJI — Wed, 26 Nov 2025 05:19:00 +0000

A guide to collect Docker and host logs using Grafana Alloy + Loki, and why Alloy is replacing Promtail. Includes diagrams, permissions, docker-compose, and config files.

Containers made deployments fast, portable, and efficient.

But collecting logs from hosts + containers + services quickly becomes chaotic.

That’s why the modern stack uses Grafana Alloy + Loki instead of the older Promtail-based approach.

🧠 Why Grafana Loki Uses Alloy Instead of Promtail

Promtail served its purpose well — but infrastructure evolved.

Grafana introduced Alloy as its unified, modern, extensible telemetry collector.

🔥 Promtail vs Alloy (Honest Breakdown)

Feature	Promtail	Alloy
Log Collection	✔️ Yes	✔️ Yes
Metrics Collection	❌ No	✔️ Yes
Traces Collection	❌ No	✔️ Yes
Unified pipeline	❌	✔️ Logs + Metrics + Traces
Docker auto-discovery	Limited	✔️ Excellent
Processing pipeline	Basic	✔️ Powerful
Extensibility	Low	✔️ High
Future support	🟥 Legacy	🟩 Actively developed

📌 The real reason Alloy replaces Promtail

Promtail = log-only agent

Alloy = one collector for logs, metrics, and traces

Promtail is now maintenance-only.

Alloy is the future.

🧩 Architecture Overview

The logging pipeline includes:

Alloy → collector
Loki → log store
Grafana → visualization

🔥 High-level workflow

Host Logs → Alloy → Loki → Grafana

Docker Logs → Alloy → Loki → Grafana

🧱 Architecture Diagram (Text View)

                  ┌───────────────────────┐
                  │        Grafana        │
                  │  (Dashboards + Logs)  │
                  └──────────┬────────────┘
                             │
                    ┌────────┴─────────┐
                    │       Loki       │
                    │    (Log Store)   │
                    └────────┬─────────┘
                             │
            ┌────────────────┴────────────────┐
            │              Alloy              │
            │   (Unified Telemetry Collector) │
            └───────────┬───────────┬─────────┘
                        │           │
                 Host Logs      Docker Logs
             (/var/log/*)   (via Docker Engine)
                            (/var/lib/docker/containers/*)

📁 Folder Structure

/opt/alloy/
├── alloy/
│ └── config.alloy
├── grafana-data/
├── loki/
│ └── loki-config.yaml
├── loki-data/
└── docker-compose.yml

🔐 Required Permissions (Critical)

Loki & Grafana will fail without correct folder ownership.

Loki storage (UID/GID 10001)

sudo mkdir -p /opt/alloy/loki-data
sudo chown -R 10001:10001 /opt/alloy/loki-data

sudo mkdir -p /opt/alloy/grafana-data
sudo chown -R 472:472 /opt/alloy/grafana-data

🐳 docker-compose.yaml (Production Ready)

services:
  loki:
    image: grafana/loki:3.1.0
    container_name: loki
    command: -config.file=/etc/loki/local-config.yaml
    volumes:
      - ./loki/loki-config.yaml:/etc/loki/loki-config.yaml:ro
      - ./loki-data:/loki
    ports:
      - "3100:3100"

  alloy:
    image: grafana/alloy:latest
    container_name: alloy
    privileged: true
    volumes:
      - ./alloy/config.alloy:/etc/alloy/config.alloy:ro
      - /var/run/docker.sock:/var/run/docker.sock
      - /var/log:/var/log:ro
    ports:
      - "12345:12345"

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    volumes:
      - ./grafana-data:/var/lib/grafana    
  ports:
      - "3000:3000"

⚙️ config.alloy


### Send Alloy’s internal logs to Loki
logging {
  level  = "info"
  format = "logfmt"
  write_to = [loki.relabel.alloy_logs.receiver]
}

### Auto-discover Docker containers
discovery.docker "local_docker" {
  host = "unix:///var/run/docker.sock"
}

### Match host logs (/var/log/*log)
local.file_match "host_logs" {
  path_targets = [
    { __path__ = "/var/log/*log" },
  ]
}

### Tail host logs
loki.source.file "host_tail" {
  targets    = local.file_match.host_logs.targets
  forward_to = [loki.process.host_pipeline.receiver]
}

### Add static labels to host logs
loki.process "host_pipeline" {
  forward_to = [loki.write.local.receiver]

  stage.static_labels {
    values = {
      job     = "varlogs",
      source  = "host",
      env     = "dev",
    }
  }
}

### Collect logs from Docker containers (stdout/stderr)
loki.source.docker "docker_engine" {
  host = "unix:///var/run/docker.sock"

  targets = discovery.docker.local_docker.targets

  labels = {
    job     = "docker_logs",
    env     = "dev",
    cluster = "local",
  }

  forward_to = [loki.write.local.receiver]
}

### Loki ingest endpoint
loki.write "local" {
  endpoint {
    url = "http://loki:3100/loki/api/v1/push"
  }
}

### Add label to internal Alloy logs
loki.relabel "alloy_logs" {
  forward_to = [loki.write.local.receiver]

  rule {
    target_label = "service"
    replacement  = "alloy"
  }
}

loki-config.yaml

auth_enabled: false

server:
  http_listen_port: 3100
  grpc_listen_port: 9096

common:
  instance_addr: 127.0.0.1
  path_prefix: /loki
  storage:
    filesystem:
      chunks_directory: /loki/chunks
      rules_directory: /loki/rules
  replication_factor: 1
  ring:
    kvstore:
      store: inmemory

query_range:
  results_cache:
    cache:
      embedded_cache:
        enabled: true
        max_size_mb: 100

limits_config:
  ingestion_rate_mb: 10
  ingestion_burst_size_mb: 20
  max_concurrent_tail_requests: 20
  max_cache_freshness_per_query: 10m
  max_streams_per_user: 50
  allow_structured_metadata: false

schema_config:
  configs:
    - from: 2024-01-01
      store: tsdb
      object_store: filesystem
      schema: v13
      index:
        prefix: index_
        period: 24h

🚀 Restart and Run

docker compose up -d

✔ All Docker logs collected
✔ All host logs collected
✔ Alloy logs included with label service=alloy
✔ Grafana fully functional
✔ No permission errors
✔ Production-grade observability pipeline

Alloy replaces Promtail and simplifies the entire telemetry ecosystem — logs, metrics, traces — in one place.

🚀 Kubernetes Architecture Explained.

SHARON SHAJI — Fri, 07 Nov 2025 05:57:21 +0000

Containers revolutionized software delivery — fast, portable, and reliable.

But managing hundreds of containers across servers? That’s where Kubernetes (K8s) comes in.

Let’s explore the complete architecture of Kubernetes, why it’s used, and how it powers modern cloud infrastructure. 🌩️

🧠 What is Kubernetes?

Kubernetes (K8s) is an open-source container orchestration platform originally developed by Google and now maintained by the Cloud Native Computing Foundation (CNCF).

It automates:

🧩 Deployment of containers
⚙️ Scaling and load balancing
🛠️ Self-healing and rolling updates
🔐 Configuration and secrets management

In short:

Kubernetes ensures your containerized applications run exactly as intended — automatically and reliably.

🧩 Kubernetes Core Architecture Overview

Kubernetes is built on two major layers:

Control Plane (Master) → Brains of the cluster
Worker Nodes → Muscles that actually run workloads

Let’s break them down 👇

🧠 1️⃣ Control Plane (Master Components)

These components manage the overall cluster state.

Component	Description
API Server (`kube-apiserver`)	The front door of the cluster. Handles REST requests, validates configuration, and updates the cluster state in `etcd`.
etcd	A distributed key-value store that holds all cluster data (desired & current state). Acts as the source of truth.
Scheduler (`kube-scheduler`)	Decides which node runs a new Pod based on available resources and policies.
Controller Manager (`kube-controller-manager`)	Ensures the cluster matches the desired configuration (e.g., if a Pod fails, it starts a new one).
Cloud Controller Manager	Connects Kubernetes with underlying cloud services like load balancers and storage.

💪 2️⃣ Worker Nodes (Data Plane)

Worker nodes actually run your containers.

Each node runs the following key components:

Component	Description
Kubelet	Node agent that ensures containers are running as per the API server’s instructions.
Kube Proxy	Manages networking, traffic routing, and load balancing between services.
Container Runtime	Runs containers (e.g., Docker, containerd, CRI-O). Responsible for pulling images and starting containers.

🧱 3️⃣ Kubernetes Objects

Kubernetes uses declarative configuration files (YAML) to manage workloads.

Object	Description
Pod 🧫	The smallest deployable unit; runs one or more containers together.
ReplicaSet 🔁	Ensures the desired number of identical Pods are always running.
Deployment 🚀	Manages rollout, rollback, and scaling of applications.
Service 🔗	Provides stable networking and load balancing between Pods.
ConfigMap / Secret 🔐	Externalize configuration and sensitive data.
Ingress 🌍	Routes external HTTP(S) traffic to internal services.
Namespace 📦	Organizes cluster resources logically for isolation.

🏗️ 6️⃣ Kubernetes Architecture Diagram (Text View)



               ┌──────────────────────────┐
               │     Load Balancer (LB)   │
               └──────────────┬───────────┘
                              │
         ┌────────────────────┴──────────────────────┐
         │            Control Plane Nodes            │
         │ (API Server, etcd, Scheduler, Controllers)│
         └────────────────────┬──────────────────────┘
                              │
         ┌────────────────────┴──────────────────────┐
         │              Worker Nodes                 │
         │ (Kubelet, Kube Proxy, Containers/Pods)    │
         └────────────────────┬──────────────────────┘
                              │
                ┌─────────────┴─────────────┐
                │     Services & Ingress    │
                └─────────────┬─────────────┘
                              │
                        User Traffic 🌍

🚀 Kubernetes Explained — What It Is, Why It’s Used, and How It Differs from Docker

SHARON SHAJI — Fri, 07 Nov 2025 02:14:45 +0000

If you’ve ever wondered “What exactly is Kubernetes?” or “How is it different from Docker?”, you’re not alone.

Let’s break it down step by step — in simple terms but with real DevOps depth 👇

🧠 What is Kubernetes?

Kubernetes (K8s) is an open-source container orchestration platform developed by Google and maintained by the Cloud Native Computing Foundation (CNCF).

In simpler words:

Kubernetes is like the brain of your containerized infrastructure — it automatically decides where, when, and how your containers should run.

⚙️ Why Do We Need Kubernetes?

Before Kubernetes, developers used Docker to package applications into containers — which was great…

Until you had hundreds of containers running across dozens of servers 😬

Managing them manually became chaotic — think:

Restarting crashed containers 🧩
Balancing traffic between services ⚖️
Updating apps without downtime 🚀
Scaling up under heavy load 📈

That’s where Kubernetes comes in.

It automates all of these complex tasks with precision and intelligence.

💡 Key Benefits of Kubernetes

Feature	Description
Automation 🤖	Automatically deploys, restarts, and scales containers.
Self-healing	Restarts failed containers and replaces unhealthy nodes.
Load Balancing ⚖️	Distributes traffic evenly across Pods.
Scalability 📈	Scales apps up/down automatically based on metrics.
Rolling Updates 🔁	Updates apps without downtime.
Portability 🌎	Runs anywhere — cloud, on-premises, or hybrid.
Resource Efficiency ⚙️	Optimizes CPU and memory across workloads.

🧩 Kubernetes Core Components (Simplified)

Here’s how a Kubernetes cluster is structured 👇

Layer	Components	Function
Control Plane 🧠	API Server, Scheduler, Controller Manager, etcd	Makes global decisions (what should run, where, and how).
Worker Nodes 💪	Kubelet, Kube Proxy, Container Runtime	Actually run your containers and handle networking.
Objects 📦	Pods, Deployments, Services, Ingress	Define what applications run and how users access them.

In short:

The Control Plane manages the cluster.

The Worker Nodes execute workloads.

🐳 Kubernetes vs Docker — The Big Question

People often say “Kubernetes vs Docker”, but actually, they’re not competitors.

They solve different problems in the container ecosystem.

🧩 Feature	Docker	Kubernetes (K8s)
Purpose	Containerization platform	Container orchestration system
Function	Builds and runs containers	Manages and scales containers
Focus	Single container lifecycle	Multiple containers across clusters
Scope	Developer-level tool	Cluster-level management
Networking	Simple bridge network	Advanced service networking (CNI, Ingress)
Scaling	Manual scaling	Auto-scaling based on CPU/Memory metrics
Self-healing	Not supported	Automatically replaces failed Pods
Storage Management	Limited volumes	Persistent Volumes & dynamic storage
Load Balancing	Needs manual setup	Built-in service load balancing

🧠 In Summary:

Docker = How you build and run containers 🐋
Kubernetes = How you orchestrate and manage containers across multiple servers ☸️

Understanding Logrotate — The Silent Hero of Linux Logs

SHARON SHAJI — Thu, 06 Nov 2025 05:26:56 +0000

Ever wondered how Linux systems manage logs so efficiently without filling up disk space?

That’s where Logrotate comes in — a simple yet powerful tool that automatically handles log file rotation, compression, and cleanup.

🧠 What Logrotate Does:

Rotates logs based on size or time
Compresses old logs to save disk space
Deletes outdated logs automatically
Keeps your services running smoothly — no restarts needed!

💡 Example:
If your application writes to /var/log/app.log, Logrotate can:

Rename it to app.log.1, app.log.2.gz, etc.

Create a new, clean app.log for fresh entries

Remove older files after a few rotations

⚙️ Why It Matters:

In production environments — especially with Docker, web servers, or microservices — logs can grow to gigabytes quickly.
Without Logrotate, this can lead to disk full errors and potential downtime.
With it, space is freed automatically — no system or service restart required.

📊 Integrate Logrotate with Docker volumes or systemd units for complete automation across environments.

> “Logrotate silently keeps your servers clean, efficient, and logging — without ever needing a restart.”