Part 5: Configuration & Persistent Data: Making Kubernetes Enterprise-Ready

In Part 4, we explored Kubernetes networking - how traffic flows securely and efficiently inside and outside the cluster.

Now we move to a topic that truly separates stateless demos from real production systems:

Configuration management and persistent data

Enterprise workloads are not just about running containers.
They are about managing state, secrets, data integrity, and lifecycle guarantees - safely and predictably.

---

The Core Problem Kubernetes Solves

Containers are:

• Ephemeral

• Immutable

• Easily replaceable

But applications need:

• Configuration that changes per environment

• Secrets that must stay secure

• Data that must survive Pod restarts, rescheduling, and failures

Kubernetes solves this using clear abstractions, not hacks.

---

1) ConfigMaps - Externalizing Configuration

ConfigMaps allow you to decouple configuration from container images.

Why this matters

• Same image → Dev, QA, Prod

• No rebuilds for config changes

• Safer deployments

What ConfigMaps store

• Environment variables

• Application config files

• Feature flags (non-sensitive)

Example

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

Used in a Pod:

envFrom:
- configMapRef:
    name: app-config

ConfigMaps make containers portable and environment-aware.

---

2) Secrets - Protecting Sensitive Data

Secrets are used for:

• Database credentials

• API keys

• Certificates

• Tokens

Key principles

• Stored base64-encoded (not encrypted by default)

• Can be encrypted at rest using KMS

• Mounted as env vars or volumes

Example

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

In production, Secrets must be encrypted at rest and access-controlled via RBAC.

---

📦 ConfigMaps vs Secrets (Mental Model)

---

3) Persistent Volumes - Decoupling Storage from Pods

Pods die. Data should not.

Kubernetes introduces PersistentVolumes (PV) and PersistentVolumeClaims (PVC) to abstract storage.

Key idea

Pods request storage — they don’t care where it comes from.

---

PersistentVolume (PV)

• Represents actual storage

• Backed by cloud or on-prem systems

• Managed by cluster administrators or dynamically provisioned

Examples:

• AWS EBS

• EFS

• NFS

• Ceph

---

PersistentVolumeClaim (PVC)

• Storage request by an application

• Defines size, access mode, and storage class

Example:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

PVCs allow developers to consume storage without knowing infrastructure details.

---

4) StatefulSets - Identity + Storage Guarantees

Deployments are great for stateless workloads.
Stateful applications need stronger guarantees.

StatefulSets provide:

• Stable Pod names (db-0, db-1)

• Stable network identities

• Dedicated Persistent Volumes per Pod

• Ordered startup and termination

Ideal for:

• Databases

• Message queues

• Search engines

• Stateful microservices

StatefulSets treat Pods as pets, not cattle — by design.

---

StatefulSet vs Deployment

---

Real-World Enterprise Scenario

Consider a production SaaS platform:

• App configuration stored in ConfigMaps

• Secrets encrypted with cloud KMS

• PostgreSQL deployed as StatefulSet

• Each DB Pod has its own PVC

• Volumes survive Pod restarts and rescheduling

• Backups handled at the storage layer

This design ensures:

• Zero config baked into images

• Secure credential management

• Durable data

• Predictable recovery behavior

---

⚠️ Common Production Pitfalls

• Storing secrets in ConfigMaps ❌

• Hardcoding configs in Docker images ❌

• Using Deployments for databases ❌

• No backup strategy for PVs ❌

• Assuming Pods are long-lived ❌

Kubernetes rewards good abstractions and punishes shortcuts.

---

Final Thought

Enterprise Kubernetes is not about running containers.

It’s about:

• Externalized configuration

• Secure secrets

• Durable storage

• Predictable state management

When these are designed correctly, Kubernetes becomes a platform, not just an orchestrator.

---

What’s Next (Part 6)

In Part 6, we’ll move into:

• Kubernetes security (RBAC, ServiceAccounts)

• Pod Security Standards

• Admission Controllers

• Real-world cluster hardening strategies