Kubernetes Deployment

Leave a Comment / Software Deployment / By /

Kubernetes runs containers across machines: you declare a desired state, the control plane tries to make it true. Use it when you have several services, need rolling updates and isolation, and can pay the operational tax. A single ASP.NET app on one VM does not need a cluster.

Objects you actually touch

  • Deployment (the usual workload): replica count, image, rolling update. Other workloads: StatefulSet, DaemonSet, Job.
  • Pod: one or more containers, ephemeral. Do not treat a pod as a pet.
  • Service: stable DNS and a selector. ClusterIP default; LoadBalancer at the edge of a cloud.
  • Ingress / Gateway: HTTP routing and TLS. Ingress is still common; Gateway API is the successor direction.
  • ConfigMap / Secret: config vs sensitive config. Secrets are still base64, not magic encryption, unless you add a provider.
  • Probe: liveness vs readiness vs startup — mixing them causes kill loops.

A deploy

CI builds an image tagged with the git SHA (not only latest). The Deployment’s image field changes; ReplicaSet rolls. Health checks must fail when the app cannot serve (not just when the process is up). Resource requests/limits: without them, noisy neighbors; with cartoon limits, throttling you will blame on “k8s.”

Example

Liveness answers “is the process up?” Readiness answers “can this pod take traffic?” Readiness may fail when the database is unreachable. Liveness must not.

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
readinessProbe:
  httpGet:
    path: /ready
    port: 8080

What breaks it

Liveness calls /ready, and /ready checks the database. A database blip restarts every pod, which makes the database worse.

livenessProbe:
  httpGet:
    path: /ready
    port: 8080

Pitfalls

  • Latest tag, no digest, no rollback.
  • One giant cluster, no namespaces or NetworkPolicies, everyone is cluster-admin.
  • Storing prod data only on an emptyDir.

Laptop cluster: Local Kubernetes. Traffic from outside: load balancer.