Kubernetes Lifecycle policy

AME Kubernetes Lifecycle policy

Upgrade impact

Each release describes the upgrade impact when upgrading from the previous version to the next. A few rules will always apply, and thus will not be written for each release. The upgrade impact column only describes ADDITIONAL impact expectations.

• When upgrading will result in a node recycle, unless otherwise mentioned in the impact section of a release.
• When upgrading between Kubernetes minor versions (e.g. v1.20.x to v1.21.x) may result in a brief period of API downtime due to an etcd upgrade.
• Upgrading is only supported from one minor version to the next.
• For more information, please read the Kubernetes version skew policy.

Lifecycle & version policy

We follow the Kubernetes version policy documented here: Kubernetes version skew policy

This means;

1. We support the 3 latest minor versions of Kubernetes (e.g. 1.21, 1.20 and 1.19).
2. The latest minor version will lag behind while we built-in support.
3. Starting from Kubernetes 1.19, we continue to release new releases up until 1 year after the initial Kubernetes release (not our support date).
4. All versions before Kubernetes 1.19 will be discontinued 9 months after initial release by the Kubernetes community. This results in Avisi Cloud declaring a specific AME Kubernetes series EOL.
5. Clusters running an EOL version will continue to support upgrades, and remain available, but downtime and/or broken functionality may occur any time after the EOL deadline.