Kubernetes Basics For Go

The minimum mental model:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels: {app: myapp}
  template:
    metadata:
      labels: {app: myapp}
    spec:
      containers:
      - name: myapp
        image: registry/myapp:v1.2.3
        ports: [{containerPort: 8080}]
        env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef: {name: db-secret, key: url}
        livenessProbe:
          httpGet: {path: /healthz, port: 8080}
        readinessProbe:
          httpGet: {path: /readyz, port: 8080}
        resources:
          requests: {cpu: 100m, memory: 128Mi}
          limits: {cpu: 500m, memory: 256Mi}
---
apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector: {app: myapp}
  ports: [{port: 80, targetPort: 8080}]

The objects a Go developer needs:

• POD: your container + its env — the unit of scheduling (you write a Deployment, not pods)
• DEPLOYMENT: replicas + rolling update (change the image tag → kubectl apply → the new version rolls out)
• SERVICE: the stable DNS name (myapp.namespace.svc) — the pod IPs change; the service routes
• configMap/secret: the env vars — mounted into the container
• INGRESS: the external traffic → the service

The Go-specific integration points:

• The /healthz and /readyz endpoints (the probes poll them — the health-check topic)
• The graceful shutdown (SIGTERM on pod stop → http.Server.Shutdown drains in-flight)
• GOMAXPROCS: Kubernetes sets CPU limits (resources.limits.cpu) — Go's scheduler reads it (1.25 reads the cgroup) or set GOMAXPROCS explicitly (the automaxprocs library for older versions)
• The rolling update's zero-downtime: readiness goes false on the old pods, the new pods come up, traffic shifts — your graceful shutdown completes the story