Around Go: Kubernetes · 3 MIN READ

Release operations: rollout, scale and rollback

Change an image deliberately, observe revisions and understand what rollback cannot restore.

A Deployment rollout changes its Pod template and replaces replicas under its update policy. A timeout or unhealthy Pod requires investigation before further mutations. These examples operate only on the inspected development go-api Deployment, using a real tested image reference in place of the placeholder.

Inspect history and set the intended artifact

rollout history lists retained Deployment revisions. set image changes the api container image in the Pod template. Use an immutable image digest in a real release where reproducibility matters, and keep the declarative source in sync with this operational change.

bash

kubectl --context dev-cluster -n go-lab rollout history deployment/go-api
kubectl --context dev-cluster -n go-lab set image deployment/go-api \
  api=registry.example.com/YOUR_OWNER/go-api:0.1.1
kubectl --context dev-cluster -n go-lab rollout status deployment/go-api --timeout=120s

Read the code

Replace the registry, owner and version with a published tested artifact before running. set image mutates the cluster immediately. A future apply from an old manifest can overwrite the change; version-controlled deployment configuration should describe the intended final state.

Scale with resource and downstream budgets in mind

scale changes desired replicas, not the size of an individual process. Check workload state and pressure afterwards. Requests, limits, database pools and worker concurrency multiply across replicas; an autoscaler or another controller may subsequently change the count.

bash

kubectl --context dev-cluster -n go-lab scale deployment/go-api --replicas=3
kubectl --context dev-cluster -n go-lab get deployment go-api
kubectl --context dev-cluster -n go-lab get pods -l app=go-api
kubectl --context dev-cluster -n go-lab top pods -l app=go-api

Read the code

Three replicas are a syntax example, not a capacity recommendation. top requires a metrics API. Confirm the cluster can schedule the workload and downstream systems can handle its multiplied demand rather than treating replica count as free capacity.

Roll back a Pod template, then verify the service

undo uses a retained earlier Deployment revision. It can restore the Pod template, but cannot reverse a database migration, external side effect or independently changed Secret/ConfigMap. Inspect the selected history revision and its artifact before a deliberate rollback.

bash

kubectl --context dev-cluster -n go-lab rollout history deployment/go-api
# After selecting and reviewing an appropriate previous revision:
kubectl --context dev-cluster -n go-lab rollout undo deployment/go-api
kubectl --context dev-cluster -n go-lab rollout status deployment/go-api --timeout=120s

Read the code

The undo line chooses the previous retained revision; use --to-revision with an inspected real number for an explicit choice. Afterwards verify readiness, logs and the API through a fresh test request. Do not repeatedly undo merely because a status command timed out.

TAKE THIS WITH YOU

Record the released image, observe the rollout and budget replicas against downstream capacity. Rollback restores a retained workload template, not databases or every separate configuration object.

Check your understanding

What can Deployment rollout undo restore?

Go to the source

Progress stays in this browser. No account needed.