Around Go: Kubernetes · 3 MIN READ

Deploy a manifest: explain, dry-run, diff and apply

Validate a workload document and observe reconciliation rather than assuming apply means ready.

A manifest declares desired state; the API accepting it is only the start of reconciliation. Save the earlier Deployment and Service example as deployment.yaml, set a real pullable image reference and use the go-lab development namespace from the context lesson.

Read the schema and validate with the server

explain documents a field from the API schema. apply --dry-run=server asks the server to validate and default the request without persisting it. It still requires API access and appropriate permission and can depend on admission configuration.

bash

kubectl --context dev-cluster explain deployment.spec.template.spec.containers
kubectl --context dev-cluster -n go-lab apply \
  --dry-run=server -f deployment.yaml

Read the code

Fix unknown fields and validation errors before the real apply. A successful dry run does not schedule Pods, pull images or test your application. Only submit trusted reviewed files, including any resource namespace declared inside them.

Review the delta and apply the intended state

diff compares the proposed object with live state; exit one means differences, not necessarily a failed comparison. apply persists the desired resource changes, so inspect the exact files and target namespace before this mutation.

bash

kubectl --context dev-cluster -n go-lab diff -f deployment.yaml
kubectl --context dev-cluster -n go-lab apply -f deployment.yaml

Read the code

kubectl diff uses status zero for no changes, one for differences and greater than one for errors. Do not hide all nonzero codes with || true in automation. apply may create or update several documents from this file.

Wait for convergence and inspect the resulting objects

rollout status waits for a Deployment update to finish within a timeout. get reports objects and their current state; it does not prove every business request succeeds. A timeout should lead to diagnosis of the existing rollout before another deployment attempt.

bash

kubectl --context dev-cluster -n go-lab rollout status deploy/go-api --timeout=120s
kubectl --context dev-cluster -n go-lab get deploy,rs,pods,svc -l app=go-api
kubectl --context dev-cluster -n go-lab get svc go-api

Read the code

The original Service example does not give the Service object an app label, so the final explicit Service query is necessary. Inspect readiness, image pulls and events if convergence fails. A successful apply alone is not release success.

TAKE THIS WITH YOU

Validate a reviewed document, understand diff exit codes, apply once and observe the rollout. API acceptance and a ready, functional application are separate milestones.

Check your understanding

What does kubectl diff returning exit status 1 normally mean?

Go to the source

Progress stays in this browser. No account needed.