Skip to content

Initial draft of workload-oriented blue-green deployment blog - #5964

Open
Steve Griffith (swgriffith) wants to merge 2 commits into
Azure:masterfrom
swgriffith:blog/blue-green-node-pool-upgrades
Open

Steve Griffith (swgriffith) wants to merge 2 commits into
Azure:masterfrom
swgriffith:blog/blue-green-node-pool-upgrades

Conversation

@swgriffith

Copy link
Copy Markdown
Member

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:

  • Added a comprehensive draft blog post (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:

  • Included step-by-step instructions and example configurations for creating separate node pools with rolling and blue-green upgrade strategies, as well as YAML manifests for workload placement.
  • Provided operational commands for validating upgrades, monitoring node/pod movement, and performing rollbacks during the blue-green upgrade process.

Best Practices and Recommendations:

  • Outlined scenarios where this pattern is most effective, as well as limitations and considerations regarding capacity and validation signals.
  • Emphasized the importance of workload segmentation, node pool design, and using Kubernetes scheduling features (affinity, taints, tolerations) to enforce placement.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 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 bluegreenpool the 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 status tracks 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.

Comment thread website/blog/2026-09-11-blue-green-node-pool-upgrades-workload-aware/index.md Outdated
- containerPort: 80
```

For stronger isolation, add taints to the blue-green pool and tolerations to only the workloads that should run there.
Comment on lines +120 to +122
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.
Comment on lines +169 to +174
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"
Copilot AI review requested due to automatic review settings September 14, 2026 18:29

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 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 apply step 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants