Kubernetes for Application Developers: Deploy Your First Service

Prepare the application

Kubernetes runs containers, so start with an image that follows container best practice: it reads configuration from environment variables, logs to standard output, handles a termination signal by finishing in-flight requests and exposes health endpoints. A liveness endpoint answers whether the process is alive; a readiness endpoint answers whether it can serve traffic right now, including dependencies such as the database. Push the image to a registry with a version tag, not only latest.

Describe the Deployment

A Deployment declares the desired state: which image, how many replicas, resource requests and limits, environment variables and probes. Kubernetes creates Pods to match and replaces them if they fail.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: catalogue-api
spec:
  replicas: 3
  selector:
    matchLabels: { app: catalogue-api }
  template:
    metadata:
      labels: { app: catalogue-api }
    spec:
      containers:
        - name: api
          image: registry.example.com/catalogue-api:1.4.0
          ports: [{ containerPort: 8000 }]
          envFrom: [{ configMapRef: { name: catalogue-config } }]
          readinessProbe:
            httpGet: { path: /ready, port: 8000 }
          livenessProbe:
            httpGet: { path: /live, port: 8000 }
          resources:
            requests: { cpu: 100m, memory: 128Mi }
            limits: { memory: 256Mi }

Resource requests help the scheduler place Pods on nodes with enough capacity; a memory limit prevents one container from exhausting a node.

Expose it with a Service

Pods come and go and their IP addresses change. A Service selects Pods by label and gives them one stable name and address inside the cluster, balancing traffic across ready Pods. To accept traffic from outside, route HTTP requests to the Service through an Ingress or the Gateway API, depending on what your cluster supports.

Separate configuration and secrets

Put non-sensitive settings in a ConfigMap and credentials in a Secret, and inject them as environment variables or mounted files. Note that Kubernetes Secrets are only base64-encoded by default; protect them with access controls, enable encryption at rest in the cluster and consider an external secret manager for sensitive production credentials. Never bake secrets into images.

Roll out and roll back

When you change the image tag and apply the Deployment, Kubernetes performs a rolling update: it starts new Pods, waits for them to become ready and then removes old ones. Watch progress with kubectl rollout status deployment/catalogue-api. If the new version misbehaves, kubectl rollout undo returns to the previous revision. Readiness probes are what make this safe, because traffic only reaches Pods that report ready.

Observe what is happening

• kubectl get pods shows status and restart counts.
• kubectl describe pod explains scheduling problems and failed probes.
• kubectl logs shows container output; add --previous to see logs from a crashed container.
• kubectl get events lists recent cluster events for the namespace.
• Application metrics and centralised logs remain essential for anything beyond quick checks.

Checklist

• The image reads config from the environment and logs to stdout
• Liveness and readiness endpoints have different meanings
• The Deployment sets replicas, resources and probes
• A Service provides stable access to Pods
• Configuration and secrets live outside the image
• You can watch a rollout and roll it back