Merge pull request #231038 from allyford/retirements-updates

WS2019 and docker retirement, other fixes

Author: v-stsavell

articles/aks/cluster-configuration.md

@@ -12,11 +12,13 @@ As part of creating an AKS cluster, you may need to customize your cluster confi
 
 ## OS configuration
 
-AKS supports Ubuntu 18.04 as the default node operating system (OS) in general availability (GA) for clusters.
+AKS supports Ubuntu 22.04 as the only node operating system (OS) for clusters with Kubernetes 1.25 and higher. Ubuntu 18.04 can also be specified at nodepool creation for Kubernetes versions 1.24 and below. 
+
+AKS supports Windows Server 2022 as the default operating system (OS) for Windows node pools in clusters with Kubernetes 1.25 and higher. Windows Server 2019 can also be specified at nodepool creation for Kubernetes versions 1.32 and below. Windows Server 2019 is being retired after Kubernetes version 1.32 reaches end of life (EOL) and won't be supported in future releases. For more information about this retirement, see the [AKS release notes][aks-release-notes].
 
 ## Container runtime configuration
 
-A container runtime is software that executes containers and manages container images on a node. The runtime helps abstract away sys-calls or operating system (OS) specific functionality to run containers on Linux or Windows. Linux node pools use `containerd` for node pools using Kubernetes version 1.19 and greater. On Windows Server 2019 node pools, `containerd` is generally available and the only container runtime option on Kubernetes 1.21 and greater. Docker is no longer supported as of September 2022. For more information about this deprecation, see the [AKS release notes][aks-release-notes].
+A container runtime is software that executes containers and manages container images on a node. The runtime helps abstract away sys-calls or operating system (OS) specific functionality to run containers on Linux or Windows. For Linux node pools, `containerd` is used on Kubernetes version 1.19 and higher. For Windows Server 2019 and 2022 node pools, `containerd` is generally available and is the only runtime option on Kubernetes version 1.23 and higher. Docker is being retired and won't be supported as of May 2023. For more information about this retirement, see the [AKS release notes][aks-release-notes].
 
 [`Containerd`](https://containerd.io/) is an [OCI](https://opencontainers.org/) (Open Container Initiative) compliant core container runtime that provides the minimum set of required functionality to execute containers and manage images on a node. `Containerd` was [donated](https://www.cncf.io/announcement/2017/03/29/containerd-joins-cloud-native-computing-foundation/) to the Cloud Native Compute Foundation (CNCF) in March of 2017. The current Moby (upstream Docker) version that AKS uses is built on top of `containerd`.
 
@@ -31,7 +33,7 @@ By using `containerd` for AKS nodes, pod startup latency improves and node resou
 > [!IMPORTANT]
 > Clusters with Linux node pools created on Kubernetes v1.19 or greater default to `containerd` for its container runtime. Clusters with node pools on a earlier supported Kubernetes versions receive Docker for their container runtime. Linux node pools will be updated to `containerd` once the node pool Kubernetes version is updated to a version that supports `containerd`.
 >
-> `containerd` with Windows Server 2019 node pools is generally available, and is the only container runtime option in Kubernetes 1.21 and higher. You can continue using Docker node pools and clusters on versions earlier than 1.23, but Docker is no longer supported as of September 2022. For more information, see [Add a Windows Server node pool with `containerd`][aks-add-np-containerd].
+> `containerd` with Windows Server 2019 and 2022 node pools is generally available, and is the only container runtime option in Kubernetes 1.23 and higher. You can continue using Docker node pools and clusters on versions earlier than 1.23, but Docker is no longer supported as of May 2023. For more information, see [Add a Windows Server node pool with `containerd`][aks-add-np-containerd].
 >
 > It is highly recommended you test your workloads on AKS node pools with `containerd` before using clusters with a Kubernetes version that supports `containerd` for your node pools.
 
@@ -57,7 +59,7 @@ Azure supports [Generation 2 (Gen2) virtual machines (VMs)](../virtual-machines/
 Generation 2 VMs use the new UEFI-based boot architecture rather than the BIOS-based architecture used by generation 1 VMs.
 Only specific SKUs and sizes support Gen2 VMs. Check the [list of supported sizes](../virtual-machines/generation-2.md#generation-2-vm-sizes), to see if your SKU supports or requires Gen2.
 
-Additionally not all VM images support Gen2, on AKS Gen2 VMs use the new [AKS Ubuntu 18.04 image](#os-configuration). This image supports all Gen2 SKUs and sizes.
+Additionally, not all VM images support Gen2 VMs. On AKS, Gen2 VMs use [AKS Ubuntu 22.04 or 18.04 image](#os-configuration) or [AKS Windows Server 2022 image](#os-configuration). These images support all Gen2 SKUs and sizes.
 
 ## Default OS disk sizing
 

articles/aks/learn/quick-windows-container-deploy-cli.md

@@ -128,7 +128,7 @@ After a few minutes, the command completes and returns JSON-formatted informatio
 ## Add a Windows node pool
 By default, an AKS cluster is created with a node pool that can run Linux containers. Use the `az aks nodepool add` command to add an additional node pool that can run Windows Server containers alongside the Linux node pool.
 
-AKS supports Windows Server 2019 and Windows Server 2022 node pools. For Kubernetes versions "1.25.0" and higher, Windows Server 2022 is the default operating system. For earlier versions, Windows Server 2019 will be the default operating system.
+AKS supports Windows Server 2019 and Windows Server 2022 node pools. For Kubernetes 1.25 and higher, Windows Server 2022 is the default operating system and only option in Kubernetes 1.33 and higher. For earlier versions, Windows Server 2019 will be the default operating system.
 
 Use the `az aks nodepool add` command to add a Windows nodepool:
 
@@ -146,7 +146,10 @@ The above command creates a new node pool named *npwin* and adds it to the *myAK
 
 ## Add a Windows Server 2019 node pool
 
-When creating a Windows node pool, the default operating system will be Windows Server 2019 for Kubernetes versions below "1.25.0". To use Windows Server 2019 nodes when not default, you will need to specify an OS SKU type of `Windows2019`.
+> [!NOTE]
+> Windows Server 2019 is being retired after Kubernetes version 1.32 reaches end of life (EOL) and won't be supported in future releases. For more information about this retirement, see the [AKS release notes][aks-release-notes].
+
+When creating a Windows node pool, on Kubernetes version 1.24 or earlier, the default operating system will be Windows Server 2019. To use Windows Server 2019 node pools when not the default option, you need to specify an OS SKU type of `Windows2019`.
 
 ```azurecli-interactive
 az aks nodepool add \
@@ -162,7 +165,7 @@ The above command creates a new Windows Server 2019 node pool named *npwin* and
 
 ## Add a Windows Server 2022 node pool
 
-When creating a Windows node pool, the default operating system will be Windows Server 2022 for Kubernetes versions "1.25.0" and higher. To use Windows Server 2022 nodes when not default, you will need to specify an OS SKU type of `Windows2022`.
+When creating a Windows node pool, for Kubernetes 1.25 and higher the default operating system will be Windows Server 2022. To use Windows Server 2022 nodes when not default, you need to specify an OS SKU type of `Windows2022`.
 
 > [!NOTE]
 > Windows Server 2022 requires Kubernetes version "1.23.0" or higher.
@@ -181,7 +184,7 @@ az aks nodepool add \
 
 ## Optional: Using `containerd` with Windows Server node pools
 
-Beginning in Kubernetes version 1.20 and greater, you can specify `containerd` as the container runtime for Windows Server 2019 node pools.  From Kubernetes 1.23, containerd will be the default container runtime for Windows.
+Beginning in Kubernetes version 1.20 and higher, you can specify `containerd` as the container runtime for Windows Server 2019 node pools. Starting with Kubernetes 1.23, `containerd` is the default and only container runtime for Windows.
 
 > [!IMPORTANT]
 > When using `containerd` with Windows Server 2019 node pools:

articles/aks/learn/quick-windows-container-deploy-powershell.md

@@ -54,6 +54,9 @@ The following additional limitations apply to Windows Server node pools:
 * The AKS cluster can have a maximum of 100 nodes in each node pool.
 * The Windows Server node pool name has a limit of 6 characters.
 
+> [!NOTE]
+> Windows Server 2019 is being retired after Kubernetes version 1.32 reaches end of life (EOL) and won't be supported in future releases. For more information about this retirement, see the [AKS release notes][aks-release-notes].
+
 ## Create a resource group
 
 An [Azure resource group](../../azure-resource-manager/management/overview.md)

articles/aks/upgrade-windows-2019-2022.md

@@ -9,11 +9,14 @@ ms.author: viniap
 
 # Upgrade Kubernetes workloads from Windows Server 2019 to 2022
 
-Upgrading the OS version of a running Windows workload on Azure Kubernetes Service (AKS) requires you to deploy a new node pool as Windows versions must match on each node pool. This article describes the steps to upgrade the OS version for Windows workloads as well as other important aspects.
+Upgrading the OS version of a running Windows workload on Azure Kubernetes Service (AKS) requires you to deploy a new node pool as Windows versions must match on each node pool. This article describes the steps to upgrade the OS version for Windows workloads and other important aspects.
+
+> [!NOTE]
+> Windows Server 2019 is being retired after Kubernetes version 1.32 reaches end of life (EOL) and won't be supported in future releases. For more information about this retirement, see the [AKS release notes][aks-release-notes].
 
 ## Limitations
 
-Windows Server 2019 and Windows Server 2022 cannot co-exist on the same node pool on AKS. A new node pool must be created to host the new OS version. It's important that you match the permissions and access of the previous node pool to the new one.
+Windows Server 2019 and Windows Server 2022 can't co-exist on the same node pool on AKS. A new node pool must be created to host the new OS version. It's important that you match the permissions and access of the previous node pool to the new one.
 
 ## Before you begin
 
@@ -27,7 +30,7 @@ Windows Server 2019 and Windows Server 2022 cannot co-exist on the same node poo
 
 ## Add a Windows Server 2022 node pool to the existing cluster
 
-Windows Server 2019 and 2022 cannot co-exist on the same node pool on AKS. To upgrade your application, you need a separate node pool for Windows Server 2022.
+Windows Server 2019 and 2022 can't co-exist on the same node pool on AKS. To upgrade your application, you need a separate node pool for Windows Server 2022.
 For more information on how to add a new Windows Server 2022 node pool to an existing AKS cluster, see [Add a Windows Server 2022 node pool](./learn/quick-windows-container-deploy-cli.md).
 
 ## Update your YAML file
@@ -39,7 +42,7 @@ Node Selector is the most common and recommended option for placement of Windows
         "kubernetes.io/os": windows
 ```
 
-The above annotation will find *any* Windows node available and place the pod on that node (of course, following all other scheduling rules). When upgrading from Windows Server 2019 to Windows Server 2022, you need to enforce not only the placement on a Windows node, but also on a node that is running the latest OS version. To accomplish this, one option is to use a different annotation:
+The above annotation finds *any* Windows node available and places the pod on that node (following all other scheduling rules). When upgrading from Windows Server 2019 to Windows Server 2022, you need to enforce not only the placement on a Windows node, but also on a node that is running the latest OS version. To accomplish this, one option is to use a different annotation:
 
 ```yaml
       nodeSelector:
@@ -49,16 +52,16 @@ The above annotation will find *any* Windows node available and place the pod on
 Once you update the nodeSelector on the YAML file, you should also update the container image to be used. You can get this information from the previous step on which you created a new version of the containerized application by changing the FROM statement on your dockerfile.
 
 > [!NOTE]
-> You should leverage the same YAML file you used to deploy the application in the first place - this will ensure no other configuration is changed, only the nodeSelector and the image to be used.
+> You should leverage the same YAML file you used to deploy the application in the first place - this ensures no other configuration is changed, only the nodeSelector and the image to be used.
 
 ## Apply the new YAML file to the existing workload
 
-If you have an application deployed already, ensure you follow the steps recommended above to deploy a new node pool with Windows Server 2022 nodes. Once deployed, your environment will show Windows Server 2019 and 2022 nodes, with the workloads running on the 2019 nodes:
+If you have an application deployed already, follow the recommended steps to deploy a new node pool with Windows Server 2022 nodes. Once deployed, your environment will show Windows Server 2019 and 2022 nodes, with the workloads running on the 2019 nodes:
 
 ```console
 kubectl get nodes -o wide
 ```
-The command above will show all nodes on your AKS cluster with additional details on the output:
+This command shows all nodes on your AKS cluster with extra details on the output:
 
 ```output
 NAME                                STATUS   ROLES   AGE     VERSION   INTERNAL-IP    EXTERNAL-IP   OS-IMAGE                         KERNEL-VERSION     CONTAINER-RUNTIME
@@ -77,18 +80,18 @@ With the Windows Server 2022 node pool deployed and the YAML file configured, yo
 kubectl apply -f <filename>
 ```
 
-The command above should return a "configured" status for the deployment:
+This command should return a "configured" status for the deployment:
 
 ```output
 deployment.apps/sample configured
 service/sample unchanged
 ```
-At this point, AKS will start the process of terminating the existing pods and deploying new pods to the Windows Server 2022 nodes. You can check the status of your deployment by running:
+At this point, AKS starts the process of terminating the existing pods and deploying new pods to the Windows Server 2022 nodes. You can check the status of your deployment by running:
 
 ```console
 kubectl get pods -o wide
 ```
-The command above return the status of the pods on the default namespace. You might need to change the command above to list the pods on specific namespaces. 
+This command returns the status of the pods on the default namespace. You might need to change the command above to list the pods on specific namespaces. 
 
 ```output
 NAME                      READY   STATUS    RESTARTS   AGE     IP             NODE              NOMINATED NODE   READINESS GATES
@@ -99,6 +102,6 @@ sample-7794bfcc4c-sh78c   1/1     Running   0          2m49s   10.240.0.228   ak
 
 ## Active Directory, gMSA and Managed Identity implications
 
-If you are leveraging Group Managed Service Accounts (gMSA) you will need to update the Managed Identity configuration for the new node pool. gMSA uses a secret (user account and password) so the node on which the Windows pod is running can authenticate the container against Active Directory. To access that secret on Azure Key Vault, the node uses a Managed Identity that allows the node to access the resource. Since Managed Identities are configured per node pool, and the pod now resides on a new node pool, you need to update that configuration. Check out [Enable Group Managed Service Accounts (GMSA) for your Windows Server nodes on your Azure Kubernetes Service (AKS) cluster](./use-group-managed-service-accounts.md) for more information.
+If you're using Group Managed Service Accounts (gMSA), update the Managed Identity configuration for the new node pool. gMSA uses a secret (user account and password) so the node on which the Windows pod is running can authenticate the container against Active Directory. To access that secret on Azure Key Vault, the node uses a Managed Identity that allows the node to access the resource. Since Managed Identities are configured per node pool, and the pod now resides on a new node pool, you need to update that configuration. Check out [Enable Group Managed Service Accounts (GMSA) for your Windows Server nodes on your Azure Kubernetes Service (AKS) cluster](./use-group-managed-service-accounts.md) for more information.
 
 The same principle applies to Managed Identities used for any other pod/node pool when accessing other Azure resources. Any access provided via Managed Identity needs to be updated to reflect the new node pool. To view update and sign-in activities, see [How to view Managed Identity activity](../active-directory/managed-identities-azure-resources/how-to-view-managed-identity-activity.md).

articles/aks/use-windows-hpc.md

@@ -18,34 +18,33 @@ A privileged DaemonSet can carry out changes or monitor a Linux host on Kubernet
 
 * HostProcess containers require Kubernetes 1.23 or greater.
 * HostProcess containers require `containerd` 1.6 or higher container runtime.
-* HostProcess pods can only contain HostProcess containers. This is a current limitation of the Windows operating system. Non-privileged Windows containers can't share a vNIC with the host IP namespace.
+* HostProcess pods can only contain HostProcess containers due to a limitation on the Windows operating system. Non-privileged Windows containers can't share a vNIC with the host IP namespace.
 * HostProcess containers run as a process on the host. The only isolation those containers have from the host is the resource constraints imposed on the HostProcess user account.
 * Filesystem isolation and Hyper-V isolation aren't supported for HostProcess containers.
 * Volume mounts are supported and are mounted under the container volume. See Volume Mounts.
 * A limited set of host user accounts are available for Host Process containers by default. See Choosing a User Account.
 * Resource limits such as disk, memory, and cpu count, work the same way as fashion as processes on the host.
-* Named pipe mounts and Unix domain sockets are not directly supported, but can be accessed on their host path, for example `\\.\pipe\*`.
+* Named pipe mounts and Unix domain sockets aren't directly supported, but can be accessed on their host path, for example `\\.\pipe\*`.
 
 
 ## Run a HostProcess workload
 
-To use HostProcess features with your deployment, set *privilaged: true*, *hostProcess: true*, and *hostNetwork: true*:  
+To use HostProcess features with your deployment, set *hostProcess: true* and *hostNetwork: true*:  
 
 ```yaml
     spec:
       ...
       containers:
           ...
           securityContext:
-            privileged: true
             windowsOptions:
               hostProcess: true
               ...
       hostNetwork: true
       ...
 ```
 
-To run an example workload that uses HostProcess features on an existing AKS cluster with Windows nodes, create `hostprocess.yaml` with the following:
+To run an example workload that uses HostProcess features on an existing AKS cluster with Windows nodes, create `hostprocess.yaml` with the following contents:
 
 ```yaml
 apiVersion: apps/v1
@@ -97,7 +96,7 @@ $ kubectl apply -f hostprocess.yaml
 daemonset.apps/privileged-daemonset created
 ```
 
-You can verify your workload use the features of HostProcess by view the pod's logs.
+Verify that your workload uses the features of HostProcess containers by viewing the pod's logs.
 
 Use `kubectl` to find the name of the pod in the `kube-system` namespace.
 
@@ -119,7 +118,7 @@ Process has admin rights:
 
 ## Next steps
 
-For more details on HostProcess containers and Microsoft's contribution to Kubernetes upstream, see the [Alpha in v1.22: Windows HostProcess Containers][blog-post].
+For more information on HostProcess containers and Microsoft's contribution to Kubernetes upstream, see the [Alpha in v1.22: Windows HostProcess Containers][blog-post].
 
 
 <!-- LINKS - External -->