DEV Community

Aisalkyn Aidarova
Aisalkyn Aidarova

Posted on

Production-Grade K8s — Configs, Networking, and Health

1. Decoupling Code from Configuration (ConfigMaps & Secrets)

In a true DevOps pipeline, you never hardcode database URLs or passwords inside your container image. If you change a configuration variable, you shouldn't have to rebuild your entire Docker image.

Kubernetes solves this with two resources:

  • ConfigMaps: For non-sensitive data (e.g., application logs settings, database hostnames).
  • Secrets: For sensitive data (e.g., API keys, database passwords). Note: Standard K8s secrets are only Base64 encoded, not strongly encrypted by default. In enterprise environments, we back them up with tools like AWS Secrets Manager or HashiCorp Vault.

📄 Lab Blueprint: Injecting Configuration into Pods

Show your students how a Pod consumes a ConfigMap as an environment variable.

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  DATABASE_HOST: "db.production.company.com"
  LOG_LEVEL: "debug"
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: backend
  template:
    metadata:
      labels:
        app: backend
    spec:
      containers:
      - name: api-server
        image: my-registry/api:v1.0
        env:
        - name: DB_HOST
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: DATABASE_HOST
Enter fullscreen mode Exit fullscreen mode

2. Advanced Traffic Management: Services & Ingress

Your pods are up, and they have their configurations. But how does a customer on the internet actually view the website?

Pods are ephemeral; they die and change IP addresses constantly. We need a permanent, stable entry point.

The Routing Chain 

[ External User Request ] 
           │
           ▼
┌──────────────────────────┐
│    Ingress Controller    │  <-- Routes traffic based on domain name (e.g., app.com)
└──────────┬───────────────┘
           │
           ▼
┌──────────────────────────┐
│     ClusterIP Service    │  <-- Acts as the permanent internal Load Balancer
└──────────┬───────────────┘
           │
           ▼
 ┌──────────────────┐
 │ Target Pods (1-3)│  <-- The actual running application instances
 └──────────────────┘
Enter fullscreen mode Exit fullscreen mode
  • ClusterIP Service: The internal load balancer. It gives your group of pods a single, permanent internal IP address.
  • Ingress Controller (e.g., Nginx, Traefik): The reverse proxy sitting at the edge of your cluster. It reads incoming HTTP requests and routes them based on the domain name or URL path (e.g., routing traffic hitting /api to the backend pods, and / to the frontend pods).

3. The Production Pillars: Health Probes

A professional DevOps engineer never assumes an application is working just because the container status says Running.

What happens if an app experiences a Java Out-Of-Memory deadlock? The container stays "alive," but it cannot handle customer traffic. Kubernetes handles this using Probes (automated health checks run by the node's kubelet).

The Two Critical Probes

Probe Type What it asks the container What happens if it fails Real-World Use Case
Readiness Probe "Are you ready to receive live user traffic right now?" The Ingress stops sending traffic to this specific pod, but does not restart it. Waiting for a heavy application to load its cache or connect to the database on boot.
Liveness Probe "Are you still alive and healthy, or are you frozen/deadlocked?" Kubelet instantly terminates the pod and spins up a fresh replica. Automatically fixing an application that has completely frozen or stopped responding.

📄 Classroom Demo: Implementing Probes 

spec:
  containers:
  - name: production-app
    image: company/app:v2
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 10
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5
Enter fullscreen mode Exit fullscreen mode

4. Resource Allocation: Requests vs. Limits

If you do not specify boundaries, a single malfunctioning container with a memory leak can steal all the RAM on a physical server, causing all other critical tenant pods on that machine to crash.

  • Requests: The guaranteed floor. The minimum amount of CPU/Memory the container needs to boot up. The scheduler uses this to pick a node.
  • Limits: The absolute ceiling. The maximum amount of resource the container is allowed to take.

⚠️ Critical Interview Question Warning for Students:
If a container breaks past its CPU Limit, Kubernetes throttles its speed (the app slows down).
If a container breaks past its Memory Limit, the Linux kernel immediately terminates it with an OOMKilled (Out of Memory Killed) error status.

Top comments (0)