Merge remote-tracking branch 'upstream/main' into dev-1.24

content/en/docs/concepts/services-networking/ingress-controllers.md

@@ -23,7 +23,7 @@ Kubernetes as a project supports and maintains [AWS](https://github.com/kubernet
 
 {{% thirdparty-content %}}
 
-* [AKS Application Gateway Ingress Controller](https://azure.github.io/application-gateway-kubernetes-ingress/) is an ingress controller that configures the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview).
+* [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).
 * [Ambassador](https://www.getambassador.io/) API Gateway is an [Envoy](https://www.envoyproxy.io)-based ingress
   controller.
 * [Apache APISIX ingress controller](https://github.com/apache/apisix-ingress-controller) is an [Apache APISIX](https://github.com/apache/apisix)-based ingress controller.

content/en/docs/concepts/services-networking/service.md

@@ -109,12 +109,45 @@ field.
 {{< /note >}}
 
 Port definitions in Pods have names, and you can reference these names in the
-`targetPort` attribute of a Service. This works even if there is a mixture
-of Pods in the Service using a single configured name, with the same network
-protocol available via different port numbers.
-This offers a lot of flexibility for deploying and evolving your Services.
-For example, you can change the port numbers that Pods expose in the next
-version of your backend software, without breaking clients.
+`targetPort` attribute of a Service. For example, we can bind the `targetPort`
+of the Service to the Pod port in the following way:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: nginx
+  labels:
+    app.kubernetes.io/name: proxy
+spec:
+  containers:
+  - name: nginx
+    image: nginx:11.14.2
+    ports:
+      - containerPort: 80
+        name: http-web-svc
+        
+---
+apiVersion: v1
+kind: Service
+metadata:
+  name: nginx-service
+spec:
+  selector:
+    app.kubernetes.io/name: proxy
+  ports:
+  - name: name-of-service-port
+    protocol: TCP
+    port: 80
+    targetPort: http-web-svc
+```
+
+
+This works even if there is a mixture of Pods in the Service using a single
+configured name, with the same network protocol available via different 
+port numbers. This offers a lot of flexibility for deploying and evolving 
+your Services. For example, you can change the port numbers that Pods expose 
+in the next version of your backend software, without breaking clients.
 
 The default protocol for Services is TCP; you can also use any other
 [supported protocol](#protocol-support).

content/en/docs/concepts/services-networking/topology-aware-hints.md

@@ -19,6 +19,12 @@ those network endpoints can be routed closer to where it originated.
 For example, you can route traffic within a locality to reduce
 costs, or to improve network performance.
 
+{{< note >}}
+The "topology-aware hints" feature is at Beta stage and it is **NOT** enabled
+by default. To try out this feature, you have to enable the `TopologyAwareHints`
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/).
+{{< /note >}}
+
 <!-- body -->
 
 ## Motivation