Sync documentation

documentation/3.4/content/userguide/istio/istio.md

@@ -35,7 +35,7 @@ These instructions assume that you are using a Kubernetes cluster with
 [Istio](https://istio.io/latest/docs/setup/install/) installed and configured already.  The operator will not install
 Istio for you.
 
-For Red Hat OpenShift Service Mesh, which has its own implementation of Istio, refer to the correct version of the documentation for installation. 
+For Red Hat OpenShift Service Mesh, which has its own implementation of Istio, refer to the correct version of the documentation for installation.
 [OpenShift Service Mesh installation 4.10](https://docs.openshift.com/container-platform/4.10/service_mesh/v2x/installing-ossm.html)
 
 {{% /notice %}}
@@ -53,7 +53,7 @@ sample application to familiarize yourself with the mesh and verify that it is w
 
 
 To learn more about Istio,
-see [What is Istio](https://istio.io/latest/docs/concepts/what-is-istio/).  
+see [What is Istio](https://istio.io/latest/docs/concepts/what-is-istio/).
 
 For Redhat OpenShift Service Mesh, see
 
@@ -78,7 +78,7 @@ The current support for Istio has these limitations:
   does not have an `EXTERNAL-IP` defined and
   you would like to externally run WLST commands,
   then see
-  [Use WLST]({{< relref "/userguide/managing-domains/accessing-the-domain/wlst.md" >}}).  
+  [Use WLST]({{< relref "/userguide/managing-domains/accessing-the-domain/wlst.md" >}}).
 
 #### Determining the Istio version
 
@@ -156,7 +156,7 @@ $ kubectl label namespace domain1 istio-injection=enabled
 
 To enable Istio support for a domain, you need to add a
 `domain.spec.configuration.istio` section to your domain custom resource YAML file,
-as shown in the following example:  
+as shown in the following example:
 
 ```yaml
 apiVersion: "weblogic.oracle/v8"
@@ -181,7 +181,7 @@ See the following description of each `spec.configuration.istio` attribute:
 * `enabled`: To enable Istio support, you must include the `istio` section
   and set `enabled: true` as shown.
 * `readinessPort`: This attribute is optional
-   and defaults to `8888` if not provided; it is used for a readiness health check.
+  and defaults to `8888` if not provided; it is used for a readiness health check.
 * `replicationChannelPort`: This attribute is optional and defaults to `4564` if not provided;
   the operator will create a `T3` protocol WebLogic network access point on each WebLogic
   Server that is part of a cluster with this port to handle EJB and servlet session state
@@ -197,7 +197,7 @@ See the following description of each `spec.configuration.istio` attribute:
   Use `true` for Istio versions prior to 1.10 and set to `false` for versions 1.10 and later.
 
   |Istio version|localhostBindingsEnabled|Notes|
-     |----|----|----|
+       |----|----|----|
   |Pre-1.10|`true`|Supported. Note that `true` is the default.|
   |Pre-1.10|`false`|Not supported.|
   |1.10 and later|`true`|Not supported.|
@@ -515,7 +515,7 @@ Istio provides rich sets of security features that you can use to secure the Ist
 
 ##### Mutual TLS
 
-By default, all traffic between the Istio sidecar proxies use mutual TLS within the mesh. However, service within the mesh can still be accessed by other pods outside the mesh.  For example, you have `domain-1`  deployed with sidecar injection, therefore within the mesh, and another domain, `domain-2`, deployed without sidecar injection, therefore outside of the mesh. Services within `domain-2` can still access the services within `domain-1`, however the traffic will be `Plain` unencrypted traffic.   This is because by default, Istio configures the traffic using the `PERMISSIVE` mode, which means it can accept both `Plain` and `mutual TLS` traffic.  You can restrict this behavior by allowing only `mutual TLS` traffic by locking down the entire mesh or by namespace within the mesh.   
+By default, all traffic between the Istio sidecar proxies use mutual TLS within the mesh. However, service within the mesh can still be accessed by other pods outside the mesh.  For example, you have `domain-1`  deployed with sidecar injection, therefore within the mesh, and another domain, `domain-2`, deployed without sidecar injection, therefore outside of the mesh. Services within `domain-2` can still access the services within `domain-1`, however the traffic will be `Plain` unencrypted traffic.   This is because by default, Istio configures the traffic using the `PERMISSIVE` mode, which means it can accept both `Plain` and `mutual TLS` traffic.  You can restrict this behavior by allowing only `mutual TLS` traffic by locking down the entire mesh or by namespace within the mesh.
 
 For locking down the entire mesh, you can:
 
@@ -698,4 +698,4 @@ spec:
       - 'regular-domain.org'
 ```
 
-See Istio [Ingress](https://istio.io/latest/docs/tasks/traffic-management/ingress).
+See Istio [Ingress](https://istio.io/latest/docs/tasks/traffic-management/ingress).

documentation/3.4/content/userguide/prerequisites/introduction.md

@@ -7,7 +7,7 @@ weight: 2
 
 For the current production release {{< latestVersion >}}:
 
-* Kubernetes 1.19.15+, 1.20.11+, 1.21.5+, 1.22.5+, 1.23.4+, and 1.24.0+ (check with `kubectl version`).
+* Kubernetes 1.19.15+, 1.20.11+, 1.21.5+, 1.22.5+, and 1.23.4+ (check with `kubectl version`).
 * Flannel networking v0.13.0-amd64 or later (check with `docker images | grep flannel`), Calico networking v3.16.1 or later,
  *or* OpenShift SDN on OpenShift 4.3 systems.
 * Docker 19.03.1+ (check with `docker version`) *or* CRI-O 1.20.2+ (check with `crictl version | grep RuntimeVersion`).