Removed $ symbol from code blocks in the Docs

content/docs/demos/canary_rollout.md

@@ -27,53 +27,63 @@ The following steps demonstrate the canary rollout deployment strategy.
 
 1. Enable permissive mode
 
-    ```bash
+    ```console
     osm_namespace=osm-system # Replace osm-system with the namespace where OSM is installed
     kubectl patch meshconfig osm-mesh-config -n "$osm_namespace" -p '{"spec":{"traffic":{"enablePermissiveTrafficPolicyMode":true}}}'  --type=merge
     ```
 
 1. Deploy the `curl` client into the `curl` namespace after enrolling its namespace to the mesh.
 
-    ```bash
-    # Create the curl namespace
+  - Create the curl namespace
+    ```console
     kubectl create namespace curl
+    ```
 
-    # Add the namespace to the mesh
+  - Add the namespace to the mesh
+    ```console
     osm namespace add curl
+    ```
 
     # Deploy curl client in the curl namespace
+    ```console
     kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm-docs/{{< param osm_branch >}}/manifests/samples/curl/curl.yaml -n curl
     ```
 
-    Confirm the `curl` client pod is up and running.
+Confirm the `curl` client pod is up and running.
+
+  ```console
+  kubectl get pods -n curl
+  ```
+  - The output will be similar to:
     ```console
-    $ kubectl get pods -n curl
     NAME                    READY   STATUS    RESTARTS   AGE
     curl-54ccc6954c-9rlvp   2/2     Running   0          20s
     ```
 
 1. Create the root `httpbin` service that clients will direct traffic to. The service has the selector `app: httpbin`.
 
-    ```bash
-    # Create the httpbin namespace
+- Create the httpbin namespace   
+    ```console
     kubectl create namespace httpbin
+    ```
 
     # Add the namespace to the mesh
     osm namespace add httpbin
 
     # Create the httpbin root service and service account
+    ```console
     kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm-docs/{{< param osm_branch >}}/manifests/samples/canary/httpbin.yaml -n httpbin
     ```
 
 1. Deploy version `v1` of the `httpbin` service. The service `httpbin-v1` has the selector `app: httpbin, version: v1`, and the deployment `httpbin-v1` has the labels `app: httpbin, version: v1` matching the selector of both the `httpbin` root service and `httpbin-v1` service.
 
-    ```bash
+    ```console
     kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm-docs/{{< param osm_branch >}}/manifests/samples/canary/httpbin-v1.yaml -n httpbin
     ```
 
 1. Create an SMI TrafficSplit resource that directs all traffic to the `httpbin-v1` service.
 
-    ```bash
+    ```console
     kubectl apply -f - <<EOF
     apiVersion: split.smi-spec.io/v1alpha2
     kind: TrafficSplit
@@ -118,13 +128,13 @@ The following steps demonstrate the canary rollout deployment strategy.
 
 1. Prepare the canary rollout by deploying version `v2` of the `httpbin` service. The service `httpbin-v2` has the selector `app: httpbin, version: v2`, and the deployment `httpbin-v2` has the labels `app: httpbin, version: v2` matching the selector of both the `httpbin` root service and `httpbin-v2` service.
 
-    ```bash
+    ```console
     kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm-docs/{{< param osm_branch >}}/manifests/samples/canary/httpbin-v2.yaml -n httpbin
     ```
 
 1. Perform the canary rollout by updating the SMI TrafficSplit resource to split traffic directed to the root service FQDN `httpbin.httpbin.svc.cluster.local` to both the `httpbin-v1` and `httpbin-v2` services, fronting the `v1` and `v2` versions of the `httpbin` service respectively. We will distribute the weight equally to demonstrate traffic splitting.
 
-    ```bash
+    ```console
     kubectl apply -f - <<EOF
     apiVersion: split.smi-spec.io/v1alpha2
     kind: TrafficSplit
@@ -144,7 +154,7 @@ The following steps demonstrate the canary rollout deployment strategy.
 1. Confirm traffic is split proportional to the weights assigned to the backend services. Since we configured a weight of `50` for both `v1` and `v2`, requests should be load balanced to both the versions as seen below.
 
     ```console
-    $ for i in {1..10}; do kubectl exec -n curl -ti "$(kubectl get pod -n curl -l app=curl -o jsonpath='{.items[0].metadata.name}')" -c curl -- curl -sI http://httpbin.httpbin:14001/json | egrep 'HTTP|pod'; done
+    for i in {1..10}; do kubectl exec -n curl -ti "$(kubectl get pod -n curl -l app=curl -o jsonpath='{.items[0].metadata.name}')" -c curl -- curl -sI http://httpbin.httpbin:14001/json | egrep 'HTTP|pod'; done
     HTTP/1.1 200 OK
     pod: httpbin-v2-6b48697db-cdqld
     HTTP/1.1 200 OK

content/docs/demos/cert-manager_integration.md

@@ -26,6 +26,9 @@ The following demo uses [cert-manager][1] as the certificate provider to issue c
     Confirm the pods are ready and running in the `cert-manager` namespace.
     ```console
     kubectl get pod -n cert-manager
+     ```
+    The output will be similar to:
+    ```console    
     NAME                                      READY   STATUS    RESTARTS   AGE
     cert-manager-55658cdf68-pdnzg             1/1     Running   0          2m33s
     cert-manager-cainjector-967788869-prtjq   1/1     Running   0          2m33s
@@ -42,8 +45,8 @@ The following demo uses [cert-manager][1] as the certificate provider to issue c
     ```
 
     Next, we use a `SelfSigned` issuer to bootstrap a custom root certificate. This will create a `SelfSigned` issuer, issue a root certificate, and use that root as a `CA` issuer for certificates issued to workloads within the mesh.
+- Create Issuer and Certificate resources
     ```bash
-    # Create Issuer and Certificate resources
     kubectl apply -f - <<EOF
     apiVersion: cert-manager.io/v1
     kind: Issuer
@@ -81,7 +84,10 @@ The following demo uses [cert-manager][1] as the certificate provider to issue c
 
 1. Confirm the `osm-ca-bundle` CA secret is created by `cert-manager` in OSM's namespace.
     ```console
-    $ kubectl get secret osm-ca-bundle -n "$osm_namespace"
+    kubectl get secret osm-ca-bundle -n "$osm_namespace"
+    ```
+    The output will be similar to:
+    ```console
     NAME            TYPE                DATA   AGE
     osm-ca-bundle   kubernetes.io/tls   3      84s
     ```
@@ -95,7 +101,10 @@ The following demo uses [cert-manager][1] as the certificate provider to issue c
 
     Confirm the OSM control plane pods are ready and running.
     ```console
-    $ kubectl get pod -n "$osm_namespace"
+    kubectl get pod -n "$osm_namespace"
+    ```
+    The output will be similar to:
+    ```console
     NAME                              READY   STATUS    RESTARTS   AGE
     osm-bootstrap-7ddc6f9b85-k8ptp    1/1     Running   0          2m52s
     osm-controller-79b777889b-mqk4g   1/1     Running   0          2m52s
@@ -111,56 +120,74 @@ The following demo uses [cert-manager][1] as the certificate provider to issue c
 
 1. Deploy the `httpbin` service into the `httpbin` namespace after enrolling its namespace to the mesh. The `httpbin` service runs on port `14001`.
 
+    Create the httpbin namespace
     ```bash
-    # Create the httpbin namespace
     kubectl create namespace httpbin
+    ```
 
-    # Add the namespace to the mesh
+    Add the namespace to the mesh
+    ```bash
     osm namespace add httpbin
-
-    # Deploy httpbin service in the httpbin namespace
+    ```
+
+    Deploy httpbin service in the httpbin namespace
+    ```bash
     kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm-docs/{{< param osm_branch >}}/manifests/samples/httpbin/httpbin.yaml -n httpbin
     ```
 
     Confirm the `httpbin` service and pods are up and running.
 
     ```console
-    $ kubectl get svc -n httpbin
+    kubectl get svc -n httpbin
+    ```
+    The output will be similar to:
+    ```console
     NAME      TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)     AGE
     httpbin   ClusterIP   10.96.198.23   <none>        14001/TCP   20s
     ```
 
     ```console
-    $ kubectl get pods -n httpbin
+    kubectl get pods -n httpbin
+    ```
+    The output will be similar to:
+    ```console
     NAME                     READY   STATUS    RESTARTS   AGE
     httpbin-5b8b94b9-lt2vs   2/2     Running   0          20s
     ```
 
 1. Deploy the `curl` client into the `curl` namespace after enrolling its namespace to the mesh.
 
+    Create the curl namespace
     ```bash
-    # Create the curl namespace
     kubectl create namespace curl
-
-    # Add the namespace to the mesh
+    ```
+    Add the namespace to the mesh
+    ```bash
     osm namespace add curl
-
-    # Deploy curl client in the curl namespace
+    ```
+    Deploy curl client in the curl namespace
+    ```bash
     kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm-docs/{{< param osm_branch >}}/manifests/samples/curl/curl.yaml -n curl
     ```
 
     Confirm the `curl` client pod is up and running.
 
     ```console
-    $ kubectl get pods -n curl
+    kubectl get pods -n curl
+    ```
+    The output will be similar to:
+    ```console
     NAME                    READY   STATUS    RESTARTS   AGE
     curl-54ccc6954c-9rlvp   2/2     Running   0          20s
     ```
 
 1. Confirm the `curl` client is able to access the `httpbin` service on port `14001`.
 
     ```console
-    $ kubectl exec -n curl -ti "$(kubectl get pod -n curl -l app=curl -o jsonpath='{.items[0].metadata.name}')" -c curl -- curl -I http://httpbin.httpbin:14001
+    kubectl exec -n curl -ti "$(kubectl get pod -n curl -l app=curl -o jsonpath='{.items[0].metadata.name}')" -c curl -- curl -I http://httpbin.httpbin:14001
+    ```
+    The output willbe similar to:
+    ```console
     HTTP/1.1 200 OK
     server: envoy
     date: Mon, 15 Mar 2021 22:45:23 GMT

content/docs/demos/circuit_breaking_mesh_external.md

@@ -22,44 +22,58 @@ The following demo shows a load-testing client [fortio](https://github.com/forti
 
 1. Deploy the `httpbin` service into the `httpbin` namespace. The `httpbin` service runs on port `14001` and is not added to the mesh, so it is considered to be a destination external to the mesh.
 
+    Create the httpbin namespace
     ```bash
-    # Create the httpbin namespace
     kubectl create namespace httpbin
-
-    # Deploy httpbin service in the httpbin namespace
+    ```
+    Deploy httpbin service in the httpbin namespace
+    ```bash
     kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm-docs/{{< param osm_branch >}}/manifests/samples/httpbin/httpbin.yaml -n httpbin
     ```
 
     Confirm the `httpbin` service and pods are up and running.
 
     ```console
-    $ kubectl get svc -n httpbin
+    kubectl get svc -n httpbin
+    ```
+    The output will be si,ilar to:
+    ```console
     NAME      TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)     AGE
     httpbin   ClusterIP   10.96.198.23   <none>        14001/TCP   20s
     ```
 
     ```console
-    $ kubectl get pods -n httpbin
+    kubectl get pods -n httpbin
+    ```
+    The output will be similar to:
+    ```console
     NAME                     READY   STATUS    RESTARTS   AGE
     httpbin-5b8b94b9-lt2vs   1/1     Running   0          20s
     ```
 
 1. Deploy the `fortio` load-testing client in the `client` namespace after enrolling its namespace to the mesh.
+    Create the client namespace
     ```bash
-    # Create the client namespace
     kubectl create namespace client
+    ```
 
-    # Add the namespace to the mesh
+    Add the namespace to the mesh
+    ```bash
     osm namespace add client
+    ```
 
     # Deploy fortio client in the client namespace
+    ```bash
     kubectl apply -f https://raw.githubusercontent.com/openservicemesh/osm-docs/{{< param osm_branch >}}/manifests/samples/fortio/fortio.yaml -n client
     ```
 
     Confirm the `fortio` client pod is up and running.
 
     ```console
-    $ kubectl get pods -n client
+    kubectl get pods -n client
+    ```
+    The output will be si,ilar to:
+    ```console
     NAME                      READY   STATUS    RESTARTS   AGE
     fortio-6477f8495f-bj4s9   2/2     Running   0          19s
     ```
@@ -87,9 +101,11 @@ The following demo shows a load-testing client [fortio](https://github.com/forti
 
 1. Confirm the `fortio` client is able to successfully make HTTP requests to the external host `httpbin.httpbin.svc.cluster.local` service on port `14001`. We call the external service with `5` concurrent connections (`-c 5`) and send `50` requests (`-n 50`).
     ```console
-    $ export fortio_pod="$(kubectl get pod -n client -l app=fortio -o jsonpath='{.items[0].metadata.name}')"
-
-    $ kubectl exec "$fortio_pod" -c fortio -n client -- /usr/bin/fortio load -c 5 -qps 0 -n 50 -loglevel Warning http://httpbin.httpbin.svc.cluster.local:14001/get
+    export fortio_pod="$(kubectl get pod -n client -l app=fortio -o jsonpath='{.items[0].metadata.name}')"
+    ```
+    Theoutpul will be similar to:
+    ```console
+    kubectl exec "$fortio_pod" -c fortio -n client -- /usr/bin/fortio load -c 5 -qps 0 -n 50 -loglevel Warning http://httpbin.httpbin.svc.cluster.local:14001/get
     19:56:34 I logger.go:127> Log level is now 3 Warning (was 2 Info)
     Fortio 1.17.1 running at 0 queries per second, 8->8 procs, for 50 calls: http://httpbin.httpbin.svc.cluster.local:14001/get
     Starting at max qps with 5 thread(s) [gomax 8] for exactly 50 calls (10 per thread + 0)
@@ -160,7 +176,10 @@ The following demo shows a load-testing client [fortio](https://github.com/forti
 
 1. Confirm the `fortio` client is unable to make the same amount of successful requests as before due to the connection and request level circuit breaking limits configured above.
     ```console
-    $ kubectl exec "$fortio_pod" -c fortio -n client -- /usr/bin/fortio load -c 5 -qps 0 -n 50 -loglevel Warning http://httpbin.httpbin.svc.cluster.local:14001/get
+    kubectl exec "$fortio_pod" -c fortio -n client -- /usr/bin/fortio load -c 5 -qps 0 -n 50 -loglevel Warning http://httpbin.httpbin.svc.cluster.local:14001/get
+    ```
+    The output will be similar to:
+    ```console
     19:58:48 I logger.go:127> Log level is now 3 Warning (was 2 Info)
     Fortio 1.17.1 running at 0 queries per second, 8->8 procs, for 50 calls: http://httpbin.httpbin.svc.cluster.local:14001/get
     Starting at max qps with 5 thread(s) [gomax 8] for exactly 50 calls (10 per thread + 0)
@@ -217,7 +236,10 @@ The following demo shows a load-testing client [fortio](https://github.com/forti
 
 1. Examine the `Envoy` sidecar stats to see statistics pertaining to the requests that tripped the circuit breaker.
     ```console
-    $ osm proxy get stats $fortio_pod -n client | grep 'httpbin.*pending'
+    osm proxy get stats $fortio_pod -n client | grep 'httpbin.*pending'
+    ```
+    The output will be similar to:
+    ```console
     cluster.httpbin_httpbin_svc_cluster_local_14001.circuit_breakers.default.remaining_pending: 1
     cluster.httpbin_httpbin_svc_cluster_local_14001.circuit_breakers.default.rq_pending_open: 0
     cluster.httpbin_httpbin_svc_cluster_local_14001.circuit_breakers.high.rq_pending_open: 0