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

content/en/docs/tutorials/clusters/apparmor.md

@@ -233,7 +233,7 @@ kubectl get events | grep hello-apparmor
 We can verify that the container is actually running with that profile by checking its proc attr:
 
 ```shell
-kubectl exec hello-apparmor cat /proc/1/attr/current
+kubectl exec hello-apparmor -- cat /proc/1/attr/current
 ```
 ```
 k8s-apparmor-example-deny-write (enforce)
@@ -242,7 +242,7 @@ k8s-apparmor-example-deny-write (enforce)
 Finally, we can see what happens if we try to violate the profile by writing to a file:
 
 ```shell
-kubectl exec hello-apparmor touch /tmp/test
+kubectl exec hello-apparmor -- touch /tmp/test
 ```
 ```
 touch: /tmp/test: Permission denied

content/en/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html

@@ -72,7 +72,7 @@ weight: 10
         <div class="row">
             <div class="col-md-8">
                 <p><b>The Control Plane is responsible for managing the cluster.</b> The Control Plane coordinates all activities in your cluster, such as scheduling applications, maintaining applications' desired state, scaling applications, and rolling out new updates.</p>
-                <p><b>A node is a VM or a physical computer that serves as a worker machine in a Kubernetes cluster.</b> Each node has a Kubelet, which is an agent for managing the node and communicating with the Kubernetes control plane. The node should also have tools for handling container operations, such as containerd or Docker. A Kubernetes cluster that handles production traffic should have a minimum of three nodes.</p>
+                <p><b>A node is a VM or a physical computer that serves as a worker machine in a Kubernetes cluster.</b> Each node has a Kubelet, which is an agent for managing the node and communicating with the Kubernetes control plane. The node should also have tools for handling container operations, such as containerd or Docker. A Kubernetes cluster that handles production traffic should have a minimum of three nodes because if one node goes down, both an etcd member and a control plane instance are lost, and redundancy is compromised. You can mitigate this risk by adding more control plane nodes.</p>
 
             </div>
             <div class="col-md-4">

content/en/docs/tutorials/services/source-ip.md

@@ -164,7 +164,7 @@ The `client_address` is always the client pod's IP address, whether the client p
 ## Source IP for Services with `Type=NodePort`
 
 Packets sent to Services with
-[`Type=NodePort`](/docs/concepts/services-networking/service/#nodeport)
+[`Type=NodePort`](/docs/concepts/services-networking/service/#type-nodeport)
 are source NAT'd by default. You can test this by creating a `NodePort` Service:
 
 ```shell

content/en/docs/tutorials/stateful-application/zookeeper.md

@@ -266,7 +266,7 @@ to read the data from another.
 The command below executes the `zkCli.sh` script to write `world` to the path `/hello` on the `zk-0` Pod in the ensemble.
 
 ```shell
-kubectl exec zk-0 zkCli.sh create /hello world
+kubectl exec zk-0 -- zkCli.sh create /hello world
 ```
 
 ```
@@ -279,7 +279,7 @@ Created /hello
 To get the data from the `zk-1` Pod use the following command.
 
 ```shell
-kubectl exec zk-1 zkCli.sh get /hello
+kubectl exec zk-1 -- zkCli.sh get /hello
 ```
 
 The data that you created on `zk-0` is available on all the servers in the