# 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

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

Used in a Pod:

```plaintext
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

```plaintext
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)

| Aspect | ConfigMap | Secret |
| --- | --- | --- |
| Sensitive data | ❌ | ✅ |
| Env-specific config | ✅ | ⚠️ |
| Encryption required | ❌ | ✅ |
| Common use | App config | Credentials |

---

## 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:

```plaintext
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

| Feature | Deployment | StatefulSet |
| --- | --- | --- |
| Pod identity | Random | Stable |
| Storage | Shared / optional | Dedicated PVC per Pod |
| Scaling order | Parallel | Ordered |
| Use case | Stateless apps | Stateful systems |

---

## 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