Kubernetes for developers: Deployment, Service, readiness, and autoscaling

Do not start with YAML alone#

Kubernetes is easier to learn by understanding the operational problem each object solves. For developers, start with Pods, Deployments, Services, and probes.

Deployment manages rollout#

A Deployment maintains the desired number of Pods and rolls out new versions. Rolling updates replace Pods gradually, but only work well when readiness checks accurately signal whether a Pod can receive traffic.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: registry.example.com/api:1.4.2
          ports:
            - containerPort: 3000
          readinessProbe:
            httpGet:
              path: /health/ready
              port: 3000
          livenessProbe:
            httpGet:
              path: /health/live
              port: 3000

Service stabilizes networking#

Pod IPs are disposable. A Service selects Pods by labels and gives other workloads a stable DNS name. Public traffic usually comes through Ingress or a load balancer in front of the Service.

Requests, limits, and autoscaling#

Requests help the scheduler place Pods. Limits define maximum resource use. Choose values from measurements, not guesses. Horizontal Pod Autoscaler can scale by CPU, memory, or custom metrics, but scaling out does not fix a slow database query.

Checklist#

• Use explicit image tags, not latest, in production.
• Readiness checks are lightweight and reflect traffic readiness.
• Liveness checks do not restart healthy Pods because a dependency is temporarily slow.
• Service selectors match Pod labels consistently.
• Requests and limits come from real measurements.
• ConfigMap and Secret values are kept out of images.

Primary references#

• Kubernetes Docs: Deployments
• Kubernetes Docs: Services
• Kubernetes Docs: Probes