From fdf0b8e9cd66292fb39d53f19e3640774f0d5a6a Mon Sep 17 00:00:00 2001
From: Eitan Suez <eitan@tetrate.io>
Date: Mon, 8 Apr 2024 15:45:04 -0500
Subject: [PATCH] revises instructions to render yaml in yaml format, removing
 the kubectl apply -f - <<EOF part (#3137)

Signed-off-by: Eitan Suez <eitan@tetrate.io>
---
 site/content/en/latest/install/custom-cert.md |  22 ++-
 .../tasks/operations/customize-envoyproxy.md  |  65 ++++----
 .../tasks/operations/deployment-mode.md       |  27 ++--
 .../tasks/security/private-key-provider.md    |  86 +++++------
 .../latest/tasks/security/secure-gateways.md  |  14 +-
 .../latest/tasks/traffic/connection-limit.md  |   7 +-
 .../en/latest/tasks/traffic/http-redirect.md  |  27 ++--
 site/content/en/latest/tasks/traffic/http3.md |   7 +-
 .../user/extensibility/envoy-patch-policy.md  |  28 ++--
 .../en/v1.0.1/user/security/backend-tls.md    |  14 +-
 .../en/v1.0.1/user/security/basic-auth.md     |   7 +-
 site/content/en/v1.0.1/user/security/cors.md  |   7 +-
 .../en/v1.0.1/user/security/ext-auth.md       |  35 +++--
 .../en/v1.0.1/user/security/mutual-tls.md     |   7 +-
 site/content/en/v1.0.1/user/security/oidc.md  |  14 +-
 .../en/v1.0.1/user/traffic/circuit-breaker.md |   7 +-
 .../user/traffic/client-traffic-policy.md     |  28 ++--
 .../en/v1.0.1/user/traffic/fault-injection.md |  15 +-
 .../v1.0.1/user/traffic/global-rate-limit.md  |  78 +++++-----
 .../en/v1.0.1/user/traffic/grpc-routing.md    |  12 +-
 .../user/traffic/http-request-headers.md      |  28 ++--
 .../user/traffic/http-request-mirroring.md    |  23 ++-
 .../user/traffic/http-response-headers.md     |  28 ++--
 .../en/v1.0.1/user/traffic/http-routing.md    |   7 +-
 .../en/v1.0.1/user/traffic/http-timeouts.md   |  14 +-
 .../user/traffic/http-traffic-splitting.md    |  34 +++--
 .../en/v1.0.1/user/traffic/http-urlrewrite.md |  21 +--
 .../v1.0.1/user/traffic/local-rate-limit.md   |  28 ++--
 site/content/en/v1.0.1/user/traffic/retry.md  |   7 +-
 .../traffic/routing-outside-kubernetes.md     | 143 +++++++++---------
 .../en/v1.0.1/user/traffic/tcp-routing.md     |  21 ++-
 .../en/v1.0.1/user/traffic/udp-routing.md     |   5 +-
 32 files changed, 448 insertions(+), 418 deletions(-)

diff --git a/site/content/en/latest/install/custom-cert.md b/site/content/en/latest/install/custom-cert.md
index dd059c03520..91dd91b2298 100644
--- a/site/content/en/latest/install/custom-cert.md
+++ b/site/content/en/latest/install/custom-cert.md
@@ -17,8 +17,8 @@ We use Cert-Manager to manage the certificates. You can install it by following
 
    *You should not use the self-signed issuer in production, you should use a real CA issuer.*
 
-   ```shell
-   cat <<EOF | kubectl apply -f -
+   ```yaml
+   ---
    apiVersion: cert-manager.io/v1
    kind: Issuer
    metadata:
@@ -56,13 +56,12 @@ We use Cert-Manager to manage the certificates. You can install it by following
    spec:
      ca:
        secretName: envoy-gateway-ca
-   EOF
    ```
 
-2. Create a cert for envoy gateway controller, the cert will be stored in secret `envoy-gatewy`.
+2. Create a cert for envoy gateway controller, the cert will be stored in secret `envoy-gateway`.
 
-   ```shell
-   cat<<EOF | kubectl apply -f -
+   ```yaml
+   ---
    apiVersion: cert-manager.io/v1
    kind: Certificate
    metadata:
@@ -86,13 +85,12 @@ We use Cert-Manager to manage the certificates. You can install it by following
      - "key encipherment"
      - "content commitment"
      secretName: envoy-gateway
-   EOF
    ```
 
 3. Create a cert for envoy proxy, the cert will be stored in secret `envoy`.
 
-   ```shell
-   cat<<EOF | kubectl apply -f -
+   ```yaml
+   ---
    apiVersion: cert-manager.io/v1
    kind: Certificate
    metadata:
@@ -113,13 +111,12 @@ We use Cert-Manager to manage the certificates. You can install it by following
      - "key encipherment"
      - "content commitment"
      secretName: envoy
-   EOF
    ```
 
 4. Create a cert for rate limit, the cert will be stored in secret `envoy-rate-limit`.
 
-   ```shell
-   cat<<EOF | kubectl apply -f -
+   ```yaml
+   ---
    apiVersion: cert-manager.io/v1
    kind: Certificate
    metadata:
@@ -140,7 +137,6 @@ We use Cert-Manager to manage the certificates. You can install it by following
      - "key encipherment"
      - "content commitment"
      secretName: envoy-rate-limit
-   EOF
    ```
 
 5. Now you can follow the helm chart [installation guide](../install-helm) to install envoy gateway with custom certs.
diff --git a/site/content/en/latest/tasks/operations/customize-envoyproxy.md b/site/content/en/latest/tasks/operations/customize-envoyproxy.md
index 76004a83676..43623282220 100644
--- a/site/content/en/latest/tasks/operations/customize-envoyproxy.md
+++ b/site/content/en/latest/tasks/operations/customize-envoyproxy.md
@@ -15,8 +15,10 @@ Before proceeding, you should be able to query the example backend using HTTP.
 
 First, you need to add ParametersRef in GatewayClass, and refer to EnvoyProxy Config:
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: GatewayClass
 metadata:
@@ -28,15 +30,14 @@ spec:
     kind: EnvoyProxy
     name: custom-proxy-config
     namespace: envoy-gateway-system
-EOF
 ```
 
 ## Customize EnvoyProxy Deployment Replicas
 
 You can customize the EnvoyProxy Deployment Replicas via EnvoyProxy Config like:
 
-```shell
-cat <<EOF | kubectl apply -f -
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: EnvoyProxy
 metadata:
@@ -48,13 +49,12 @@ spec:
     kubernetes:
       envoyDeployment:
         replicas: 2
-EOF
 ```
 
 After you apply the config, you should see the replicas of envoyproxy changes to 2.
 And also you can dynamically change the value.
 
-``` shell
+```shell
 kubectl get deployment -l gateway.envoyproxy.io/owning-gateway-name=eg -n envoy-gateway-system
 ```
 
@@ -62,8 +62,8 @@ kubectl get deployment -l gateway.envoyproxy.io/owning-gateway-name=eg -n envoy-
 
 You can customize the EnvoyProxy Image via EnvoyProxy Config like:
 
-```shell
-cat <<EOF | kubectl apply -f -
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: EnvoyProxy
 metadata:
@@ -76,7 +76,6 @@ spec:
       envoyDeployment:
         container:
           image: envoyproxy/envoy:v1.25-latest
-EOF
 ```
 
 After applying the config, you can get the deployment image, and see it has changed.
@@ -85,8 +84,8 @@ After applying the config, you can get the deployment image, and see it has chan
 
 You can customize the EnvoyProxy Pod Annotations via EnvoyProxy Config like:
 
-```shell
-cat <<EOF | kubectl apply -f -
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: EnvoyProxy
 metadata:
@@ -101,7 +100,6 @@ spec:
           annotations:
             custom1: deploy-annotation1
             custom2: deploy-annotation2
-EOF
 ```
 
 After applying the config, you can get the envoyproxy pods, and see new annotations has been added.
@@ -110,8 +108,8 @@ After applying the config, you can get the envoyproxy pods, and see new annotati
 
 You can customize the EnvoyProxy Deployment Resources via EnvoyProxy Config like:
 
-```shell
-cat <<EOF | kubectl apply -f -
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: EnvoyProxy
 metadata:
@@ -130,15 +128,14 @@ spec:
             limits:
               cpu: 500m
               memory: 1Gi
-EOF
 ```
 
 ## Customize EnvoyProxy Deployment Env
 
 You can customize the EnvoyProxy Deployment Env via EnvoyProxy Config like:
 
-```shell
-cat <<EOF | kubectl apply -f -
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: EnvoyProxy
 metadata:
@@ -155,7 +152,6 @@ spec:
             value: env_a_value
           - name: env_b
             value: env_b_value
-EOF
 ```
 
 > Envoy Gateway has provided two initial `env` `ENVOY_GATEWAY_NAMESPACE` and `ENVOY_POD_NAME` for envoyproxy container.
@@ -166,8 +162,8 @@ After applying the config, you can get the envoyproxy deployment, and see resour
 
 You can customize the EnvoyProxy Deployment Volumes or VolumeMounts via EnvoyProxy Config like:
 
-```shell
-cat <<EOF | kubectl apply -f -
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: EnvoyProxy
 metadata:
@@ -188,7 +184,6 @@ spec:
           - name: certs
             secret:
               secretName: envoy-cert
-EOF
 ```
 
 After applying the config, you can get the envoyproxy deployment, and see resources has been changed.
@@ -197,8 +192,8 @@ After applying the config, you can get the envoyproxy deployment, and see resour
 
 You can customize the EnvoyProxy Service Annotations via EnvoyProxy Config like:
 
-```shell
-cat <<EOF | kubectl apply -f -
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: EnvoyProxy
 metadata:
@@ -212,8 +207,6 @@ spec:
         annotations:
           custom1: svc-annotation1
           custom2: svc-annotation2
-
-EOF
 ```
 
 After applying the config, you can get the envoyproxy service, and see annotations has been added.
@@ -226,8 +219,8 @@ There are two ways to customize it:
 * Replace: the whole bootstrap config will be replaced by the config you provided.
 * Merge: the config you provided will be merged into the default bootstrap config.
 
-```shell
-cat <<EOF | kubectl apply -f -
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: EnvoyProxy
 metadata:
@@ -307,7 +300,6 @@ spec:
               ads: {}
               resource_api_version: V3
             name: runtime-0
-EOF
 ```
 
 You can use [egctl translate][]
@@ -323,8 +315,8 @@ You can enable [Horizontal Pod Autoscaler](https://github.com/envoyproxy/gateway
 
 Once confirmed, you can apply it via EnvoyProxy Config as shown below:
 
-```shell
-cat <<EOF | kubectl apply -f -
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: EnvoyProxy
 metadata:
@@ -344,7 +336,6 @@ spec:
                 averageUtilization: 60
                 type: Utilization
             type: Resource
-EOF
 ```
 
 After applying the config, the EnvoyProxy HPA (Horizontal Pod Autoscaler) is generated. However, upon activating the EnvoyProxy's HPA, the Envoy Gateway will no longer reference the `replicas` field specified in the `envoyDeployment`, as outlined [here](#customize-envoyproxy-deployment-replicas).
@@ -354,8 +345,8 @@ After applying the config, the EnvoyProxy HPA (Horizontal Pod Autoscaler) is gen
 You can customize the EnvoyProxy Command line options via `spec.extraArgs` in EnvoyProxy Config.
 For example, the following configuration will add `--disable-extensions` arg in order to disable `envoy.access_loggers/envoy.access_loggers.wasm` extension:
 
-```shell
-cat <<EOF | kubectl apply -f -
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: EnvoyProxy
 metadata:
@@ -364,7 +355,6 @@ metadata:
 spec:
   extraArgs:
     - --disable-extensions envoy.access_loggers/envoy.access_loggers.wasm 
-EOF
 ```
 
 ## Customize EnvoyProxy with Patches
@@ -373,8 +363,8 @@ You can customize the EnvoyProxy using patches.
 
 For example, the following configuration will add resource limits to the `envoy` and the `shutdown-manager` containers in the `envoyproxy` deployment:
 
-```shell
-cat <<EOF | kubectl apply -f -
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: EnvoyProxy
 metadata:
@@ -402,7 +392,6 @@ spec:
                       limits:
                         cpu: 200m
                         memory: 1024Mi
-EOF
 ```
 
 After applying the configuration, you will see the change in both containers in the `envoyproxy` deployment.
diff --git a/site/content/en/latest/tasks/operations/deployment-mode.md b/site/content/en/latest/tasks/operations/deployment-mode.md
index dd3ea9ea6f8..2e1649bc13c 100644
--- a/site/content/en/latest/tasks/operations/deployment-mode.md
+++ b/site/content/en/latest/tasks/operations/deployment-mode.md
@@ -44,7 +44,7 @@ and **creates** managed data plane resources such as EnvoyProxy `Deployment` in
 each `tenant` deploy their own Envoy Gateway controller in their respective `namespace`. Below is an example of deploying Envoy Gateway
 by the `marketing` and `product` teams in separate namespaces.
 
-* Lets deploy Envoy Gateway in the `marketing` namespace and also watch resources only in this namespace. We are also setting the controller name to a unique string here `gateway.envoyproxy.io/marketing-gatewayclass-controller`.
+* Deploy Envoy Gateway in the `marketing` namespace and also watch resources only in this namespace. We are also setting the controller name to a unique string here `gateway.envoyproxy.io/marketing-gatewayclass-controller`.
 
 ```shell
 helm install \
@@ -55,10 +55,12 @@ eg-marketing oci://docker.io/envoyproxy/gateway-helm \
 --version v0.0.0-latest -n marketing --create-namespace
 ```
 
-Lets create a `GatewayClass` linked to the marketing team's Envoy Gateway controller, and as well other resources linked to it, so the `backend` application operated by this team can be exposed to external clients.
+Create a `GatewayClass` linked to the marketing team's Envoy Gateway controller, and as well other resources linked to it, so the `backend` application operated by this team can be exposed to external clients.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resources to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: GatewayClass
 metadata:
@@ -155,7 +157,6 @@ spec:
         - path:
             type: PathPrefix
             value: /
-EOF
 ```
 
 Lets port forward to the generated envoy proxy service in the `marketing` namespace and send a request to it.
@@ -233,10 +234,10 @@ eg-product oci://docker.io/envoyproxy/gateway-helm \
 --version v0.0.0-latest -n product --create-namespace
 ```
 
-Lets create a `GatewayClass` linked to the product team's Envoy Gateway controller, and as well other resources linked to it, so the `backend` application operated by this team can be exposed to external clients.
+Create a `GatewayClass` linked to the product team's Envoy Gateway controller, and as well other resources linked to it, so the `backend` application operated by this team can be exposed to external clients.
 
-```shell
-cat <<EOF | kubectl apply -f -
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: GatewayClass
 metadata:
@@ -333,10 +334,9 @@ spec:
         - path:
             type: PathPrefix
             value: /
-EOF
 ```
 
-Lets port forward to the generated envoy proxy service in the `product` namespace and send a request to it.
+Port-forward to the generated envoy proxy service in the `product` namespace and send a request to it.
 
 ```shell
 export ENVOY_SERVICE=$(kubectl get svc -n product --selector=gateway.envoyproxy.io/owning-gateway-namespace=product,gateway.envoyproxy.io/owning-gateway-name=eg -o jsonpath='{.items[0].metadata.name}')
@@ -606,10 +606,10 @@ Install the GatewayClass, Gateway, HTTPRoute and example app from [Quickstart][]
 kubectl apply -f https://github.com/envoyproxy/gateway/releases/download/latest/quickstart.yaml -n default
 ```
 
-Lets create also and additional `Gateway` linked to the GatewayClass and `backend` application from Quickstart example.
+Create an additional `Gateway` linked to the GatewayClass and `backend` application from Quickstart example.
 
-```shell
-cat <<EOF | kubectl apply -f -
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: Gateway
 metadata:
@@ -643,7 +643,6 @@ spec:
         - path:
             type: PathPrefix
             value: /
-EOF
 ```
 
 Verify that Gateways are deployed and programmed
diff --git a/site/content/en/latest/tasks/security/private-key-provider.md b/site/content/en/latest/tasks/security/private-key-provider.md
index 447e61cb353..c84ef895df5 100644
--- a/site/content/en/latest/tasks/security/private-key-provider.md
+++ b/site/content/en/latest/tasks/security/private-key-provider.md
@@ -114,25 +114,24 @@ It required the node with 3rd generation Intel Xeon Scalable processor server pr
 
 * Follow the steps from the [Quickstart](../quickstart) to install Envoy Gateway.
 
-* Lets enable the EnvoyPatchPolicy feature, which will allow us to directly configure the Private Key Provider Envoy Filter, since Envoy Gateway does not directly expose this functionality.
-
-  ```shell
-  cat <<EOF | kubectl apply -f -
-  apiVersion: v1
-  kind: ConfigMap
-  metadata:
-    name: envoy-gateway-config
-    namespace: envoy-gateway-system
-  data:
-    envoy-gateway.yaml: |
-      apiVersion: gateway.envoyproxy.io/v1alpha1
-      kind: EnvoyGateway
-      gateway:
-        controllerName: gateway.envoyproxy.io/gatewayclass-controller
-      extensionApis:
-        enableEnvoyPatchPolicy: true
-  EOF
-  ```
+* Enable the EnvoyPatchPolicy feature, which will allow us to directly configure the Private Key Provider Envoy Filter, since Envoy Gateway does not directly expose this functionality.
+
+    ```yaml
+    ---
+    apiVersion: v1
+    kind: ConfigMap
+    metadata:
+      name: envoy-gateway-config
+      namespace: envoy-gateway-system
+    data:
+      envoy-gateway.yaml: |
+        apiVersion: gateway.envoyproxy.io/v1alpha1
+        kind: EnvoyGateway
+        gateway:
+          controllerName: gateway.envoyproxy.io/gatewayclass-controller
+        extensionApis:
+          enableEnvoyPatchPolicy: true
+    ```
 
 * After updating the `ConfigMap`, you will need to restart the `envoy-gateway` deployment so the configuration kicks in
 
@@ -146,28 +145,27 @@ It required the node with 3rd generation Intel Xeon Scalable processor server pr
 
 * Update GatewayClass for using the envoyproxy image with contrib extensions and requests required resources.
 
-  ```shell
-  cat <<EOF | kubectl apply -f -
-  apiVersion: gateway.networking.k8s.io/v1
-  kind: GatewayClass
-  metadata:
-    name: eg
-  spec:
-    controllerName: gateway.envoyproxy.io/gatewayclass-controller
-    parametersRef:
-      group: gateway.envoyproxy.io
-      kind: EnvoyProxy
-      name: custom-proxy-config
-      namespace: envoy-gateway-system
-  EOF
-  ```
+    ```yaml
+    ---
+    apiVersion: gateway.networking.k8s.io/v1
+    kind: GatewayClass
+    metadata:
+      name: eg
+    spec:
+      controllerName: gateway.envoyproxy.io/gatewayclass-controller
+      parametersRef:
+        group: gateway.envoyproxy.io
+        kind: EnvoyProxy
+        name: custom-proxy-config
+        namespace: envoy-gateway-system
+    ```
 
 ### Change EnvoyProxy configuration for QAT
 
 Using the envoyproxy image with contrib extensions and add qat resources requesting, ensure the k8s scheduler find out a machine with required resource.
 
-```shell
-cat <<EOF | kubectl apply -f -
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: EnvoyProxy
 metadata:
@@ -192,15 +190,14 @@ spec:
               cpu: 1000m
               memory: 4096Mi
               qat.intel.com/cy: '1'
-EOF
 ```
 
 ### Change EnvoyProxy configuration for CryptoMB
 
 Using the envoyproxy image with contrib extensions and add the node affinity to scheduling the Envoy Gateway pod on the machine with required CPU instructions.
 
-```shell
-cat <<EOF | kubectl apply -f -
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: EnvoyProxy
 metadata:
@@ -239,7 +236,6 @@ spec:
                     operator: Exists
                   - key: feature.node.kubernetes.io/cpu-cpuid.AVX512VBMI2
                     operator: Exists
-EOF
 ```
 
 Or using `preferredDuringSchedulingIgnoredDuringExecution` for best effort scheduling, or not doing any node affinity, just doing the random scheduling. The CryptoMB private key provider supports software fallback if the required CPU instructions aren't here.
@@ -276,8 +272,8 @@ fortio load -c 10 -k -qps 0 -t 30s -keepalive=false https://www.example.com:${NO
 
 ### For QAT
 
-```shell
-cat <<EOF | kubectl apply -f -
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: EnvoyPatchPolicy
 metadata:
@@ -311,13 +307,12 @@ spec:
         op: copy
         from: "/tls_certificate/private_key"
         path: "/tls_certificate/private_key_provider/typed_config/private_key"
-EOF
 ```
 
 ### For CryptoMB
 
-```shell
-cat <<EOF | kubectl apply -f -
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: EnvoyPatchPolicy
 metadata:
@@ -351,7 +346,6 @@ spec:
         op: copy
         from: "/tls_certificate/private_key"
         path: "/tls_certificate/private_key_provider/typed_config/private_key"
-EOF
 ```
 
 ### Benchmark after enabling private key provider
diff --git a/site/content/en/latest/tasks/security/secure-gateways.md b/site/content/en/latest/tasks/security/secure-gateways.md
index f1f1f525526..f9342bb691e 100644
--- a/site/content/en/latest/tasks/security/secure-gateways.md
+++ b/site/content/en/latest/tasks/security/secure-gateways.md
@@ -171,8 +171,10 @@ Before proceeding, ensure you can query the HTTPS backend service from the [Test
 To demonstrate cross namespace certificate references, create a ReferenceGrant that allows Gateways from the "default"
 namespace to reference Secrets in the "envoy-gateway-system" namespace:
 
-```console
-$ cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1alpha2
 kind: ReferenceGrant
 metadata:
@@ -186,7 +188,6 @@ spec:
   to:
   - group: ""
     kind: Secret
-EOF
 ```
 
 Delete the previously created Secret:
@@ -210,8 +211,10 @@ kubectl create secret tls example-cert -n envoy-gateway-system --key=www.example
 
 Update the Gateway HTTPS listener with `namespace: envoy-gateway-system`, for example:
 
-```console
-$ cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: Gateway
 metadata:
@@ -232,7 +235,6 @@ spec:
             group: ""
             name: example-cert
             namespace: envoy-gateway-system
-EOF
 ```
 
 The Gateway HTTPS listener status should now surface the `Ready: True` condition and you should once again be able to
diff --git a/site/content/en/latest/tasks/traffic/connection-limit.md b/site/content/en/latest/tasks/traffic/connection-limit.md
index 138e620bf9b..0660ab8d11f 100644
--- a/site/content/en/latest/tasks/traffic/connection-limit.md
+++ b/site/content/en/latest/tasks/traffic/connection-limit.md
@@ -57,8 +57,10 @@ There are no connection limits, and so all 100 requests succeed.
 
 Next, we apply a limit of 5 connections. 
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: ClientTrafficPolicy
 metadata:
@@ -73,7 +75,6 @@ spec:
   connection:
     connectionLimit:
       value: 5    
-EOF
 ```
 
 Execute the load simulation again.
diff --git a/site/content/en/latest/tasks/traffic/http-redirect.md b/site/content/en/latest/tasks/traffic/http-redirect.md
index 8639c2c9d7c..4f92be017ee 100644
--- a/site/content/en/latest/tasks/traffic/http-redirect.md
+++ b/site/content/en/latest/tasks/traffic/http-redirect.md
@@ -19,8 +19,10 @@ Redirects return HTTP 3XX responses to a client, instructing it to retrieve a di
 For example, to issue a permanent redirect (301) from HTTP to HTTPS, configure `requestRedirect.statusCode=301` and
 `requestRedirect.scheme="https"`:
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -38,7 +40,6 @@ spec:
           statusCode: 301
           hostname: www.example.com
           port: 443
-EOF
 ```
 
 __Note:__ `301` (default) and `302` are the only supported statusCodes.
@@ -104,8 +105,10 @@ kubectl create secret tls example-com --key=tls.key --cert=tls.crt
 
 Define a https listener on the existing gateway
 
-```shell
-cat <<EOF | kubectl apply -n default -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: Gateway
 metadata:
@@ -126,7 +129,6 @@ spec:
       certificateRefs:
       - kind: Secret
         name: example-com
-EOF
 ```
 
 Check for any TLS certificate issues on the gateway.
@@ -137,9 +139,10 @@ kubectl -n default describe gateway eg
 
 Create two HTTPRoutes and attach them to the HTTP and HTTPS listeners using the [sectionName][] field.
 
+Apply the following resources to your cluster:
 
-```shell
-cat <<EOF | kubectl apply -n default -f -
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -178,7 +181,6 @@ spec:
         - path:
             type: PathPrefix
             value: /
-EOF
 ```
 
 Curl the example app through http listener:
@@ -200,8 +202,10 @@ curl -v -H 'Host:www.example.com' --resolve "www.example.com:443:$GATEWAY_HOST"
 Path redirects use an HTTP Path Modifier to replace either entire paths or path prefixes. For example, the HTTPRoute
 below will issue a 302 redirect to all `path.redirect.example` requests whose path begins with `/get` to `/status/200`.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -226,7 +230,6 @@ spec:
       backendRefs:
       - name: backend
         port: 3000
-EOF
 ```
 
 The HTTPRoute status should indicate that it has been accepted and is bound to the example Gateway.
diff --git a/site/content/en/latest/tasks/traffic/http3.md b/site/content/en/latest/tasks/traffic/http3.md
index 3b83bc7def5..50704b01c6b 100644
--- a/site/content/en/latest/tasks/traffic/http3.md
+++ b/site/content/en/latest/tasks/traffic/http3.md
@@ -60,10 +60,10 @@ kubectl patch gateway eg --type=json --patch '[{
 }]'
 ```
 
-Apply the following ClientTrafficPolicy to enable HTTP3
+Apply the following ClientTrafficPolicy to enable HTTP3:
 
-```shell
-kubectl apply -f - <<EOF
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: ClientTrafficPolicy
 metadata:
@@ -75,7 +75,6 @@ spec:
     kind: Gateway
     name: eg
     namespace: default
-EOF
 ```
 
 Verify the Gateway status:
diff --git a/site/content/en/v1.0.1/user/extensibility/envoy-patch-policy.md b/site/content/en/v1.0.1/user/extensibility/envoy-patch-policy.md
index 5f24f448969..94a673a6c96 100644
--- a/site/content/en/v1.0.1/user/extensibility/envoy-patch-policy.md
+++ b/site/content/en/v1.0.1/user/extensibility/envoy-patch-policy.md
@@ -27,14 +27,15 @@ Before proceeding, you should be able to query the example backend using HTTP.
 
 ### Enable EnvoyPatchPolicy
 
-* By default [EnvoyPatchPolicy][] is disabled. Lets enable it in the [EnvoyGateway][] startup configuration
+* By default [EnvoyPatchPolicy][] is disabled. Let's enable it in the [EnvoyGateway][] startup configuration
 
 * The default installation of Envoy Gateway installs a default [EnvoyGateway][] configuration and attaches it
 using a `ConfigMap`. In the next step, we will update this resource to enable EnvoyPatchPolicy.
 
+Apply the following resource to your cluster:
 
-```shell
-cat <<EOF | kubectl apply -f -
+```yaml
+---
 apiVersion: v1
 kind: ConfigMap
 metadata:
@@ -50,7 +51,6 @@ data:
       controllerName: gateway.envoyproxy.io/gatewayclass-controller
     extensionApis:
       enableEnvoyPatchPolicy: true
-EOF
 ```
 
 * After updating the `ConfigMap`, you will need to restart the `envoy-gateway` deployment so the configuration kicks in
@@ -63,13 +63,13 @@ kubectl rollout restart deployment envoy-gateway -n envoy-gateway-system
 
 ### Customize Response
 
-* Lets use EnvoyProxy's [Local Reply Modification][] feature to return a custom response back to the client when
+* Use EnvoyProxy's [Local Reply Modification][] feature to return a custom response back to the client when
 the status code is `404`
 
-* Lets apply the configuration
+* Apply the configuration to your cluster:
 
-```shell
-cat <<EOF | kubectl apply -f -
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: EnvoyPatchPolicy
 metadata:
@@ -101,14 +101,15 @@ spec:
             status_code: 406
             body:
               inline_string: "could not find what you are looking for"
-EOF
 ```
 
 When mergeGateways is enabled, there will be one Envoy deployment for all Gateways in the cluster.
 Then the EnvoyPatchPolicy should target a specific GatewayClass.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: EnvoyPatchPolicy
 metadata:
@@ -140,10 +141,9 @@ spec:
             status_code: 406
             body:
               inline_string: "could not find what you are looking for"
-EOF
 ```
 
-* Lets edit the HTTPRoute resource from the Quickstart to only match on paths with value `/get`
+* Edit the HTTPRoute resource from the Quickstart to only match on paths with value `/get`
 
 ```
 kubectl patch httproute backend --type=json --patch '[{
@@ -153,7 +153,7 @@ kubectl patch httproute backend --type=json --patch '[{
 }]'
 ```
 
-* Lets test it out by specifying a path apart from `/get`
+* Test it out by specifying a path apart from `/get`
 
 ```
 $ curl --header "Host: www.example.com" http://localhost:8888/find
diff --git a/site/content/en/v1.0.1/user/security/backend-tls.md b/site/content/en/v1.0.1/user/security/backend-tls.md
index c7ce67251c3..da7d1199949 100644
--- a/site/content/en/v1.0.1/user/security/backend-tls.md
+++ b/site/content/en/v1.0.1/user/security/backend-tls.md
@@ -103,8 +103,10 @@ kubectl patch deployment backend --type=json --patch '[
 
 Create a service that exposes port 443 on the backend service. 
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: v1
 kind: Service
 metadata:
@@ -121,13 +123,14 @@ spec:
     port: 443
     protocol: TCP
     targetPort: 8443
-EOF
 ```
 
 Create a [BackendTLSPolicy][] instructing Envoy Gateway to establish a TLS connection with the backend and validate the backend certificate is issued by a trusted CA and contains an appropriate DNS SAN.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1alpha2
 kind: BackendTLSPolicy
 metadata:
@@ -145,7 +148,6 @@ spec:
         group: ''
         kind: ConfigMap
     hostname: www.example.com
-EOF
 ```
 
 Patch the HTTPRoute's backend reference, so that it refers to the new TLS-enabled service:
diff --git a/site/content/en/v1.0.1/user/security/basic-auth.md b/site/content/en/v1.0.1/user/security/basic-auth.md
index a45de6fe2c5..44729d814f7 100644
--- a/site/content/en/v1.0.1/user/security/basic-auth.md
+++ b/site/content/en/v1.0.1/user/security/basic-auth.md
@@ -103,8 +103,10 @@ kubectl create secret generic basic-auth --from-file=.htpasswd
 The below example defines a SecurityPolicy that authenticates requests against the user list in the kubernetes
 secret generated in the previous step.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: SecurityPolicy
 metadata:
@@ -117,7 +119,6 @@ spec:
   basicAuth:
     users:
       name: "basic-auth"
-EOF
 ```
 
 Verify the SecurityPolicy configuration:
diff --git a/site/content/en/v1.0.1/user/security/cors.md b/site/content/en/v1.0.1/user/security/cors.md
index dea4f04361d..0869015786e 100644
--- a/site/content/en/v1.0.1/user/security/cors.md
+++ b/site/content/en/v1.0.1/user/security/cors.md
@@ -22,8 +22,10 @@ In addition to that the entire origin (with or without specifying a scheme) can
 
 The below example defines a SecurityPolicy that allows CORS for all HTTP requests originating from `www.foo.com`.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: SecurityPolicy
 metadata:
@@ -46,7 +48,6 @@ spec:
     exposeHeaders:
     - "x-header-3"
     - "x-header-4"
-EOF
 ```
 
 Verify the SecurityPolicy configuration:
diff --git a/site/content/en/v1.0.1/user/security/ext-auth.md b/site/content/en/v1.0.1/user/security/ext-auth.md
index efcd8b62467..901b2ed1973 100644
--- a/site/content/en/v1.0.1/user/security/ext-auth.md
+++ b/site/content/en/v1.0.1/user/security/ext-auth.md
@@ -34,8 +34,10 @@ kubectl apply -f https://raw.githubusercontent.com/envoyproxy/gateway/latest/exa
 
 Create a new HTTPRoute resource to route traffic on the path `/myapp` to the backend service.  
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -53,7 +55,6 @@ spec:
     backendRefs:
     - name: backend
       port: 3000   
-EOF
 ```
 
 Verify the HTTPRoute status:
@@ -69,8 +70,10 @@ Create a new SecurityPolicy resource to configure the external authorization. Th
 authorization. The `headersToBackend` field specifies the headers that will be sent to the backend service if the request
 is successfully authorized.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: SecurityPolicy
 metadata:
@@ -86,7 +89,6 @@ spec:
         name: http-ext-auth
         port: 9002
       headersToBackend: ["x-current-user"]
-EOF
 ```
 
 Verify the SecurityPolicy configuration:
@@ -162,8 +164,10 @@ not created the HTTPRoute, you can create it now.
 
 Create a new HTTPRoute resource to route traffic on the path `/myapp` to the backend service.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -181,7 +185,6 @@ spec:
     backendRefs:
     - name: backend
       port: 3000   
-EOF
 ```
 
 Verify the HTTPRoute status:
@@ -195,8 +198,10 @@ kubectl get httproute/myapp -o yaml
 Update the SecurityPolicy that was created in the previous section to use the gRPC external authorization service.
 It calls the gRPC external authorization service "grpc-ext-auth" on port 9002 for authorization. 
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: SecurityPolicy
 metadata:
@@ -211,7 +216,6 @@ spec:
       backendRef:
         name: grpc-ext-auth
         port: 9002
-EOF
 ```
 
 Verify the SecurityPolicy configuration:
@@ -223,8 +227,10 @@ kubectl get securitypolicy/ext-auth-example -o yaml
 Because the gRPC external authorization service is enabled with TLS, a BackendTLSConfig needs to be created to configure
 the communication between the Envoy proxy and the gRPC auth service.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1alpha2
 kind: BackendTLSPolicy
 metadata:
@@ -241,7 +247,6 @@ spec:
       group: ''
       kind: ConfigMap
     hostname: grpc-ext-auth
-EOF
 ```
 
 Verify the BackendTLSPolicy configuration:
diff --git a/site/content/en/v1.0.1/user/security/mutual-tls.md b/site/content/en/v1.0.1/user/security/mutual-tls.md
index e24562ca45e..3d34f1d126f 100644
--- a/site/content/en/v1.0.1/user/security/mutual-tls.md
+++ b/site/content/en/v1.0.1/user/security/mutual-tls.md
@@ -81,8 +81,10 @@ kubectl get gateway/eg -o yaml
 
 Create a [ClientTrafficPolicy][] to enforce client validation using the CA Certificate as a trusted anchor.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: ClientTrafficPolicy
 metadata:
@@ -100,7 +102,6 @@ spec:
       - kind: "Secret"
         group: ""
         name: "example-ca-cert"
-EOF
 ```
 
 ## Testing
diff --git a/site/content/en/v1.0.1/user/security/oidc.md b/site/content/en/v1.0.1/user/security/oidc.md
index 392650640e7..8f24ca05c4f 100644
--- a/site/content/en/v1.0.1/user/security/oidc.md
+++ b/site/content/en/v1.0.1/user/security/oidc.md
@@ -29,8 +29,10 @@ This guide demonstrates the configuration of OIDC at the HTTPRoute level.
 
 Let's create an HTTPRoute that represents an application protected by OIDC.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -47,7 +49,6 @@ spec:
     backendRefs:
     - name: backend
       port: 3000
-EOF
 ```
 
 Verify the HTTPRoute status:
@@ -93,8 +94,10 @@ by the OAuth2 filter on that HTTPRoute.
 
 Note: please replace the ${CLIENT_ID} in the below yaml snippet with the actual Client ID that you got from the OIDC provider.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: SecurityPolicy
 metadata:
@@ -112,7 +115,6 @@ spec:
       name: "my-app-client-secret"
     redirectURL: "http://www.example.com:8080/myapp/oauth2/callback"
     logoutPath: "/myapp/logout"
-EOF
 ```
 
 Verify the SecurityPolicy configuration:
diff --git a/site/content/en/v1.0.1/user/traffic/circuit-breaker.md b/site/content/en/v1.0.1/user/traffic/circuit-breaker.md
index 2a797fc24c4..a2b1ec03e79 100644
--- a/site/content/en/v1.0.1/user/traffic/circuit-breaker.md
+++ b/site/content/en/v1.0.1/user/traffic/circuit-breaker.md
@@ -62,8 +62,10 @@ The default circuit breaker threshold (1024) is not met. As a result, requests d
 
 In order to fail fast, apply a `BackendTrafficPolicy` that limits concurrent requests to 10 and pending requests to 0.  
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: BackendTrafficPolicy
 metadata:
@@ -77,7 +79,6 @@ spec:
   circuitBreaker:
     maxPendingRequests: 0
     maxParallelRequests: 10
-EOF
 ```
 
 Execute the load simulation again.  
diff --git a/site/content/en/v1.0.1/user/traffic/client-traffic-policy.md b/site/content/en/v1.0.1/user/traffic/client-traffic-policy.md
index 7b37f8d4338..738f964b7f7 100644
--- a/site/content/en/v1.0.1/user/traffic/client-traffic-policy.md
+++ b/site/content/en/v1.0.1/user/traffic/client-traffic-policy.md
@@ -23,8 +23,10 @@ Before proceeding, you should be able to query the example backend using HTTP.
 
 ### Support TCP keepalive for downstream client
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: ClientTrafficPolicy
 metadata:
@@ -40,7 +42,6 @@ spec:
     idleTime: 20m
     interval: 60s
     probes: 3
-EOF
 ```
 
 Verify that ClientTrafficPolicy is Accepted:
@@ -176,8 +177,10 @@ You can see keepalive connection marked by the output in:
 
 This example configures Proxy Protocol for downstream clients.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: ClientTrafficPolicy
 metadata:
@@ -190,7 +193,6 @@ spec:
     name: eg
     namespace: default
   enableProxyProtocol: true
-EOF
 ```
 
 Verify that ClientTrafficPolicy is Accepted:
@@ -289,8 +291,10 @@ You should now expect 200 response status and also see that source IP was preser
 
 This example configures the number of additional ingress proxy hops from the right side of XFF HTTP headers to trust when determining the origin client's IP address and determines whether or not `x-forwarded-proto` headers will be trusted. Refer to https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/headers#x-forwarded-for for details.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: ClientTrafficPolicy
 metadata:
@@ -305,7 +309,6 @@ spec:
   clientIPDetection:
     xForwardedFor:
       numTrustedHops: 2
-EOF
 ```
 
 Verify that ClientTrafficPolicy is Accepted:
@@ -415,8 +418,10 @@ Handling connection for 8888
 This feature allows you to limit the take taken by the Envoy Proxy fleet to receive the entire request from the client, which is useful in preventing certain clients from consuming too much memory in Envoy
 This example configures the HTTP request timeout for the client, please check out the details [here](https://www.envoyproxy.io/docs/envoy/latest/faq/configuration/timeouts#stream-timeouts). 
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: ClientTrafficPolicy
 metadata:
@@ -429,7 +434,6 @@ spec:
   timeout:
     http:
       requestReceivedTimeout: 2s
-EOF
 ```
 
 Curl the example app through Envoy proxy:
diff --git a/site/content/en/v1.0.1/user/traffic/fault-injection.md b/site/content/en/v1.0.1/user/traffic/fault-injection.md
index c033d12aed3..c70fbe477ed 100644
--- a/site/content/en/v1.0.1/user/traffic/fault-injection.md
+++ b/site/content/en/v1.0.1/user/traffic/fault-injection.md
@@ -26,8 +26,10 @@ Allow requests with a valid faultInjection by creating an [BackendTrafficPolicy]
 
 ### HTTPRoute
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resources to your cluster:
+
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: BackendTrafficPolicy
 metadata:
@@ -96,8 +98,6 @@ spec:
     - path:
         type: PathPrefix
         value: /bar
-
-EOF
 ```
 
 Two HTTPRoute has been created, one for `/foo` and another for `/bar`.  `fault-injection-abort` BackendTrafficPolicy has been created and targeted HTTPRoute foo to abort requests for `/foo`. `fault-injection-delay` BackendTrafficPolicy has been created and targeted HTTPRoute foo to delay `2s` requests for `/bar`. 
@@ -118,8 +118,10 @@ kubectl get backendtrafficpolicy/fault-injection-delay -o yaml
 
 ### GRPCRoute
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: BackendTrafficPolicy
 metadata:
@@ -151,7 +153,6 @@ spec:
       name: yages
       port: 9000
       weight: 1
-EOF
 ```
 
 A BackendTrafficPolicy has been created and targeted GRPCRoute yages to abort requests for `yages` service..
diff --git a/site/content/en/v1.0.1/user/traffic/global-rate-limit.md b/site/content/en/v1.0.1/user/traffic/global-rate-limit.md
index aca136fb298..065f969a162 100644
--- a/site/content/en/v1.0.1/user/traffic/global-rate-limit.md
+++ b/site/content/en/v1.0.1/user/traffic/global-rate-limit.md
@@ -35,8 +35,10 @@ Before proceeding, you should be able to query the example backend using HTTP.
 * The global rate limit feature is based on [Envoy Ratelimit][] which requires a Redis instance as its caching layer.
 Lets install a Redis deployment in the `redis-system` namespce.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resources to your cluster:
+
+```yaml
+---
 kind: Namespace
 apiVersion: v1
 metadata:
@@ -87,9 +89,6 @@ spec:
     targetPort: 6379
   selector:
     app: redis
----
-
-EOF
 ```
 
 ### Enable Global Rate limit in Envoy Gateway
@@ -98,9 +97,10 @@ EOF
 using a `ConfigMap`. In the next step, we will update this resource to enable rate limit in Envoy Gateway
 as well as configure the URL for the Redis instance used for Global rate limiting.
 
+Apply the following resource to your cluster:
 
-```shell
-cat <<EOF | kubectl apply -f -
+```yaml
+---
 apiVersion: v1
 kind: ConfigMap
 metadata:
@@ -119,7 +119,6 @@ data:
         type: Redis
         redis:
           url: redis.redis-system.svc.cluster.local:6379
-EOF
 ```
 
 * After updating the `ConfigMap`, you will need to restart the `envoy-gateway` deployment so the configuration kicks in
@@ -134,8 +133,10 @@ kubectl rollout restart deployment envoy-gateway -n envoy-gateway-system
 Here is an example of a rate limit implemented by the application developer to limit a specific user by matching on a custom `x-user-id` header
 with a value set to `one`.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: BackendTrafficPolicy 
 metadata:
@@ -157,13 +158,14 @@ spec:
         limit:
           requests: 3
           unit: Hour
-EOF
 ```
 
 ### HTTPRoute
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -183,7 +185,6 @@ spec:
       kind: Service
       name: backend
       port: 3000
-EOF
 ```
 
 The HTTPRoute status should indicate that it has been accepted and is bound to the example Gateway.
@@ -286,8 +287,10 @@ Here is an example of a rate limit implemented by the application developer to l
 value in the `x-user-id` header. Here, user `one` (recognised from the traffic flow using the header `x-user-id` and value `one`) will be rate limited at 3 requests/hour
 and so will user `two` (recognised from the traffic flow using the header `x-user-id` and value `two`).
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: BackendTrafficPolicy 
 metadata:
@@ -309,13 +312,14 @@ spec:
         limit:
           requests: 3
           unit: Hour
-EOF
 ```
 
 ### HTTPRoute
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -335,7 +339,6 @@ spec:
       kind: Service
       name: backend
       port: 3000
-EOF
 ```
 
 Lets run the same command again with the header `x-user-id` and value `one` set in the request. We should the first 3 requests succeeding and
@@ -421,8 +424,10 @@ transfer-encoding: chunked
 
 This example shows you how to rate limit all requests matching the HTTPRoute rule at 3 requests/Hour by leaving the `clientSelectors` field unset.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: BackendTrafficPolicy 
 metadata:
@@ -440,13 +445,14 @@ spec:
       - limit:
           requests: 3
           unit: Hour
-EOF
 ```
 
 ### HTTPRoute
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -466,7 +472,6 @@ spec:
       kind: Service
       name: backend
       port: 3000
-EOF
 ```
 
 ```shell
@@ -515,8 +520,10 @@ Note: EG supports two kinds of rate limit for the IP address: exact and distinct
 * exact means that all IP addresses within the specified Source IP CIDR share the same rate limit bucket.
 * distinct means that each IP address within the specified Source IP CIDR has its own rate limit bucket.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resources to your cluster:
+
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: BackendTrafficPolicy 
 metadata:
@@ -558,7 +565,6 @@ spec:
       kind: Service
       name: backend
       port: 3000
-EOF
 ```
 
 ```shell
@@ -602,8 +608,10 @@ transfer-encoding: chunked
 
 Here is an example of a rate limit implemented by the application developer to limit distinct users who can be differentiated based on the value of the Jwt claims carried.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resources to your cluster:
+
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: SecurityPolicy
 metadata:
@@ -663,7 +671,6 @@ spec:
     - path:
         type: PathPrefix
         value: /foo
-EOF
 ```
 
 Get the JWT used for testing request authentication:
@@ -767,8 +774,10 @@ like container `image`, `securityContext`, `env` and pod `annotations` and `secu
 
 * `tls.certificateRef` set the client certificate for redis server TLS connections.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: v1
 kind: ConfigMap
 metadata:
@@ -814,7 +823,6 @@ data:
           tls:
             certificateRef:
               name: ratelimit-cert
-EOF
 ```
 
 * After updating the `ConfigMap`, you will need to restart the `envoy-gateway` deployment so the configuration kicks in
diff --git a/site/content/en/v1.0.1/user/traffic/grpc-routing.md b/site/content/en/v1.0.1/user/traffic/grpc-routing.md
index 5334514b7cc..4a6e9fcabed 100644
--- a/site/content/en/v1.0.1/user/traffic/grpc-routing.md
+++ b/site/content/en/v1.0.1/user/traffic/grpc-routing.md
@@ -96,8 +96,10 @@ It supports two match types: `Exact` and `RegularExpression`.
 The following example shows how to match a request based on the service and method names for `grpc.reflection.v1alpha.ServerReflection/ServerReflectionInfo`,
 as well as a match for all services with a method name `Ping` which matches `yages.Echo/Ping` in our deployment.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1alpha2
 kind: GRPCRoute
 metadata:
@@ -122,7 +124,6 @@ spec:
           name: yages
           port: 9000
           weight: 1
-EOF
 ```
 
 Verify the GRPCRoute status:
@@ -143,8 +144,8 @@ The following example shows how to match a request based on the service and meth
 with match type `RegularExpression`. It matches all the services and methods with pattern
 `/.*.Echo/Pin.+`, which matches `yages.Echo/Ping` in our deployment.
 
-```shell
-cat <<EOF | kubectl apply -f -
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1alpha2
 kind: GRPCRoute
 metadata:
@@ -171,7 +172,6 @@ spec:
           name: yages
           port: 9000
           weight: 1
-EOF
 ```
 
 Verify the GRPCRoute status:
diff --git a/site/content/en/v1.0.1/user/traffic/http-request-headers.md b/site/content/en/v1.0.1/user/traffic/http-request-headers.md
index af946da719e..26ef8cae520 100644
--- a/site/content/en/v1.0.1/user/traffic/http-request-headers.md
+++ b/site/content/en/v1.0.1/user/traffic/http-request-headers.md
@@ -24,8 +24,10 @@ does not have the header configured by the filter, then that header will be adde
 has the header configured by the filter, then the value of the header in the filter will be appended to the value of the
 header in the request.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -52,7 +54,6 @@ spec:
         add:
         - name: "add-header"
           value: "foo"
-EOF
 ```
 
 The HTTPRoute status should indicate that it has been accepted and is bound to the example Gateway.
@@ -107,8 +108,10 @@ will be added, but unlike [adding request headers](#adding-request-headers) whic
 the request already contains it, setting a header will cause the value to be replaced by the value configured in the
 filter.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -135,7 +138,6 @@ spec:
         set:
         - name: "set-header"
           value: "foo"
-EOF
 ```
 
 Querying `headers.example/get` should result in a `200` response from the example Gateway and the output from the
@@ -178,8 +180,10 @@ will be added, but unlike [adding request headers](#adding-request-headers) whic
 the request already contains it, setting a header will cause the value to be replaced by the value configured in the
 filter.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -204,7 +208,6 @@ spec:
       requestHeaderModifier:
         remove:
         - "remove-header"
-EOF
 ```
 
 Querying `headers.example/get` should result in a `200` response from the example Gateway and the output from the
@@ -243,8 +246,10 @@ $ curl -vvv --header "Host: headers.example" "http://${GATEWAY_HOST}/get" --head
 
 Headers can be added/set/removed in a single filter on the same HTTPRoute and they will all perform as expected
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -276,7 +281,6 @@ spec:
           value: "bar"
         remove:
         - "removed-header"
-EOF
 ```
 
 [HTTPRoute]: https://gateway-api.sigs.k8s.io/api-types/httproute/
diff --git a/site/content/en/v1.0.1/user/traffic/http-request-mirroring.md b/site/content/en/v1.0.1/user/traffic/http-request-mirroring.md
index 0398cf3780b..9009b250063 100644
--- a/site/content/en/v1.0.1/user/traffic/http-request-mirroring.md
+++ b/site/content/en/v1.0.1/user/traffic/http-request-mirroring.md
@@ -16,8 +16,7 @@ Before proceeding, you should be able to query the example backend using HTTP.
 Next, create a new `Deployment` and `Service` to mirror requests to. The following example will use
 a second instance of the application deployed in the quickstart.
 
-```shell
-kubectl apply -f - <<EOF
+```yaml
 ---
 apiVersion: v1
 kind: ServiceAccount
@@ -71,14 +70,13 @@ spec:
               valueFrom:
                 fieldRef:
                   fieldPath: metadata.namespace
-EOF
 ```
 
 Then create an `HTTPRoute` that uses a `HTTPRequestMirrorFilter` to send requests to the original
 service from the quickstart, and mirror request to the service that was just deployed.
 
-```shell
-kubectl apply -f - <<EOF
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -105,7 +103,6 @@ spec:
       kind: Service
       name: backend
       port: 3000
-EOF
 ```
 
 The HTTPRoute status should indicate that it has been accepted and is bound to the example Gateway.
@@ -164,8 +161,10 @@ Echoing back request made to /get to client (10.42.0.10:45096)
 
 When an `HTTPRoute` has multiple `backendRefs` and an `HTTPRequestMirrorFilter`, traffic splitting will still behave the same as it normally would for the main `backendRefs` while the `backendRef` of the `HTTPRequestMirrorFilter` will continue receiving mirrored copies of the incoming requests.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -196,15 +195,16 @@ spec:
       kind: Service
       name: backend-3
       port: 3000
-EOF
 ```
 
 ## Multiple HTTPRequestMirrorFilters
 
 Multiple `HTTPRequestMirrorFilters` are not supported on the same `HTTPRoute` `rule`. When attempting to do so, the admission webhook will reject the configuration.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -237,7 +237,6 @@ spec:
       kind: Service
       name: backend
       port: 3000
-EOF
 ```
 
 ```console
diff --git a/site/content/en/v1.0.1/user/traffic/http-response-headers.md b/site/content/en/v1.0.1/user/traffic/http-response-headers.md
index 13efc8af19a..b837610523e 100644
--- a/site/content/en/v1.0.1/user/traffic/http-response-headers.md
+++ b/site/content/en/v1.0.1/user/traffic/http-response-headers.md
@@ -22,8 +22,10 @@ does not have the header configured by the filter, then that header will be adde
 already has the header configured by the filter, then the value of the header in the filter will be appended to the
 value of the header in the response.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -50,7 +52,6 @@ spec:
         add:
         - name: "add-header"
           value: "foo"
-EOF
 ```
 
 The HTTPRoute status should indicate that it has been accepted and is bound to the example Gateway.
@@ -105,8 +106,10 @@ will be added, but unlike [adding response headers](#adding-response-headers) wh
 if the response already contains it, setting a header will cause the value to be replaced by the value configured in the
 filter.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -133,7 +136,6 @@ spec:
         set:
         - name: "set-header"
           value: "foo"
-EOF
 ```
 
 Querying `headers.example/get` should result in a `200` response from the example Gateway and the output from the
@@ -177,8 +179,10 @@ will be added, but unlike [adding response headers](#adding-response-headers) wh
 if the response already contains it, setting a header will cause the value to be replaced by the value configured in the
 filter.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -203,7 +207,6 @@ spec:
       responseHeaderModifier:
         remove:
         - "remove-header"
-EOF
 ```
 
 Querying `headers.example/get` should result in a `200` response from the example Gateway and the output from the
@@ -242,8 +245,10 @@ $ curl -vvv --header "Host: headers.example" "http://${GATEWAY_HOST}/get" -H 'X-
 
 Headers can be added/set/removed in a single filter on the same HTTPRoute and they will all perform as expected
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -275,7 +280,6 @@ spec:
           value: "bar"
         remove:
         - "removed-header"
-EOF
 ```
 
 [HTTPRoute]: https://gateway-api.sigs.k8s.io/api-types/httproute/
diff --git a/site/content/en/v1.0.1/user/traffic/http-routing.md b/site/content/en/v1.0.1/user/traffic/http-routing.md
index 12e1773a91f..9cfb3a27d9e 100644
--- a/site/content/en/v1.0.1/user/traffic/http-routing.md
+++ b/site/content/en/v1.0.1/user/traffic/http-routing.md
@@ -131,8 +131,10 @@ For this feature to work please make sure
 * you have a fallback route rule defined, the backend for this route rule can be invalid.
 * The SecurityPolicy is applied to both the fallback route as well as the route with the claim header matches, to avoid spoofing.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resources to your cluster:
+
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: SecurityPolicy
 metadata:
@@ -192,7 +194,6 @@ spec:
         - path:
             type: PathPrefix
             value: /
-EOF
 ```
 
 Get the JWT used for testing request authentication:
diff --git a/site/content/en/v1.0.1/user/traffic/http-timeouts.md b/site/content/en/v1.0.1/user/traffic/http-timeouts.md
index c3abc192611..7d7b02efa8c 100644
--- a/site/content/en/v1.0.1/user/traffic/http-timeouts.md
+++ b/site/content/en/v1.0.1/user/traffic/http-timeouts.md
@@ -22,8 +22,10 @@ backend has the ability to delay responses; we use it as the backend to control
 ### request timeout
 We configure the backend to delay responses by 3 seconds, then we set the request timeout to 4 seconds. Envoy Gateway will successfully respond to the request.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -48,7 +50,6 @@ spec:
         value: /
     timeouts:
       request: "4s"
-EOF
 ```
 
 ```shell
@@ -65,8 +66,10 @@ content-length: 480
 
 Then we set the request timeout to 2 seconds. In this case, Envoy Gateway will respond with a timeout.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -91,7 +94,6 @@ spec:
         value: /
     timeouts:
       request: "2s"
-EOF
 ```
 
 ```shell
diff --git a/site/content/en/v1.0.1/user/traffic/http-traffic-splitting.md b/site/content/en/v1.0.1/user/traffic/http-traffic-splitting.md
index ef240753ad8..c172252361a 100644
--- a/site/content/en/v1.0.1/user/traffic/http-traffic-splitting.md
+++ b/site/content/en/v1.0.1/user/traffic/http-traffic-splitting.md
@@ -15,8 +15,10 @@ Before proceeding, you should be able to query the example backend using HTTP.
 
 When a single backendRef is configured in a HTTPRoute, it will receive 100% of the traffic.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -36,7 +38,6 @@ spec:
       kind: Service
       name: backend
       port: 3000
-EOF
 ```
 
 The HTTPRoute status should indicate that it has been accepted and is bound to the example Gateway.
@@ -87,8 +88,9 @@ configured.
 
 First, create a second instance of the example app from the quickstart:
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resources to your cluster:
+
+```yaml
 ---
 apiVersion: v1
 kind: ServiceAccount
@@ -142,13 +144,14 @@ spec:
               valueFrom:
                 fieldRef:
                   fieldPath: metadata.namespace
-EOF
 ```
 
 Then create an HTTPRoute that uses both the app from the quickstart and the second instance that was just created
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -172,7 +175,6 @@ spec:
       kind: Service
       name: backend-2
       port: 3000
-EOF
 ```
 
 Querying `backends.example/get` should result in `200` responses from the example Gateway and the output from the
@@ -217,8 +219,10 @@ HTTPRoute. The weight is not a percentage and the sum of all weights does not ne
 The HTTPRoute below will configure the gateway to send 80% of the traffic to the backend service, and 20% to the
 backend-2 service.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -244,7 +248,6 @@ spec:
       name: backend-2
       port: 3000
       weight: 2
-EOF
 ```
 
 ## Invalid backendRefs
@@ -263,8 +266,10 @@ Modifying the above example to make the backend-2 backendRef invalid by using a
 will result in 80% of the traffic being sent to the backend service, and 20% of the traffic receiving an HTTP response
 with status code `500`.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -290,7 +295,6 @@ spec:
       name: backend-2
       port: 9000
       weight: 2
-EOF
 ```
 
 Querying `backends.example/get` should result in `200` responses 80% of the time, and `500` responses 20% of the time.
diff --git a/site/content/en/v1.0.1/user/traffic/http-urlrewrite.md b/site/content/en/v1.0.1/user/traffic/http-urlrewrite.md
index 062f6086392..4fa9fbde04d 100644
--- a/site/content/en/v1.0.1/user/traffic/http-urlrewrite.md
+++ b/site/content/en/v1.0.1/user/traffic/http-urlrewrite.md
@@ -15,8 +15,10 @@ Before proceeding, you should be able to query the example backend using HTTP.
 You can configure to rewrite the prefix in the url like below. In this example, any curls to
 `http://${GATEWAY_HOST}/get/xxx` will be rewritten to `http://${GATEWAY_HOST}/replace/xxx`.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -39,7 +41,6 @@ spec:
       backendRefs:
       - name: backend
         port: 3000
-EOF
 ```
 
 The HTTPRoute status should indicate that it has been accepted and is bound to the example Gateway.
@@ -114,8 +115,10 @@ You can configure to rewrite the fullpath in the url like below. In this example
 `http://${GATEWAY_HOST}/get/origin/path/xxxx` will be rewritten to
 `http://${GATEWAY_HOST}/force/replace/fullpath`.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -139,7 +142,6 @@ spec:
       backendRefs:
       - name: backend
         port: 3000
-EOF
 ```
 
 The HTTPRoute status should indicate that it has been accepted and is bound to the example Gateway.
@@ -208,8 +210,10 @@ You can see that the `X-Envoy-Original-Path` is `/get/origin/path/extra`, but th
 You can configure to rewrite the hostname like below. In this example, any requests sent to
 `http://${GATEWAY_HOST}/get` with `--header "Host: path.rewrite.example"` will rewrite host into `envoygateway.io`.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -231,7 +235,6 @@ spec:
       backendRefs:
       - name: backend
         port: 3000
-EOF
 ```
 
 The HTTPRoute status should indicate that it has been accepted and is bound to the example Gateway.
diff --git a/site/content/en/v1.0.1/user/traffic/local-rate-limit.md b/site/content/en/v1.0.1/user/traffic/local-rate-limit.md
index 822e2dd5e56..d6382b7ca9b 100644
--- a/site/content/en/v1.0.1/user/traffic/local-rate-limit.md
+++ b/site/content/en/v1.0.1/user/traffic/local-rate-limit.md
@@ -36,8 +36,10 @@ Before proceeding, you should be able to query the example backend using HTTP.
 Here is an example of a rate limit implemented by the application developer to limit a specific user by matching on a custom `x-user-id` header
 with a value set to `one`.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: BackendTrafficPolicy 
 metadata:
@@ -59,13 +61,14 @@ spec:
         limit:
           requests: 3
           unit: Hour
-EOF
 ```
 
 ### HTTPRoute
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -85,7 +88,6 @@ spec:
       kind: Service
       name: backend
       port: 3000
-EOF
 ```
 
 The HTTPRoute status should indicate that it has been accepted and is bound to the example Gateway.
@@ -186,8 +188,10 @@ server: envoy
 
 This example shows you how to rate limit all requests matching the HTTPRoute rule at 3 requests/Hour by leaving the `clientSelectors` field unset.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: BackendTrafficPolicy 
 metadata:
@@ -205,13 +209,14 @@ spec:
       - limit:
           requests: 3
           unit: Hour
-EOF
 ```
 
 ### HTTPRoute
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
@@ -231,7 +236,6 @@ spec:
       kind: Service
       name: backend
       port: 3000
-EOF
 ```
 
 ```shell
diff --git a/site/content/en/v1.0.1/user/traffic/retry.md b/site/content/en/v1.0.1/user/traffic/retry.md
index ad40202a107..b4b0c4e1bb1 100644
--- a/site/content/en/v1.0.1/user/traffic/retry.md
+++ b/site/content/en/v1.0.1/user/traffic/retry.md
@@ -46,8 +46,10 @@ Let's create a `BackendTrafficPolicy` with a retry setting.
 
 The request will be retried 5 times with a 100ms base interval and a 10s maximum interval.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resource to your cluster:
+
+```yaml
+---
 apiVersion: gateway.envoyproxy.io/v1alpha1
 kind: BackendTrafficPolicy
 metadata:
@@ -71,7 +73,6 @@ spec:
       triggers:
         - connect-failure
         - retriable-status-codes
-EOF
 ```
 
 Execute the test again.
diff --git a/site/content/en/v1.0.1/user/traffic/routing-outside-kubernetes.md b/site/content/en/v1.0.1/user/traffic/routing-outside-kubernetes.md
index 6be1853570f..64c5d042724 100644
--- a/site/content/en/v1.0.1/user/traffic/routing-outside-kubernetes.md
+++ b/site/content/en/v1.0.1/user/traffic/routing-outside-kubernetes.md
@@ -12,84 +12,85 @@ Before proceeding, you should be able to query the example backend using HTTP.
 
 ## Configuration
 
-* Lets define a Service and EndpointSlice that represents https://httpbin.org
-
-```shell
-cat <<EOF | kubectl apply -f -
-apiVersion: v1
-kind: Service
-metadata:
-  name: httpbin
-  namespace: default
-spec:
-  ports:
-    - port: 443
+* Define a Service and EndpointSlice that represents https://httpbin.org
+
+    Apply the following resources to your cluster:
+
+    ```yaml
+    ---
+    apiVersion: v1
+    kind: Service
+    metadata:
+      name: httpbin
+      namespace: default
+    spec:
+      ports:
+        - port: 443
+          protocol: TCP
+          targetPort: 443
+          name: https
+    ---
+    apiVersion: discovery.k8s.io/v1
+    kind: EndpointSlice
+    metadata:
+      name: httpbin
+      namespace: default
+      labels:
+        kubernetes.io/service-name: httpbin 
+    addressType: FQDN
+    ports:
+    - name: https
       protocol: TCP
-      targetPort: 443
-      name: https
----
-apiVersion: discovery.k8s.io/v1
-kind: EndpointSlice
-metadata:
-  name: httpbin
-  namespace: default
-  labels:
-    kubernetes.io/service-name: httpbin 
-addressType: FQDN
-ports:
-- name: https
-  protocol: TCP
-  port: 443
-endpoints:
-- addresses:
-  - "httpbin.org"
-EOF
-```
-
-* Lets update the [Gateway][] to include a TLS Listener on port 443
-
-```shell
-kubectl patch gateway eg --type=json --patch '[{
-   "op": "add",
-   "path": "/spec/listeners/-",
-   "value": {
-      "name": "tls",
-      "protocol": "TLS",
-      "port": 443,
-      "tls": {
-        "mode": "Passthrough",
-      },
-    },
-}]'
-```
-
-* Lets add a [TLSRoute][] that can route incoming traffic to the above backend that we created
-
-```shell
-cat <<EOF | kubectl apply -f -
-apiVersion: gateway.networking.k8s.io/v1alpha2
-kind: TLSRoute
-metadata:
-  name: httpbin 
-spec:
-  parentRefs:
-  - name: eg 
-    sectionName: tls
-  rules:
-  - backendRefs:
-    - name: httpbin
       port: 443
-EOF
-```    
-
-Lets get the Gateway address
+    endpoints:
+    - addresses:
+      - "httpbin.org"
+    ```
+
+* Update the [Gateway][] to include a TLS Listener on port 443
+
+    ```shell
+    kubectl patch gateway eg --type=json --patch '[{
+      "op": "add",
+      "path": "/spec/listeners/-",
+      "value": {
+          "name": "tls",
+          "protocol": "TLS",
+          "port": 443,
+          "tls": {
+            "mode": "Passthrough",
+          },
+        },
+    }]'
+    ```
+
+* Add a [TLSRoute][] that can route incoming traffic to the above backend that we created
+
+    Apply the following resource to your cluster:
+
+    ```yaml
+    ---
+    apiVersion: gateway.networking.k8s.io/v1alpha2
+    kind: TLSRoute
+    metadata:
+      name: httpbin 
+    spec:
+      parentRefs:
+      - name: eg 
+        sectionName: tls
+      rules:
+      - backendRefs:
+        - name: httpbin
+          port: 443
+    ```    
+
+Obtain the Gateway address:
 
 ```shell
 export GATEWAY_HOST=$(kubectl get gateway/eg -o jsonpath='{.status.addresses[0].value}')
 ```
 
-
-Lets send a request and view the response
+Send a request and view the response:
 
 ```shell
 curl -I -HHost:httpbin.org --resolve "httpbin.org:443:${GATEWAY_HOST}" https://httpbin.org:443
diff --git a/site/content/en/v1.0.1/user/traffic/tcp-routing.md b/site/content/en/v1.0.1/user/traffic/tcp-routing.md
index 854522c7b98..9d454088bdd 100644
--- a/site/content/en/v1.0.1/user/traffic/tcp-routing.md
+++ b/site/content/en/v1.0.1/user/traffic/tcp-routing.md
@@ -23,8 +23,10 @@ TCPRoutes, note that the protocol set for the listeners on the Gateway is TCP:
 
 Install the GatewayClass and a `tcp-gateway` Gateway first.
 
-```shell
-cat <<EOF | kubectl apply -f -
+Apply the following resources to your cluster:
+
+```yaml
+---
 kind: GatewayClass
 apiVersion: gateway.networking.k8s.io/v1
 metadata:
@@ -51,13 +53,12 @@ spec:
     allowedRoutes:
       kinds:
       - kind: TCPRoute
-EOF
 ```
 
 Install two services `foo` and `bar`, which are binded to `backend-1` and `backend-2`.
 
-```shell
-cat <<EOF | kubectl apply -f -
+```yaml
+---
 apiVersion: v1
 kind: Service
 metadata:
@@ -153,13 +154,12 @@ spec:
                   fieldPath: metadata.namespace
             - name: SERVICE_NAME
               value: bar
-EOF
 ```
 
 Install two TCPRoutes `tcp-app-1` and `tcp-app-2` with different `sectionName`:
 
-```shell
-cat <<EOF | kubectl apply -f -
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1alpha2
 kind: TCPRoute
 metadata:
@@ -185,13 +185,12 @@ spec:
   - backendRefs:
     - name: bar
       port: 3002
-EOF
 ```
 
 In the above example we separate the traffic for the two separate backend TCP Services by using the sectionName field in
 the parentRefs:
 
-``` yaml
+```yaml
 spec:
   parentRefs:
   - name: tcp-gateway
@@ -200,7 +199,7 @@ spec:
 
 This corresponds directly with the name in the listeners in the Gateway:
 
-``` yaml
+```yaml
   listeners:
   - name: foo
     protocol: TCP
diff --git a/site/content/en/v1.0.1/user/traffic/udp-routing.md b/site/content/en/v1.0.1/user/traffic/udp-routing.md
index 521d0b41acc..063746ccc31 100644
--- a/site/content/en/v1.0.1/user/traffic/udp-routing.md
+++ b/site/content/en/v1.0.1/user/traffic/udp-routing.md
@@ -59,8 +59,8 @@ kubectl get gateway/eg -o yaml
 
 Create a UDPRoute resource to route UDP traffic received on Gateway port 5300 to the CoredDNS backend.
 
-```shell
-cat <<EOF | kubectl apply -f -
+```yaml
+---
 apiVersion: gateway.networking.k8s.io/v1alpha2
 kind: UDPRoute
 metadata:
@@ -73,7 +73,6 @@ spec:
     - backendRefs:
         - name: coredns
           port: 53
-EOF
 ```
 
 Verify the UDPRoute status: