ConfigMaps, Secrets, & Ingress

Managing Configuration

In the Twelve-Factor App methodology, configuration (like environment variables, API keys, and connection strings) should never be hardcoded into your application code.

Kubernetes provides two native objects to manage configuration securely and decouple it from your container image:

1. ConfigMaps

A ConfigMap is an API object used to store non-confidential data in key-value pairs. Pods can consume ConfigMaps as environment variables, command-line arguments, or as configuration files in a volume.

yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: game-config
data:
  # property-like keys; each key maps to a simple value
  player_initial_lives: "3"
  ui_properties_file_name: "user-interface.properties"

2. Secrets

A Secret is very similar to a ConfigMap, but it's specifically designed to hold sensitive data such as passwords, OAuth tokens, and SSH keys. Storing confidential data in a Secret is safer and more flexible than storing it verbatim in a Pod definition or container image.

yaml
apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  # Data must be base64 encoded!
  username: YWRtaW4=
  password: MWYyZDFlMmU2N2Rm

Routing External Traffic: Ingress

We learned earlier about LoadBalancer Services. While they work great for exposing a single application, they have a massive flaw: Cost.

If your cluster has 10 microservices, defining 10 LoadBalancer Services means your Cloud Provider (AWS/GCP) will literally provision 10 physical Load Balancers. That means paying for 10 separate Load Balancer bills every month!

The Solution: Ingress Controllers

An Ingress is an API object that manages external access to the services in a cluster, typically via HTTP/HTTPS.

Instead of provisioning multiple Load Balancers, you provision one Load Balancer pointing to an Ingress Controller (like Nginx Ingress or Traefik). The Ingress Controller acts as an intelligent router inside the cluster.

Anatomy of an Ingress Rule

You write Ingress Rules to define how URL paths map to your internal ClusterIP Services.

yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: minimal-ingress
spec:
  rules:
    - http:
        paths:
          - path: /api/v1/users
            pathType: Prefix
            backend:
              service:
                name: user-microservice-clusterip # Traffic hits this service!
                port:
                  number: 8080
          - path: /api/v1/payments
            pathType: Prefix
            backend:
              service:
                name: payment-microservice-clusterip # Or this service!
                port:
                  number: 5000

Course Completion

Congratulations, you have finished the beginner Kubernetes track! You went from understanding raw container infrastructure (Pods and Nodes) to wrapping them in self-healing lifecycles (Deployments), decoupling network routing (Services and Ingress), and securely managing configuration (Secrets and ConfigMaps).