Merge pull request #97974 from jluk/master

rev n-2 ETA 12/9/19

Author: ktoliver

articles/aks/supported-kubernetes-versions.md

@@ -6,7 +6,7 @@ author: sauryadas
 
 ms.service: container-service
 ms.topic: article
-ms.date: 05/20/2019
+ms.date: 12/09/2019
 ms.author: saudas
 ---
 
@@ -17,8 +17,7 @@ improvements. Patch releases are more frequent (sometimes weekly) and are only i
 minor version. These patch releases include fixes for security vulnerabilities or major bugs impacting a large number
 of customers and products running in production based on Kubernetes.
 
-AKS aims to certify and release new Kubernetes versions within 30 days of an upstream release, subject to the stability
-of the release.
+AKS aims to certify and release new Kubernetes versions within 30 days of an upstream release, subject to the stability of the release.
 
 ## Kubernetes versions
 
@@ -39,75 +38,62 @@ Each number in the version indicates general compatibility with the previous ver
 * Minor versions change when functionality changes are made that are backwards compatible to the other minor releases.
 * Patch versions change when backwards-compatible bug fixes are made.
 
-In general, users should endeavor to run the latest patch release of the minor version they are running, for example if
-your production cluster is on *1.12.14* and *1.12.15* is the latest available patch version available for the *1.12*
-series, you should upgrade to *1.12.15* as soon as you are able to ensure your cluster is fully patched and supported.
+Users should aim to run the latest patch release of the minor version they are running, for example if
+your production cluster is on *1.12.14* and *1.12.15* is the latest available patch version available for the *1.12* series, you should upgrade to *1.12.15* as soon as you are able to ensure your cluster is fully patched and supported.
 
 ## Kubernetes version support policy
 
-> [!NOTE]
-> Starting December 9th, 2019 AKS will move to supporting latest (N) - 2 versions of Kubernetes. This change is to conform to the upstream window of support for Kubernetes versions and ensure the latest and most secure versions are being used. To learn more read the [announcement here](https://azure.microsoft.com/updates/azure-kubernetes-service-will-be-retiring-support-for-kubernetes-versions-1-11-and-1-12/).
-
-AKS supports four minor versions of Kubernetes:
+AKS supports three minor versions of Kubernetes:
 
 * The current minor version that is released in AKS (N)
-* Three previous minor versions. Each supported minor version also supports two stable patches.
+* Two previous minor versions. Each supported minor version also supports two stable patches.
 
-This is known as "N-3" - (N (Latest release) - 3 (minor versions)).
+This is known as "N-2": (N (Latest release) - 2 (minor versions)).
 
-For example, if AKS introduces *1.13.a* today, support is provided for the following versions:
+For example, if AKS introduces *1.15.a* today, support is provided for the following versions:
 
 New minor version    |    Supported Version List
 -----------------    |    ----------------------
-1.13.a               |    1.12.a, 1.12.b, 1.11.a, 1.11.b, 1.10.a, 1.10.b
+1.15.a               |    1.15.a, 1.15.b, 1.14.c, 1.14.d, 1.13.e, 1.13.f
 
-Where ".a" and ".b" are representative patch versions."a" from 1.13.a can be different from 1.12.a. For example, 1.13.9 and 1.12.8.
+Where ".letter" is representative of patch versions.
 
 For details on communications regarding version changes and expectations, see "Communications" below.
 
-When a new minor version is introduced, the oldest minor version and patch releases supported are deprecated and
-removed. For example if the current supported version list is:
+When a new minor version is introduced, the oldest minor version and patch releases supported are deprecated and removed. For example, if the current supported version list is:
 
 ```
-1.12.a
-1.12.b
-1.11.a
-1.11.b
-1.10.a
-1.10.b
-1.9.a
-1.9.b
+1.15.a
+1.15.b
+1.14.c
+1.14.d
+1.13.e
+1.13.f
 ```
 
-And AKS releases 1.13.*, this means that the 1.9.* versions (all 1.9 versions) will be removed and out of support.
+And AKS releases 1.16.*, this means that the 1.13.* versions (all 1.13 versions) will be removed and out of support.
 
 > [!NOTE]
 > Please note, that if customers are running an unsupported Kubernetes version, they will be asked to upgrade when
 > requesting support for the cluster. Clusters running unsupported Kubernetes releases are not covered by the
 > [AKS support policies](https://docs.microsoft.com/azure/aks/support-policies).
 
-
-In addition to the above on minor versions, AKS supports the two latest *patch** releases of a given minor version. For
-example, given the following supported versions:
+In addition to the above on minor versions, AKS supports the two latest **patch** releases of a given minor version. For example, given the following supported versions:
 
 ```
 Current Supported Version List
 ------------------------------
-1.12.1, 1.12.2, 1.11.4, 1.11.5
+1.15.2, 1.15.1, 1.14.5, 1.14.4
 ```
 
-If upstream Kubernetes released 1.12.3 and 1.11.6 and AKS releases those patch versions, the oldest patch versions
-are deprecated and removed, and the supported version list becomes:
+If upstream Kubernetes released 1.15.3 and 1.14.6 and AKS releases those patch versions, the oldest patch versions are deprecated and removed, and the supported version list becomes:
 
 ```
 New Supported Version List
 ----------------------
-1.12.*2*, 1.12.*3*, 1.11.*5*, 1.11.*6*
+1.15.*3*, 1.15.*2*, 1.14.*6*, 1.14.*5*
 ```
 
-> [!NOTE]
-> Customers should not pin cluster creation, CI or other automated jobs to specific patch releases. 
-
 ### Communications
 
 * For new **minor** versions of Kubernetes
@@ -119,17 +105,11 @@ New Supported Version List
   * Users have **30 days** to upgrade to a newer, supported patch release. Users have **30 days** to upgrade to
     a supported patch release before the oldest is removed.
 
-AKS defines "released" as general availability, enabled in all SLO / Quality of Service measurements and
-available in all regions.
-
-> [!NOTE]
-> Customers are notified of Kubernetes version releases and deprecations, when a minor version is
-> deprecated/removed users are given 60 days to upgrade to a supported release. In the case of patch releases,
-> customers are given 30 days to upgrade to a supported release.
+AKS defines a "released version" as the generally available versions, enabled in all SLO / Quality of Service measurements and available in all regions. AKS may also support preview versions which are explicitly labeled and subject to Preview terms and conditions.
 
 #### Notification channels for AKS changes
 
-AKS releases a weekly service update which summarizes new Kubernetes versions, service changes, and component updates that have been released on the service on [github](https://github.com/Azure/AKS/releases).
+AKS publishes regular service updates which summarize new Kubernetes versions, service changes, and component updates that have been released on the service on [GitHub](https://github.com/Azure/AKS/releases).
 
 These changes are rolled to all customers as part of regular maintenance that is offered as part of the managed service, some require explicit upgrades while others require no action.
 
@@ -139,62 +119,37 @@ Notifications are also sent via:
 * Azure portal notifications
 * [Azure update channel][azure-update-channel]
 
-### Policy Exceptions
+### Supported Versions Policy Exceptions
 
-AKS reserves the right to add or remove new/existing versions that have been identified to have one or more critical
-production impacting bugs or security issues without advance notice.
+AKS reserves the right to add or remove new/existing versions that have been identified to have one or more critical production impacting bugs or security issues without advance notice.
 
 Specific patch releases may be skipped, or rollout accelerated depending on the severity of the bug or security issue.
 
 ### Azure portal and CLI default versions
 
-When you deploy an AKS cluster in the portal or with the Azure CLI, the cluster is always set to the N-1 minor version
-and latest patch. For example, if AKS supports *1.13.a*, *1.12.a* + *1.12.b*, *1.11.a* + *1.11.b*, *1.10.a* + *1.10b*,
-the default version for new clusters is *1.12.b*.
+When you deploy an AKS cluster in the portal or with the Azure CLI, the cluster is defaulted to the N-1 minor version and latest patch. For example, if AKS supports *1.15.a*, *1.15.b*, *1.14.c*, *1.14.d*,  *1.13.e*, and *1.13.f*, the default version selected is *1.14.c*.
 
-AKS defaults to N-1 (minor.latestPatch, eg 1.12.b) to provide customers a known, stable and patched version by default.
+AKS chooses the default of N-1 to provide customers a known, stable, and patched version by default.
 
 ## List currently supported versions
 
 To find out what versions are currently available for your subscription and region, use the
-[az aks get-versions][az-aks-get-versions] command. The following example lists the available Kubernetes versions for
-the *EastUS* region:
+[az aks get-versions][az-aks-get-versions] command. The following example lists the available Kubernetes versions for the *EastUS* region:
 
 ```azurecli-interactive
 az aks get-versions --location eastus --output table
 ```
 
-The output is similar to the following example, which shows that Kubernetes version *1.14.6* is the most recent version
-available:
-
-```
-KubernetesVersion    Upgrades
--------------------  ------------------------
-1.14.6               None available
-1.14.5               1.14.6
-1.13.10              1.14.5, 1.14.6
-1.13.9               1.13.10, 1.14.5, 1.14.6
-1.12.8               1.13.9, 1.13.10
-1.12.7               1.12.8, 1.13.9, 1.13.10
-1.11.10              1.12.7, 1.12.8
-1.11.9               1.11.10, 1.12.7, 1.12.8
-1.10.13              1.11.9, 1.11.10
-1.10.12              1.10.13, 1.11.9, 1.11.10
-```
-
 ## FAQ
 
 **What happens when a customer upgrades a Kubernetes cluster with a minor version that is not supported?**
 
-If you are on the *n-4* version, you are outside of support and will be asked to upgrade. If your upgrade from version
-n-4 to n-3 succeeds, you are now within our support policies. For example:
+If you are on the *n-3* version, you are outside of support and will be asked to upgrade. If your upgrade from version n-3 to n-2 succeeds, you are now within our support policies. For example:
 
-- If the supported AKS versions are *1.13.a*, *1.12.b* + *1.12.c*, *1.11.d* + *1.11.e*, and *1.10.f* + *1.10.g* and you
-  are on *1.9.h* or *1.9.i*, you are outside of support.
-- If the upgrade from *1.9.h* or *1.9.i* to *1.10.f* or *1.10.g* succeeds, you are back in the within our support policies.
+- If the oldest supported AKS version is are *1.13.a* and you are on *1.12.b* or older, you are outside of support.
+- If the upgrade from *1.12.b* to *1.13.a* or higher succeeds, you are back in the within our support policies.
 
-Upgrades to versions older than *n-4* are not supported. In such cases, we recommend customers create new AKS clusters
-and redeploy their workloads.
+Upgrades to versions older than the supported window of *N-2* are not supported. In such cases, we recommend customers create new AKS clusters and redeploy their workloads with versions in the supported window.
 
 **What does 'Out of Support' mean**
 
@@ -204,16 +159,16 @@ runtime or other guarantees for clusters outside of the supported versions list.
 
 **What happens when a customer scales a Kubernetes cluster with a minor version that is not supported?**
 
-For minor versions not supported by AKS, scaling in or out continues to work without any issues.
+For minor versions not supported by AKS, scaling in or out should continue to work but it is highly recommended to upgrade to bring your cluster back into support.
 
 **Can a customer stay on a Kubernetes version forever?**
 
 Yes. However, if the cluster is not on one of the versions supported by AKS, the cluster is out of the AKS support
 policies. Azure does not automatically upgrade your cluster or delete it.
 
-**What version does the master support if the agent cluster is not in one of the supported AKS versions?**
+**What version does the control plane support if the node pool is not in one of the supported AKS versions?**
 
-The master is automatically updated to the latest supported version.
+The control plane must be within a window of versions from all node pools. For details on upgrading the control plane or node pools, visit documentation on [upgrading node pools](use-multiple-node-pools.md#upgrade-a-cluster-control-plane-with-multiple-node-pools).
 
 ## Next steps
 

articles/aks/use-multiple-node-pools.md

@@ -34,7 +34,7 @@ The following limitations apply when you create and manage AKS clusters that sup
 * You can't add or delete node pools using an existing Resource Manager template as with most operations. Instead, [use a separate Resource Manager template](#manage-node-pools-using-a-resource-manager-template) to make changes to node pools in an AKS cluster.
 * The name of a node pool may only contain lowercase alphanumeric characters and must begin with a lowercase letter. For Linux node pools the length must be between 1 and 12 characters, for Windows node pools the length must be between 1 and 6 characters.
 * The AKS cluster can have a maximum of eight node pools.
-* The AKS cluster can have a maximum of 400 nodes across those eight node pools.
+* The AKS cluster can have a maximum of 800 nodes across those eight node pools.
 * All node pools must reside in the same subnet.
 
 ## Create an AKS cluster