Initial draft of workload-oriented blue-green deployment blog - #5964
Steve Griffith (swgriffith) wants to merge 2 commits into
Conversation
There was a problem hiding this comment.
🟡 Changes recommended
Critical and moderate correctness issues remain in the documented commands, pool isolation, capacity examples, and upgrade validation.
Get a fresh assessment by requesting another Copilot review.
Pull request overview
This PR adds a draft blog post describing workload-aware blue-green AKS node pool upgrades.
Changes:
- Explains workload segmentation and upgrade-boundary design.
- Adds Azure CLI, Kubernetes placement, validation, and rollback examples.
- Documents capacity considerations and operational guidance.
- Review findings include invalid pool naming, incomplete scheduling isolation, incorrect upgrade commands, insufficient capacity examples, and SEO/prerequisite gaps.
File summaries
| File | Description |
|---|---|
website/blog/2026-09-11-blue-green-node-pool-upgrades-workload-aware/index.md |
New draft blog post and configuration examples; requires corrections to critical and moderate technical issues plus minor metadata and prerequisite updates. |
Review details
Suppressed comments (5)
website/blog/2026-09-11-blue-green-node-pool-upgrades-workload-aware/index.md:3
- This description is 148 characters, below the site's required 150–160-character SEO description range in
.github/instructions/website.blog.instructions.md:30. Add the missing context so the post metadata meets that requirement.
description: "Learn how to make AKS blue-green node pool upgrades workload-aware by isolating apps on dedicated pools, reducing capacity needs, and validating safely."
website/blog/2026-09-11-blue-green-node-pool-upgrades-workload-aware/index.md:56
- Because the commands in this post depend on preview CLI support, readers using an older Azure CLI will receive unsupported-option errors. The repository's preview-feature entry states that blue-green node pool upgrades require Azure CLI 2.64.0 or later (
CHANGELOG.md:625-628); include that prerequisite in this note.
> **Note**: Blue-green node pool upgrades are currently in preview. Review the [AKS preview feature support policy](https://learn.microsoft.com/azure/aks/support-policies) before using preview features in production environments.
website/blog/2026-09-11-blue-green-node-pool-upgrades-workload-aware/index.md:148
- This Deployment also omits resource requests and limits. The scheduler will not reserve or account for this workload's resource usage during the blue-green capacity transition; add representative requests and limits to make the upgrade-capacity example actionable, following the repository's AKS workload examples (
website/blog/2026-03-20-node-provisioning-best-practice/index.md:228-234).
containers:
- name: app
image: mcr.microsoft.com/azuredocs/aks-helloworld:v1
website/blog/2026-09-11-blue-green-node-pool-upgrades-workload-aware/index.md:89
- The post calls
bluegreenpoolthe smaller pool, but both user pools are created with--node-count 2. As written, the example does not demonstrate the reduced-capacity boundary that the cost discussion relies on; make the pool sizes intentionally different or update those claims.
--node-count 2 \
website/blog/2026-09-11-blue-green-node-pool-upgrades-workload-aware/index.md:196
kubectl rollout statustracks a Deployment generation, but this node-pool upgrade does not change the Deployment. It can therefore report success immediately without checking that evicted or recreated pods are ready on the green nodes; use a pod readiness/health check and verify the selected pods' nodes during the soak.
kubectl rollout status deployment/recommendations-worker
- Files reviewed: 1/2 changed files
- Comments generated: 6
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| - containerPort: 80 | ||
| ``` | ||
|
|
||
| For stronger isolation, add taints to the blue-green pool and tolerations to only the workloads that should run there. |
| containers: | ||
| - name: app | ||
| image: mcr.microsoft.com/azuredocs/aks-helloworld:v1 |
|
|
||
| ## Upgrade only the blue-green pool | ||
|
|
||
| Now start a node image or Kubernetes version upgrade on the blue-green pool. The rolling pool does not need to participate. |
| az aks nodepool upgrade \ | ||
| --resource-group $RESOURCE_GROUP \ | ||
| --cluster-name $CLUSTER_NAME \ | ||
| --name bluegreenpool \ | ||
| --node-image-only \ | ||
| --upgrade-strategy bluegreen |
| @@ -0,0 +1,239 @@ | |||
| --- | |||
| title: "A Workload-Oriented Pattern for AKS Blue-Green Node Pool Upgrades" | |||
There was a problem hiding this comment.
🟡 Changes recommended
Unresolved documentation and example correctness issues remain.
Get a fresh assessment by requesting another Copilot review.
Review details
Suppressed comments (4)
website/blog/2026-09-11-blue-green-node-pool-upgrades-workload-aware/index.md:155
- The two Deployment manifests are shown but never applied, so the subsequent placement checks and upgrade validation have no workloads to inspect. Add an explicit
kubectl applystep after the snippets, using concrete file names or a copy-pasteable heredoc.
Confirm placement before starting the upgrade.
website/blog/2026-09-11-blue-green-node-pool-upgrades-workload-aware/index.md:122
- The repository's Kubernetes manifest guidance requires resource requests and limits, but this container omits both. Add representative values so the node-capacity and temporary-doubling discussion has bounded, reproducible scheduling behavior.
containers:
- name: app
image: mcr.microsoft.com/azuredocs/aks-helloworld:v1
website/blog/2026-09-11-blue-green-node-pool-upgrades-workload-aware/index.md:148
- The repository's Kubernetes manifest guidance requires resource requests and limits, but this container omits both. Add representative values so the node-capacity and temporary-doubling discussion has bounded, reproducible scheduling behavior.
containers:
- name: app
image: mcr.microsoft.com/azuredocs/aks-helloworld:v1
website/blog/2026-09-11-blue-green-node-pool-upgrades-workload-aware/index.md:2
- The title is 65 characters, exceeding this repository's blog guideline that titles stay under 60 characters. Shorten it so the post title is not truncated in listings and search results.
title: "A Workload-Oriented Pattern for AKS Blue-Green Node Pool Upgrades"
- Files reviewed: 1/2 changed files
- Comments generated: 4
- Review effort level: Lite
|
|
||
| ### Create the node pools | ||
|
|
||
| Start with an AKS cluster and add two user pools. The rolling pool uses the default rolling strategy. The blue-green pool uses blue-green and a short soak configuration for illustration. |
| --resource-group $RESOURCE_GROUP \ | ||
| --cluster-name $CLUSTER_NAME \ | ||
| --name bluegreen \ | ||
| --node-count 2 \ |
|
|
||
| For stronger isolation, add taints to the blue-green pool and tolerations to only the workloads that should run there. | ||
|
|
||
| Confirm placement before starting the upgrade. |
| Blue-green upgrades are most useful when you do something with the soak window. Use that time to run validation against the workloads that moved to green nodes: | ||
|
|
||
| ```bash | ||
| kubectl rollout status deployment/recommendations-worker |
This pull request adds a new draft blog post to the website about implementing workload-aware blue-green node pool upgrades in Azure Kubernetes Service (AKS). The post explains how to design node pools as upgrade boundaries, segment workloads appropriately, and use blue-green upgrades only where their benefits justify the temporary cost and capacity overhead.
Key additions in this pull request:
Content Additions:
website/blog/2026-09-11-blue-green-node-pool-upgrades-workload-aware/index.md) detailing a pattern for making AKS blue-green node pool upgrades workload-aware, including rationale, configuration examples, and operational guidance.Technical Guidance:
Best Practices and Recommendations: