Kubernetes for DevOps Teams

Kubernetes is the de facto container orchestration platform, and understanding how to operate it is a core DevOps skill. This lesson focuses on the practical Kubernetes concepts that DevOps teams use every day: deploying applications, managing configuration, and integrating Kubernetes into CI/CD pipelines.

The Deployment Object

A Kubernetes Deployment is the primary way to run stateless applications. It declares the desired state — which image to run, how many replicas, resource limits — and the controller ensures the actual state matches.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-api
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-api
  template:
    metadata:
      labels:
        app: web-api
    spec:
      containers:
        - name: web-api
          image: myregistry/web-api:v1.4.2
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"

Rolling Updates and Rollbacks

When you update a Deployment (e.g., change the image tag), Kubernetes performs a rolling update by default — it creates new pods and terminates old ones gradually, ensuring availability throughout. The maxUnavailable and maxSurge parameters control the rollout pace.

To roll back to the previous version:

kubectl rollout undo deployment/web-api

Kubernetes maintains a revision history, so you can also roll back to a specific revision:

kubectl rollout undo deployment/web-api --to-revision=3

Health Probes

Health probes let Kubernetes know whether a container is healthy and ready to serve traffic:

Important: Without a readiness probe, Kubernetes sends traffic to pods as soon as they start — before your application is actually ready. Always configure readiness probes for web services.

ConfigMaps and Secrets

Never bake configuration or credentials into a container image. Externalise them:

• ConfigMap: Non-sensitive configuration (feature flags, environment names, URLs). Mounted as files or injected as environment variables.
• Secret: Sensitive values (passwords, API keys, TLS certificates). Base64-encoded in etcd. For production, use a secrets manager (AWS Secrets Manager, HashiCorp Vault) with the External Secrets Operator to sync values into Kubernetes Secrets.

Namespaces and RBAC

Namespaces provide virtual clusters within a physical cluster. Common patterns:

• One namespace per environment: development, staging, production
• One namespace per team: team-payments, team-identity
• ResourceQuotas limit CPU, memory, and object counts per namespace

Kubernetes RBAC grants permissions to subjects (users, service accounts) over resources in specific namespaces. In CI/CD, the pipeline service account should only have permission to update Deployments in its target namespace — not cluster-wide admin access.

Kubernetes in a CI/CD Pipeline

A typical GitOps-style Kubernetes pipeline:

1. CI builds and pushes a new Docker image tagged with the commit SHA
2. CI updates the image tag in the Helm chart or Kustomize overlay (via a Git commit or PR)
3. ArgoCD or Flux detects the change in the config repo
4. The GitOps operator applies the new manifests to the cluster
5. Kubernetes performs a rolling update; health probes gate traffic to the new pods
6. If probes fail, Kubernetes halts the rollout; the operator detects drift and alerts

Helm — Kubernetes Package Manager

Helm packages Kubernetes manifests into reusable, versioned charts. A chart is a template with configurable values — you install the same chart with different values.yaml files for different environments. Most popular OSS applications (Prometheus, Nginx, Cert-Manager) are distributed as Helm charts.