Upgrades

Kubernetes Upgrades

Upgrade strategies

The following table provides a quick overview of the available upgrade strategies, after which we will go into more detail about each strategy.

Each node pool can have its own upgrade strategy. The default strategy is replace. You can use different strategies for different node pools within your cluster to optimize the upgrade process. For example, you may have stateful workloads that require a more controlled or in place upgrade process, while other workloads can be replaced without any issues.

Replace

The replace strategy is ideal for scenarios where reliability and a clean slate are the top priorities. Each node is replaced, ensuring that the new nodes have the latest Kubernetes version and a fresh environment, which minimizes the risk of legacy issues or misconfigurations.

Example Use Case: A critical production workload that demands maximum reliability and performance. Ensuring each node starts fresh avoids lingering issues from previous configurations or states.

ReplaceMinorInplacePatch

The replaceMinorInplacePatch strategy is useful in cases where minor upgrades require high reliability through node replacement, but patch upgrades can be done in place to save time and resources while maintaining a balance between reliability and efficiency.

Example Use Case: A workload that benefits from reliability during major changes but doesn’t justify full node replacements for small fixes, such as batch processing jobs that tolerate some downtime during patch upgrades but require a clean slate for significant changes.

ReplaceMinorInplacePatchWithoutDrain

The replaceMinorInplacePatchWithoutDrain strategy is the default recommendation for most workloads, offering a balance of efficiency and reliability. It avoids container restarts during patch upgrades while ensuring a clean state and reliability during minor Kubernetes upgrades by replacing nodes.

Example Use Case: General-purpose applications such as microservices where some level of reliability is critical during minor upgrades, but workloads can tolerate minimal downtime or in-place updates during patches.

Inplace

The inplace strategy is best suited for scenarios where node replacement is unnecessary or unwanted, but workloads can tolerate being drained to allow for underlying upgrades. This can be useful when updating components like the container runtime or OS dependencies.

Example Use Case: Data analysis workloads or job-based processing where nodes are drained and workloads are rescheduled without long-term disruption. Draining ensures all workloads restart cleanly on the same nodes while upgrades to tools like containerd are applied.

InplaceWithoutDrain

The inplaceWithoutDrain strategy is perfect for stateful workloads or applications that require low-impact upgrades with minimal disruption. By upgrading in place without draining, this strategy avoids restarting workloads that may have stateful data or long-running connections.

Example Use Case: Database workloads or stateful services such as MongoDB or Redis, where restarting nodes or draining workloads could disrupt operations or cause performance degradation. This strategy allows upgrades without interrupting critical services.

Node replacement flow

AME uses a surge style upgrade strategy. Meaning before a node is replaced, a new one will be provisioned.

AME Versioning

Version scheme

AME uses a versioning scheme that is a combination of the Kubernetes version and the AME version. The first part is the Kubernetes version, followed by the AME version. As example we can break the following version down:

v1.31.2-u-ame.3

• Major version: The major version of the Kubernetes cluster. This is the first number in the version string. In this case, it is 1.
• Minor version: The minor version of the Kubernetes cluster. This is the second number in the version string. In this case, it is 31.
• Patch version: The patch version of the Kubernetes cluster. This is the third number in the version string. In this case, it is 2.
• Linux distribution: The Linux distribution used for the Kubernetes cluster. This is the fifth part of the version string. In this case, it is u for Ubuntu.
• AME version: The AME version of the Kubernetes cluster. This is the fourth number in the version string. In this case, it is 3.

Changes in versioning

• Minor version: A minor version change indicates a new feature or a change in the Kubernetes version. This can include new features, changes in the way resources are handled, or changes in the way the cluster is managed.

  Besides Kubernetes changes, AME can also release changes within the same Kubernetes minor version. These changes can include new features, changes in the way resources are handled, or changes in the way the cluster is managed.

• Patch version: A patch version change indicates a bug fix or a security update in the Kubernetes version. This can include bug fixes, security updates, or other minor changes.

  Besides Kubernetes patches, AME can also release changes within the same Kubernetes patch. These patches can include bug fixes, security updates, or other minor AME changes and its dependencies.

• AME version: An AME version change indicates a change in just AME and its dependencies and components. This can include new features, bug fixes, and any dependency changes.

Update channels

Update channels are used to define the Kubernetes minor version that should be used for the cluster. This can be used to in combination with Auto Upgrades to automatically upgrade the cluster to the latest patch version of the specified minor version.

The version specified in the update channel will be the target version for your cluster when an upgrade is started.

Upgrading and scheduling

With AME you can perform manual upgrades of clusters immediately, schedule an upgrade for later or configure auto upgrades.

Overview of your cluster upgrades

From the console you can head to the "Maintenance" tab to see an overview of all your scheduled cluster upgrades within your organization.

Automatic upgrades

AME supports automatic upgrades for your Kubernetes cluster. We recommend that you enable auto upgrades to keep your cluster up to date with the latest Kubernetes version.

When you enable auto upgrades, your cluster will automatically upgrade to the latest patch version of the specified minor version. This ensures that your cluster is always running the latest version of Kubernetes, with the latest security patches and bug fixes.

Read more about this in the Auto Upgrades documentation.

Upstream cluster

AME allows you to configure an upstream cluster to use as a target for the Kubernetes version to upgrade to. This can be used to, for example, enforce a production cluster to wait for a staging cluster to be upgraded first.

Troubleshooting

There are a few edge cases in which an upgrade may take a long time to complete;

• When running a workload such as PostgreSQL, that uses a graceful shutdown. e.g. waiting until all client connections have disconnected before exiting.
• Standalone pods, deployed without making use of either a StatefulSet, Deployment or DaemonSet. These pods will be removed during a node replacement and will not be recreated.

To speed up this process, it may be necessary to shutdown some applications manually.