Canary Releases

A canary release sends a small slice of traffic to a new version, validates stability, and then ramps up gradually.

Common pattern

• Two Deployments: track=stable and track=canary
• Service points to stable first, then introduces canary
• Metrics and logs decide if you expand traffic

Label idea

# stable
labels:
  app: api
  track: stable
# canary
labels:
  app: api
  track: canary

Release rhythm

1. Start the canary
2. Send a small portion of traffic
3. Watch errors and latency
4. Increase or roll back

Pitfalls

• Ramp up without clear signals
• No metrics split by version

Practical notes

• Start with a quick inventory: kubectl get nodes, kubectl get pods -A, and kubectl get events -A.
• Compare desired vs. observed state; kubectl describe usually explains drift or failed controllers.
• Keep names, labels, and selectors consistent so Services and controllers can find Pods.

Quick checklist

• The resource matches the intent you described in YAML.
• Namespaces, RBAC, and images are correct for the target environment.
• Health checks and logs are in place before promotion.

References

• Deployments
• kubectl rollout
• Services