📢 Announcement: Intershop Platform automatic AKS node image and Kubernetes patch version upgrades

Effective: Ongoing (already enabled across all AKS clusters)
Category: Infrastructure Change
Impact Level: Medium (Awareness Recommended)

🔧 Why We Enabled This Feature and What Benefits It Offers

Azure Kubernetes Service (AKS) node pools run on an underlying operating system that requires regular security patching, in the same way any server operating system does. Microsoft periodically releases updated, hardened node images to address newly discovered security vulnerabilities.

To ensure these patches are applied consistently and in a timely manner, without relying on manual, error-prone processes, we have enabled AKS's built-in automatic node OS image upgrade capability across our AKS infrastructure.

Here's what you'll get:

• Consistent, timely application of operating system security patches across all node pools, reducing exposure to known vulnerabilities
• A managed, tested upgrade process (Microsoft-tested images, safe deployment practices)
• Reduced operational risk of outdated or unsupported node images
• Predictable timing, because upgrades only occur within defined, communicated maintenance windows (see below)

Other aspects included in this are:

• During the same maintenance windows, Kubernetes version updates may also be applied to AKS at patch level (versioning schema <major>.<minor>.<patch>). This means a maintenance window may involve both a node OS image upgrade and a Kubernetes patch version upgrade.

What this does not do:

• It does not modify your application code, configuration, or data.

🔁 What Actually Happens During an Upgrade

Automatic node OS and Kubernetes version upgrades are not equivalent to a lightweight, in-place patch command running quietly on existing nodes. Instead, for each node being upgraded:

1. New nodes are created and added to the affected node pool
2. Workloads (pods) running on the existing node moved from unpatched nodes to new nodes
3. Original node is patched/reimaged in the background with the updated base image
4. This repeats for all nodes until all got the upgraded base OS image in place

This sequence repeats for each node in the pool until the upgrade is complete. It means that during a maintenance window, your workloads are moved.

For most stateless workloads this is transparent. However, workloads that are sensitive to pod restarts, such as long-running batch jobs, staging/replication processes, or process chains, can be affected if they are actively running during this time.

🕒 When This Happens: Maintenance Windows

To make these activities predictable and to avoid unexpected disruption, upgrades are only performed within the following defined maintenance windows:

Day of week:

• Production (PRD) environments: Thursdays
• Development (DEV aka NonPRD) environments: Tuesdays

Note: the 8-hour window is a reserved outer boundary to accommodate Microsoft's process. In practice, the actual upgrade activity typically completes well within this window, usually well within around 3 hours.

✅ What You Should Do

1. If you run scheduled batch jobs, data replication, staging processes, or other process chains, please avoid scheduling these to run during the maintenance window applicable to your region and environment (production or non-production), where possible.
2. Continue to monitor your own application/job schedules against the table above, especially if you operate across multiple regions.

🆘 Need Help?

If you experience unexpected impact from a maintenance window, or have questions about how this applies to your environment, please contact our support team via Intershop Service Portal or through your dedicated service contact, referencing this article.

Thank you for your attention and cooperation.

This article will be reviewed and updated if maintenance windows or the upgrade approach change.