You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/operator-nexus/concepts-nexus-kubernetes-cluster.md
+7-7Lines changed: 7 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -37,18 +37,18 @@ VM is created as part of NKS cluster deployment on Nexus instance. There are two
37
37
However, application pods can be scheduled on system node pools in case user wants only one node pool in their cluster. Every Nexus Kubernetes Cluster must
38
38
contain at least one system node pool with at least one node.
39
39
40
-
## Nexus Kubernetes Cluster Add-ons
40
+
## Nexus Kubernetes Cluster Features
41
41
42
-
Nexus Kubernetes Cluster Add-onsis a feature of the Nexus platform that allows customers to enhance their Nexus Kubernetes clusters with extra packages or features. The Add-ons are categorized into two types: required and optional.
42
+
Nexus Kubernetes Cluster Features, previously known as "Add-ons" in releases before [Azure Operator Nexus](/articles/operator-nexus/overview.md) release 3.11.0, is a component of the Nexus platform that allows customers to enhance their Nexus Kubernetes clusters with extra packages or components. The Features are categorized into two types: required and optional.
43
43
44
-
* Required Add-ons: Add-ons are automatically deployed into provisioned Nexus Kubernetes clusters. Core add-ons such as Calico, MetalLB, Nexus Storage CSI, IPAM plugins, metrics-server, node-local-dns, Arc for Kubernetes,
45
-
and Arc for Servers are included by default when clusters are created. The successful completion of the cluster provisioning process depends on these add-ons being installed successfully. If a required add-on installation fails and can't be fixed, the cluster status is marked as failed.
44
+
* Required Features: Required Features are automatically deployed into provisioned Nexus Kubernetes clusters. Core Features such as Calico, MetalLB, Nexus Storage CSI, IPAM plugins, metrics-server, node-local-dns, Arc for Kubernetes,
45
+
and Arc for Servers are included by default when clusters are created. The successful completion of the cluster provisioning process depends on these Features being installed successfully. If a required Feature installation fails and can't be fixed, the cluster status is marked as failed.
46
46
47
-
* Optional Add-ons: Add-ons are supplementary services associated with a Kubernetes Cluster resource. Customers can choose to activate or deactivate these add-ons on demand.
47
+
* Optional Features: Optional Features are supplementary services associated with a Kubernetes Cluster resource. Customers can choose to activate or deactivate these Features on demand.
48
48
Example for supplementary services could include deployment of cluster-level local image caching registry within the NKS cluster to support for disconnected scenarios. NKS enables the customer to observe the status, health,
49
-
and version of each required and optional add-on, which can be monitored on Azure portal, or the state can be fetched using Azure Resource Manager APIs.
49
+
and version of each required and optional Feature, which can be monitored on Azure portal, or the state can be fetched using Azure Resource Manager APIs.
50
50
51
-
Add-ons are installed once and can only be updated or upgraded when the customer upgrades the Nexus Kubernetes cluster. It enables customers to apply critical production hotfixes without interference from the underlying infrastructure operations, which could otherwise overwrite their cluster modifications.
51
+
Features are installed once and can only be updated or upgraded when the customer upgrades the Nexus Kubernetes cluster. It enables customers to apply critical production hotfixes without interference from the underlying infrastructure operations, which could otherwise overwrite their cluster modifications.
# Supported Kubernetes versions in Azure Operator Nexus Kubernetes service
12
12
13
-
This document provides an overview of the versioning schema used for the Operator Nexus Kubernetes service, including the supported Kubernetes versions. It explains the differences between major, minor, and patch versions, and provides guidance on upgrading Kubernetes versions, and what the upgrade experience is like. The document also covers the version support lifecycle and end of life (EOL) for each minor version of Kubernetes. Additionally it will describe features, a group of components which were previously known as "add-ons".
13
+
This document provides an overview of the versioning schema used for the Operator Nexus Kubernetes service, including the supported Kubernetes versions. It explains the differences between major, minor, and patch versions, and provides guidance on upgrading Kubernetes versions, and what the upgrade experience is like. The document also covers the version support lifecycle and end of life (EOL) for each minor version of Kubernetes. Additionally it will describe Features, a group of components which were previously known as "Add-ons".
14
14
15
15
The Kubernetes community releases minor versions roughly every three months. Starting with version 1.19, the Kubernetes community has [increased the support window for each version from nine months to one year](https://kubernetes.io/blog/2020/08/31/kubernetes-1-19-feature-one-year-support/).
16
16
@@ -50,14 +50,14 @@ For the past release history, see [Kubernetes history](https://github.com/kubern
50
50
An Operator Nexus Kubernetes service version is made of two discrete components that are combined into a single representation:
51
51
52
52
* The Kubernetes version. For example, 1.25.4, is the version of Kubernetes that you deploy in Operator Nexus. These packages are supplied by Azure AKS, including all patch versions that Operator Nexus supports. For more information on Azure AKS versions, see [AKS Supported Kubernetes Versions](/azure/aks/supported-kubernetes-versions)
53
-
* A [Version Bundle](#version-bundles) number which encapsulates the Kubernetes version, features, and operating system (OS) image used by nodes in the Operator Nexus Kubernetes cluster, as a single number. For example, 2.†
53
+
* A [Version Bundle](#version-bundles) number which encapsulates the Kubernetes version, Features, and operating system (OS) image used by nodes in the Operator Nexus Kubernetes cluster, as a single number. For example, 2.†
54
54
55
55
The combination of these values is represented in the API as the single kubernetesVersion. For example, `1.25.4-2` or the alternatively supported “v” notation: `v1.25.4-2`.
56
56
57
-
† As of April 2025 version bundle increments have now changed to feature release versioning rather than sequential numbering to provide release-to-release distinctiveness at a glance. Continue reading for more information on this change.
57
+
† As of April 2025 version bundle increments have now changed to include release versioning rather than sequential numbering to provide release-to-release distinctiveness at a glance. Continue reading for more information on this change.
58
58
59
59
### Version bundles
60
-
By extending the version of Kubernetes to include a secondary value, cumulatively called the "version bundle", the Operator Nexus service can clearly account for cases where the Kubernetes version is unchanged but the OS and features are modified to include updates from a new Nexus release. Such updates might include but aren't limited to: updated operating system images, patch releases for features, and the introduction of some platform features.
60
+
By extending the version of Kubernetes to include a secondary value, cumulatively called the "version bundle", the Operator Nexus service can clearly account for cases where the Kubernetes version is unchanged but the OS and Features are modified to include updates from a new Nexus release. Such updates might include but aren't limited to: updated operating system images, patch releases for Features, and the introduction of some platform Features.
61
61
62
62
Prior to April 2025, version bundle numbers were incremented starting from "1" and varied depending on how long a particular Kubernetes patch version had been available on Nexus. After April 2025, all version bundles in the same release are numbered with the same release identifier, e.g. "-4.4.0" or "-4.5.0". The chart below details which version bundles are in the same series.
63
63
@@ -73,7 +73,7 @@ Changes to the configuration of a deployed Operator Nexus Kubernetes cluster sho
73
73
### Choosing a version bundle for an upgrade scenario
74
74
We allow upgrade from any patch version in one Kubernetes minor version to any patch version in the next Kubernetes minor version, giving you flexibility. For example, an upgrade from 1.31.1-x.x.x to 1.32.x-x.x.x would be allowed, regardless of the presence of an intermediate 1.31.2-x.x.x version.
75
75
76
-
When new version bundles are released, all the Kubernetes patch versions in that version bundle release use the same versions of both OS and features; only the Kubernetes code differs between them. Let's look at a few examples of upgrade routes which may be desirable:
76
+
When new version bundles are released, all the Kubernetes patch versions in that version bundle release use the same versions of both OS and Features; only the Kubernetes code differs between them. Let's look at a few examples of upgrade routes which may be desirable:
77
77
78
78
#### Kubernetes version update
79
79
If the goal of the Nexus cluster upgrade is to ONLY patch or update the Kubernetes minor version, select an available Kubernetes version from the same version bundle series. E.G., if 1.32.1-4.4.0 is your current version bundle, and 1.33.1-4.4.0 is the latest 1.33.x version bundle, then you should choose 1.33.1-4.4.0. This will ensure the current OS and component versions remain the same.
@@ -90,7 +90,7 @@ In the first two cases, you may need to accept an updated Kubernetes version or
90
90
### Components version and breaking changes
91
91
Note the following important changes to make before you upgrade to any of the available minor versions:
92
92
93
-
Note that the azure-arc-k8sagents version refers to the version of this feature shipped with the version bundle. The Arc-enabled Kubernetes agent is set to auto upgrade to the latest version of the agent whenever it's available.
93
+
Note that the azure-arc-k8sagents version refers to the version of this Feature shipped with the version bundle. The Arc-enabled Kubernetes agent is set to auto upgrade to the latest version of the agent whenever it's available.
@@ -182,7 +182,7 @@ Note that the azure-arc-k8sagents version refers to the version of this feature
182
182
| v1.26.3|2|[Azure Linux 2.0.20230904-2.0](https://github.com/microsoft/azurelinux/releases/tag/2.0.20230904-2.0)|1.21.10|v1.0.1|[v3.26.1](https://github.com/projectcalico/calico/releases/tag/v3.26.1)|v0.13.9|[v3.8](https://github.com/k8snetworkplumbingwg/multus-cni/releases/tag/v3.8)|[v3.5.1](https://github.com/k8snetworkplumbingwg/sriov-network-device-plugin/releases/tag/v3.5.1)|[v4.4.0](https://github.com/kubernetes-csi/csi-driver-nfs/releases/tag/v4.4.0)|v1.0.4|[v0.6.3](https://github.com/kubernetes-sigs/metrics-server/releases/tag/v0.6.3)|v1.0.1|v0.1.0|Not Installed|3.8|v3.5.6-5|v1.9.3|v0.5.11|
183
183
| v1.26.3|1|[Azure Linux 2.0.20230904-2.0](https://github.com/microsoft/azurelinux/releases/tag/2.0.20230904-2.0)|1.21.10|v1.0.1|[v3.24.0](https://github.com/projectcalico/calico/releases/tag/v3.24.0)|v0.13.9|[v3.8](https://github.com/k8snetworkplumbingwg/multus-cni/releases/tag/v3.8)|[v3.5.1](https://github.com/k8snetworkplumbingwg/sriov-network-device-plugin/releases/tag/v3.5.1)|[v4.1.0](https://github.com/kubernetes-csi/csi-driver-nfs/releases/tag/v4.1.0)|v1.0.3|[v0.6.3](https://github.com/kubernetes-sigs/metrics-server/releases/tag/v0.6.3)|v1.0.0|v0.1.0|Not Installed|3.8|v3.5.6-5|v1.9.3|v0.5.11|
0 commit comments