Updated docs.microsoft.com to learn.microsoft.com in English

bismayam · bismayam · commit ca7fd70f952f · 2025-09-29T10:35:15.000+05:30
diff --git a/content/en/blog/_posts/2020-06-30-SIG-Windows-Spotlight/index.md b/content/en/blog/_posts/2020-06-30-SIG-Windows-Spotlight/index.md
@@ -35,7 +35,7 @@ So when it comes to running containers on Windows, there are actually two very i
 * Native Windows processes running as native Windows Server style containers,
 * and traditional Linux containers running on a Linux Kernel, generally hosted on a lightweight Hyper-V Virtual Machine.
 
-You can learn more about Linux and Windows containers in this [tutorial](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/linux-containers) from Microsoft.
+You can learn more about Linux and Windows containers in this [tutorial](https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/linux-containers) from Microsoft.
 
 
 
diff --git a/content/en/docs/concepts/configuration/windows-resource-management.md b/content/en/docs/concepts/configuration/windows-resource-management.md
@@ -20,7 +20,7 @@ as a pod boundary for resource control. Containers are created within that bound
 for network, process and file system isolation. The Linux cgroup APIs can be used to
 gather CPU, I/O, and memory use statistics.
 
-In contrast, Windows uses a [_job object_](https://docs.microsoft.com/windows/win32/procthread/job-objects) per container with a system namespace filter
+In contrast, Windows uses a [_job object_](https://learn.microsoft.com/windows/win32/procthread/job-objects) per container with a system namespace filter
 to contain all processes in a container and provide logical isolation from the
 host.
 (Job objects are a Windows process isolation mechanism and are different from
@@ -49,11 +49,11 @@ Windows can limit the amount of CPU time allocated for different processes but c
 guarantee a minimum amount of CPU time.
 
 On Windows, the kubelet supports a command-line flag to set the
-[scheduling priority](https://docs.microsoft.com/windows/win32/procthread/scheduling-priorities) of the
+[scheduling priority](https://learn.microsoft.com/windows/win32/procthread/scheduling-priorities) of the
 kubelet process: `--windows-priorityclass`. This flag allows the kubelet process to get
 more CPU time slices when compared to other processes running on the Windows host.
 More information on the allowable values and their meaning is available at
-[Windows Priority Classes](https://docs.microsoft.com/en-us/windows/win32/procthread/scheduling-priorities#priority-class).
+[Windows Priority Classes](https://learn.microsoft.com/en-us/windows/win32/procthread/scheduling-priorities#priority-class).
 To ensure that running Pods do not starve the kubelet of CPU cycles, set this flag to `ABOVE_NORMAL_PRIORITY_CLASS` or above.
 
 ## Resource reservation {#resource-reservation}
diff --git a/content/en/docs/concepts/security/_index.md b/content/en/docs/concepts/security/_index.md
@@ -86,7 +86,7 @@ Amazon Web Services | https://aws.amazon.com/security |
 Google Cloud Platform | https://cloud.google.com/security |
 Huawei Cloud | https://www.huaweicloud.com/intl/en-us/securecenter/overallsafety |
 IBM Cloud | https://www.ibm.com/cloud/security |
-Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security |
+Microsoft Azure | https://learn.microsoft.com/en-us/azure/security/azure-security |
 Oracle Cloud Infrastructure | https://www.oracle.com/security |
 Tencent Cloud | https://www.tencentcloud.com/solutions/data-security-and-information-protection |
 VMware vSphere | https://www.vmware.com/solutions/security/hardening-guides |
diff --git a/content/en/docs/concepts/security/windows-security.md b/content/en/docs/concepts/security/windows-security.md
@@ -23,7 +23,7 @@ operator, you should take both of the following additional measures:
 
 1. Use file ACLs to secure the Secrets' file location.
 1. Apply volume-level encryption using
-   [BitLocker](https://docs.microsoft.com/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server).
+   [BitLocker](https://learn.microsoft.com/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server).
 
 ## Container users
 
@@ -34,7 +34,7 @@ processes as specific user. This is roughly equivalent to
 
 Windows containers offer two default user accounts, ContainerUser and ContainerAdministrator.
 The differences between these two user accounts are covered in
-[When to use ContainerAdmin and ContainerUser user accounts](https://docs.microsoft.com/virtualization/windowscontainers/manage-containers/container-security#when-to-use-containeradmin-and-containeruser-user-accounts)
+[When to use ContainerAdmin and ContainerUser user accounts](https://learn.microsoft.com/virtualization/windowscontainers/manage-containers/container-security#when-to-use-containeradmin-and-containeruser-user-accounts)
 within Microsoft's _Secure Windows containers_ documentation.
 
 Local users can be added to container images during the container build process.
diff --git a/content/en/docs/concepts/services-networking/dns-pod-service.md b/content/en/docs/concepts/services-networking/dns-pod-service.md
@@ -379,7 +379,7 @@ this problem.
   Windows treats all names with a `.` as a FQDN and skips FQDN resolution.
 - On Windows, there are multiple DNS resolvers that can be used. As these come with
   slightly different behaviors, using the
-  [`Resolve-DNSName`](https://docs.microsoft.com/powershell/module/dnsclient/resolve-dnsname)
+  [`Resolve-DNSName`](https://learn.microsoft.com/powershell/module/dnsclient/resolve-dnsname)
   powershell cmdlet for name query resolutions is recommended.
 - On Linux, you have a DNS suffix list, which is used after resolution of a name as fully
   qualified has failed.
diff --git a/content/en/docs/concepts/services-networking/ingress-controllers.md b/content/en/docs/concepts/services-networking/ingress-controllers.md
@@ -27,7 +27,7 @@ Kubernetes as a project supports and maintains [AWS](https://github.com/kubernet
 
 {{% thirdparty-content %}}
 
-* [AKS Application Gateway Ingress Controller](https://docs.microsoft.com/azure/application-gateway/tutorial-ingress-controller-add-on-existing?toc=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Faks%2Ftoc.json&bc=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fbread%2Ftoc.json) is an ingress controller that configures the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview).
+* [AKS Application Gateway Ingress Controller](https://learn.microsoft.com/azure/application-gateway/tutorial-ingress-controller-add-on-existing?toc=https%3A%2F%2Flearn.microsoft.com%2Fen-us%2Fazure%2Faks%2Ftoc.json&bc=https%3A%2F%2Flearn.microsoft.com%2Fen-us%2Fazure%2Fbread%2Ftoc.json) is an ingress controller that configures the [Azure Application Gateway](https://learn.microsoft.com/azure/application-gateway/overview).
 * [Alibaba Cloud MSE Ingress](https://www.alibabacloud.com/help/en/mse/user-guide/overview-of-mse-ingress-gateways) is an ingress controller that configures the [Alibaba Cloud Native Gateway](https://www.alibabacloud.com/help/en/mse/product-overview/cloud-native-gateway-overview?spm=a2c63.p38356.0.0.20563003HJK9is), which is also the commercial version of [Higress](https://github.com/alibaba/higress).
 * [Apache APISIX ingress controller](https://github.com/apache/apisix-ingress-controller) is an [Apache APISIX](https://github.com/apache/apisix)-based ingress controller.
 * [Avi Kubernetes Operator](https://github.com/vmware/load-balancer-and-ingress-services-for-kubernetes) provides L4-L7 load-balancing using [VMware NSX Advanced Load Balancer](https://avinetworks.com/).
diff --git a/content/en/docs/concepts/services-networking/windows-networking.md b/content/en/docs/concepts/services-networking/windows-networking.md
@@ -53,7 +53,7 @@ with recommendations on when to use each CNI:
 | Network Driver | Description | Container Packet Modifications | Network Plugins | Network Plugin Characteristics |
 | -------------- | ----------- | ------------------------------ | --------------- | ------------------------------ |
 | L2bridge       | Containers are attached to an external vSwitch. Containers are attached to the underlay network, although the physical network doesn't need to learn the container MACs because they are rewritten on ingress/egress. | MAC is rewritten to host MAC, IP may be rewritten to host IP using HNS OutboundNAT policy. | [win-bridge](https://www.cni.dev/plugins/current/main/win-bridge/), [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md), [Flannel host-gateway](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#host-gw) uses win-bridge | win-bridge uses L2bridge network mode, connects containers to the underlay of hosts, offering best performance. Requires user-defined routes (UDR) for inter-node connectivity. |
-| L2Tunnel | This is a special case of l2bridge, but only used on Azure. All packets are sent to the virtualization host where SDN policy is applied. | MAC rewritten, IP visible on the underlay network | [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) | Azure-CNI allows integration of containers with Azure vNET, and allows them to leverage the set of capabilities that [Azure Virtual Network provides](https://azure.microsoft.com/en-us/services/virtual-network/). For example, securely connect to Azure services or use Azure NSGs. See [azure-cni for some examples](https://docs.microsoft.com/azure/aks/concepts-network#azure-cni-advanced-networking) |
+| L2Tunnel | This is a special case of l2bridge, but only used on Azure. All packets are sent to the virtualization host where SDN policy is applied. | MAC rewritten, IP visible on the underlay network | [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) | Azure-CNI allows integration of containers with Azure vNET, and allows them to leverage the set of capabilities that [Azure Virtual Network provides](https://azure.microsoft.com/en-us/services/virtual-network/). For example, securely connect to Azure services or use Azure NSGs. See [azure-cni for some examples](https://learn.microsoft.com/azure/aks/concepts-network#azure-cni-advanced-networking) |
 | Overlay | Containers are given a vNIC connected to an external vSwitch. Each overlay network gets its own IP subnet, defined by a custom IP prefix.The overlay network driver uses VXLAN encapsulation. | Encapsulated with an outer header. | [win-overlay](https://www.cni.dev/plugins/current/main/win-overlay/), [Flannel VXLAN](https://github.com/flannel-io/flannel/blob/master/Documentation/backends.md#vxlan) (uses win-overlay) | win-overlay should be used when virtual container networks are desired to be isolated from underlay of hosts (e.g. for security reasons). Allows for IPs to be re-used for different overlay networks (which have different VNID tags)  if you are restricted on IPs in your datacenter.  This option requires [KB4489899](https://support.microsoft.com/help/4489899) on Windows Server 2019. |
 | Transparent (special use case for [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)) | Requires an external vSwitch. Containers are attached to an external vSwitch which enables intra-pod communication via logical networks (logical switches and routers). | Packet is encapsulated either via [GENEVE](https://datatracker.ietf.org/doc/draft-gross-geneve/) or [STT](https://datatracker.ietf.org/doc/draft-davie-stt/) tunneling to reach pods which are not on the same host.  <br/> Packets are forwarded or dropped via the tunnel metadata information supplied by the ovn network controller. <br/> NAT is done for north-south communication. | [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes) | [Deploy via ansible](https://github.com/openvswitch/ovn-kubernetes/tree/master/contrib). Distributed ACLs can be applied via Kubernetes policies. IPAM support. Load-balancing can be achieved without kube-proxy. NATing is done without using iptables/netsh. |
 | NAT (*not used in Kubernetes*) | Containers are given a vNIC connected to an internal vSwitch. DNS/DHCP is provided using an internal component called [WinNAT](https://techcommunity.microsoft.com/t5/virtualization/windows-nat-winnat-capabilities-and-limitations/ba-p/382303) | MAC and IP is rewritten to host MAC/IP. | [nat](https://github.com/Microsoft/windows-container-networking/tree/master/plugins/nat) | Included here for completeness |
@@ -91,7 +91,7 @@ The following IPAM options are supported on Windows:
 
 * [host-local](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/host-local)
 * [azure-vnet-ipam](https://github.com/Azure/azure-container-networking/blob/master/docs/ipam.md) (for azure-cni only)
-* [Windows Server IPAM](https://docs.microsoft.com/windows-server/networking/technologies/ipam/ipam-top) (fallback option if no IPAM is set)
+* [Windows Server IPAM](https://learn.microsoft.com/windows-server/networking/technologies/ipam/ipam-top) (fallback option if no IPAM is set)
 
 ## Direct Server Return (DSR) {#dsr}
 
@@ -117,7 +117,7 @@ In a cluster that includes Windows nodes, you can use the following types of Ser
 * `ExternalName`
 
 Windows container networking differs in some important ways from Linux networking.
-The [Microsoft documentation for Windows Container Networking](https://docs.microsoft.com/en-us/virtualization/windowscontainers/container-networking/architecture)
+The [Microsoft documentation for Windows Container Networking](https://learn.microsoft.com/en-us/virtualization/windowscontainers/container-networking/architecture)
 provides additional details and background.
 
 On Windows, you can use the following settings to configure Services and load
diff --git a/content/en/docs/concepts/storage/storage-limits.md b/content/en/docs/concepts/storage/storage-limits.md
@@ -59,7 +59,7 @@ volumes to be attached to a Node. For other instance types on
 <a href="https://aws.amazon.com/ec2/">Amazon Elastic Compute Cloud (EC2)</a>,
 Kubernetes allows 39 volumes to be attached to a Node.
 
-* On Azure, up to 64 disks can be attached to a node, depending on the node type. For more details, refer to [Sizes for virtual machines in Azure](https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes).
+* On Azure, up to 64 disks can be attached to a node, depending on the node type. For more details, refer to [Sizes for virtual machines in Azure](https://learn.microsoft.com/en-us/azure/virtual-machines/windows/sizes).
 
 * If a CSI storage driver advertises a maximum number of volumes for a Node (using `NodeGetInfo`), the {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}} honors that limit.
 Refer to the [CSI specifications](https://github.com/container-storage-interface/spec/blob/master/spec.md#nodegetinfo) for details.
diff --git a/content/en/docs/concepts/windows/intro.md b/content/en/docs/concepts/windows/intro.md
@@ -41,7 +41,7 @@ Windows Server 2019 or Windows Server 2022.
 
 This document uses the term *Windows containers* to mean Windows containers with
 process isolation. Kubernetes does not support running Windows containers with
-[Hyper-V isolation](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container).
+[Hyper-V isolation](https://learn.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container).
 
 ## Compatibility and limitations {#limitations}
 
@@ -168,7 +168,7 @@ At a high level, these OS concepts are different:
   are represented as integer types. User and group names
   are not canonical - they are just an alias in `/etc/groups`
   or `/etc/passwd` back to UID+GID. Windows uses a larger binary
-  [security identifier](https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/security-identifiers) (SID)
+  [security identifier](https://learn.microsoft.com/en-us/windows/security/identity-protection/access-control/security-identifiers) (SID)
   which is stored in the Windows Security Access Manager (SAM) database. This
   database is not shared between the host and containers, or between containers.
 * File permissions - Windows uses an access control list based on (SIDs), whereas
@@ -195,7 +195,7 @@ work between Windows and Linux:
 
 * Huge pages are not implemented in the Windows container
   runtime, and are not available. They require [asserting a user
-  privilege](https://docs.microsoft.com/en-us/windows/desktop/Memory/large-page-support)
+  privilege](https://learn.microsoft.com/en-us/windows/desktop/Memory/large-page-support)
   that's not configurable for containers.
 * `requests.cpu` and `requests.memory` - requests are subtracted
   from node available resources, so they can be used to avoid overprovisioning a
@@ -293,7 +293,7 @@ is available on GitHub.
 Microsoft maintains a different multi-architecture image, with Linux and Windows
 amd64 support, that you can find as `mcr.microsoft.com/oss/kubernetes/pause:3.6`.
 This image is built from the same source as the Kubernetes maintained image but
-all of the Windows binaries are [authenticode signed](https://docs.microsoft.com/en-us/windows-hardware/drivers/install/authenticode) by Microsoft.
+all of the Windows binaries are [authenticode signed](https://learn.microsoft.com/en-us/windows-hardware/drivers/install/authenticode) by Microsoft.
 The Kubernetes project recommends using the Microsoft maintained image if you are
 deploying to a production or production-like environment that requires signed
 binaries.
@@ -424,8 +424,8 @@ The Kubernetes [cluster API](https://cluster-api.sigs.k8s.io/) project also prov
 ## Windows distribution channels
 
 For a detailed explanation of Windows distribution channels see the
-[Microsoft documentation](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19).
+[Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19).
 
 Information on the different Windows Server servicing channels
 including their support models can be found at
-[Windows Server servicing channels](https://docs.microsoft.com/en-us/windows-server/get-started/servicing-channels-comparison).
+[Windows Server servicing channels](https://learn.microsoft.com/en-us/windows-server/get-started/servicing-channels-comparison).
diff --git a/content/en/docs/contribute/style/style-guide.md b/content/en/docs/contribute/style/style-guide.md
@@ -50,7 +50,7 @@ in the [API Reference](/docs/reference/kubernetes-api/). When writing
 general documentation, it's better to use upper camel case, calling it "ConfigMap" instead.
 
 When you are generally discussing an API object, use
-[sentence-style capitalization](https://docs.microsoft.com/en-us/style-guide/text-formatting/using-type/use-sentence-style-capitalization).
+[sentence-style capitalization](https://learn.microsoft.com/en-us/style-guide/text-formatting/using-type/use-sentence-style-capitalization).
 
 The following examples focus on capitalization. For more information about formatting
 API object names, review the related guidance on [Code Style](#code-style-inline-code).
diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates/HyperVContainer.md b/content/en/docs/reference/command-line-tools-reference/feature-gates/HyperVContainer.md
@@ -20,5 +20,5 @@ stages:
 removed: true
 ---
 Enable
-[Hyper-V isolation](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container)
+[Hyper-V isolation](https://learn.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container)
 for Windows containers.
diff --git a/content/en/docs/tasks/configure-pod-container/configure-gmsa.md b/content/en/docs/tasks/configure-pod-container/configure-gmsa.md
@@ -9,7 +9,7 @@ weight: 30
 {{< feature-state for_k8s_version="v1.18" state="stable" >}}
 
 This page shows how to configure
-[Group Managed Service Accounts](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview) (GMSA)
+[Group Managed Service Accounts](https://learn.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview) (GMSA)
 for Pods and containers that will run on Windows nodes. Group Managed Service Accounts
 are a specific type of Active Directory account that provides automatic password management,
 simplified service principal name (SPN) management, and the ability to delegate the management
@@ -69,10 +69,10 @@ manually (with appropriate substitutions for the parameters)
 
 Before Pods in Kubernetes can be configured to use GMSAs, the desired GMSAs need
 to be provisioned in Active Directory as described in the
-[Windows GMSA documentation](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#BKMK_Step1).
+[Windows GMSA documentation](https://learn.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#BKMK_Step1).
 Windows worker nodes (that are part of the Kubernetes cluster) need to be configured
 in Active Directory to access the secret credentials associated with the desired GMSA as described in the
-[Windows GMSA documentation](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#to-add-member-hosts-using-the-set-adserviceaccount-cmdlet).
+[Windows GMSA documentation](https://learn.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#to-add-member-hosts-using-the-set-adserviceaccount-cmdlet).
 
 ## Create GMSA credential spec resources
 
diff --git a/content/en/docs/tasks/configure-pod-container/configure-runasusername.md b/content/en/docs/tasks/configure-pod-container/configure-runasusername.md
diff --git a/content/en/docs/tasks/configure-pod-container/create-hostprocess-pod.md b/content/en/docs/tasks/configure-pod-container/create-hostprocess-pod.md
diff --git a/content/en/docs/tasks/debug/debug-cluster/windows.md b/content/en/docs/tasks/debug/debug-cluster/windows.md
