Deployment Basics

Introduction

Deploying Go services means building static binaries, containerizing, and running on Kubernetes, AWS ECS, Google Cloud Run, or VM systemd services. Go's single binary simplifies deployment — copy one file and run.

Kubernetes Deployment + Service + Ingress is the cloud-native standard. Configure liveness/readiness probes, resource limits, horizontal pod autoscaling, and rolling updates. CI/CD pipelines automate test → build → push → deploy.

This lesson covers K8s manifest essentials, GitHub Actions CI, and zero-downtime rolling deployments — the deployment story interviewers expect from Go backend candidates.

The story

A Go payments service deploys to GKE via GitHub Actions: build and test, push a container to Artifact Registry, apply Kubernetes manifests with rolling updates (maxUnavailable: 0), and verify Prometheus alerts stay green. readinessProbe waits for database connectivity; preStop hook sleeps 5 seconds so the load balancer drains connections before the pod terminates.

Blue-green or canary deploys route 5% traffic to a new version first — Go's fast startup makes rolling back a bad deploy a one-command kubectl rollout undo.

Understanding the topic

Key concepts

• Kubernetes Deployment manages pod replicas.
• Service exposes pods internally; Ingress externally.
• Liveness probe restarts unhealthy pods.
• Readiness probe removes pod from load balancer until ready.
• ConfigMap/Secret inject env configuration.
• HPA scales pods on CPU/memory/custom metrics.

flowchart LR
  Source[Go Source] --> Build[go build]
  Build --> Image[Docker Image]
  Image --> Registry[ECR / GCR]
  Registry --> K8s[Kubernetes Pod]

Step-by-step explanation

1. CI: go test -race → docker build → push to registry.
2. CD: kubectl apply or Helm upgrade.
3. Rolling update replaces pods incrementally.
4. Readiness waits for DB migration and Ping success.
5. Ingress routes HTTPS with cert-manager TLS.
6. Monitor with Prometheus metrics and alerting.

Practical code example

Kubernetes Deployment manifest and GitHub Actions CI snippet:

# k8s/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: go-api
  template:
    metadata:
      labels:
        app: go-api
    spec:
      containers:
      - name: api
        image: ghcr.io/techlearningpro/go-api:1.0.0
        ports:
        - containerPort: 8080
        envFrom:
        - secretRef:
            name: go-api-secrets
        resources:
          requests:
            memory: "64Mi"
            cpu: "100m"
          limits:
            memory: "256Mi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 5
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 3

# .github/workflows/ci.yaml snippet
# - run: go test -race ./...
# - run: docker build -t ghcr.io/org/go-api:$GITHUB_SHA .
# - run: docker push ghcr.io/org/go-api:$GITHUB_SHA

Line-by-line code explanation

• Deployment spec with replicas: 3 maintains desired pod count across node failures.
• readinessProbe httpGet path: /readyz gates traffic until the app is fully initialized.
• livenessProbe restarts pods that deadlock — separate from readiness to avoid flapping.
• resources.requests and limits — CPU/memory guarantees prevent noisy neighbor issues.
• rollingUpdate.maxSurge / maxUnavailable controls deploy speed vs capacity.
• ConfigMap and Secret volumes inject config without baking secrets into images.
• HPA on CPU or custom metrics scales replicas during traffic spikes automatically.
• graceful shutdown — handle SIGTERM, call server.Shutdown, then exit.

Key takeaway: Readiness prevents traffic before DB ready. Resource limits prevent noisy neighbor. Pin image digest in production.

Real-world use

Where you'll use this in production

• Production API on AWS EKS or GKE.
• Serverless Go on Cloud Run with auto-scaling.
• Edge deployment of static Go binary on VM systemd.
• Blue-green or canary releases with Argo Rollouts.

Best practices

• Immutable deployments — new image per release, never patch running container.
• Readiness probe on DB connectivity.
• Set resource requests and limits.
• Use semantic versioning tags plus git SHA.
• Automate rollback on failed health checks.
• Separate staging and production clusters/namespaces.

Common mistakes

• No readiness probe — traffic hits starting pods.
• Latest tag in production — unpredictable deploys.
• Missing resource limits — pod OOM or node exhaustion.
• Secrets baked into image instead of K8s Secret.
• No rollback plan when deployment fails.

Advanced interview questions

Summary

Deploy Go as container on K8s with probes and resource limits. CI runs tests and builds; CD applies manifests or Helm. Readiness gates traffic; liveness restarts failed pods. Secrets via K8s Secret — never in image layers. Next lesson: interview preparation and final project.