Code snippents shouldn't include the command prompt (#12779)

content/en/docs/tasks/administer-cluster/configure-multiple-schedulers.md

@@ -96,7 +96,9 @@ kubectl create -f my-scheduler.yaml
 Verify that the scheduler pod is running:
 
 ```shell
-$ kubectl get pods --namespace=kube-system
+kubectl get pods --namespace=kube-system
+```
+```
 NAME                                           READY     STATUS    RESTARTS   AGE
 ....
 my-scheduler-lnf4s-4744f                       1/1       Running   0          2m
@@ -116,7 +118,9 @@ First, update the following fields in your YAML file:
 
 If RBAC is enabled on your cluster, you must update the `system:kube-scheduler` cluster role. Add your scheduler name to the resourceNames of the rule applied for endpoints resources, as in the following example:
 ```
-$ kubectl edit clusterrole system:kube-scheduler
+kubectl edit clusterrole system:kube-scheduler
+```
+```yaml
 - apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:

content/en/docs/tasks/administer-cluster/highly-available-master.md

@@ -42,7 +42,7 @@ Set the following flag:
 The following sample command sets up a HA-compatible cluster in the GCE zone europe-west1-b:
 
 ```shell
-$ MULTIZONE=true KUBE_GCE_ZONE=europe-west1-b  ENABLE_ETCD_QUORUM_READS=true ./cluster/kube-up.sh
+MULTIZONE=true KUBE_GCE_ZONE=europe-west1-b  ENABLE_ETCD_QUORUM_READS=true ./cluster/kube-up.sh
 ```
 
 Note that the commands above create a cluster with one master;
@@ -65,7 +65,7 @@ as those are inherited from when you started your HA-compatible cluster.
 The following sample command replicates the master on an existing HA-compatible cluster:
 
 ```shell
-$ KUBE_GCE_ZONE=europe-west1-c KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
+KUBE_GCE_ZONE=europe-west1-c KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
 ```
 
 ## Removing a master replica
@@ -82,7 +82,7 @@ If empty: any replica from the given zone will be removed.
 The following sample command removes a master replica from an existing HA cluster:
 
 ```shell
-$ KUBE_DELETE_NODES=false KUBE_GCE_ZONE=europe-west1-c ./cluster/kube-down.sh
+KUBE_DELETE_NODES=false KUBE_GCE_ZONE=europe-west1-c ./cluster/kube-down.sh
 ```
 
 ## Handling master replica failures
@@ -94,13 +94,13 @@ The following sample commands demonstrate this process:
 1. Remove the broken replica:
 
 ```shell
-$ KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_name ./cluster/kube-down.sh
+KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_name ./cluster/kube-down.sh
 ```
 
 <ol start="2"><li>Add a new replica in place of the old one:</li></ol>
 
 ```shell
-$ KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
+KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
 ```
 
 ## Best practices for replicating masters for HA clusters

content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md

@@ -71,10 +71,14 @@ Otherwise, you must manually approve certificates with the [`kubectl certificate
 The following kubeadm command outputs the name of the certificate to approve, then blocks and waits for approval to occur:
 
 ```shell
-$ sudo kubeadm alpha certs renew apiserver --use-api &
+sudo kubeadm alpha certs renew apiserver --use-api &
+```
+```
 [1] 2890
 [certs] certificate request "kubeadm-cert-kube-apiserver-ld526" created
-$ kubectl certificate approve kubeadm-cert-kube-apiserver-ld526
+```
+```shell
+kubectl certificate approve kubeadm-cert-kube-apiserver-ld526
 certificatesigningrequest.certificates.k8s.io/kubeadm-cert-kube-apiserver-ld526 approved
 [1]+  Done                    sudo kubeadm alpha certs renew apiserver --use-api
 ```

content/en/docs/tasks/administer-cluster/namespaces-walkthrough.md

@@ -45,7 +45,9 @@ Services, and Deployments used by the cluster.
 Assuming you have a fresh cluster, you can inspect the available namespaces by doing the following:
 
 ```shell
-$ kubectl get namespaces
+kubectl get namespaces
+```
+```
 NAME      STATUS    AGE
 default   Active    13m
 ```
@@ -74,7 +76,7 @@ Use the file [`namespace-dev.json`](/examples/admin/namespace-dev.json) which de
 Create the `development` namespace using kubectl.
 
 ```shell
-$ kubectl create -f https://k8s.io/examples/admin/namespace-dev.json
+kubectl create -f https://k8s.io/examples/admin/namespace-dev.json
 ```
 
 Save the following contents into file [`namespace-prod.json`](/examples/admin/namespace-prod.json) which describes a `production` namespace:
@@ -84,13 +86,15 @@ Save the following contents into file [`namespace-prod.json`](/examples/admin/na
 And then let's create the `production` namespace using kubectl.
 
 ```shell
-$ kubectl create -f https://k8s.io/examples/admin/namespace-prod.json
+kubectl create -f https://k8s.io/examples/admin/namespace-prod.json
 ```
 
 To be sure things are right, let's list all of the namespaces in our cluster.
 
 ```shell
-$ kubectl get namespaces --show-labels
+kubectl get namespaces --show-labels
+```
+```
 NAME          STATUS    AGE       LABELS
 default       Active    32m       <none>
 development   Active    29s       name=development
@@ -108,7 +112,9 @@ To demonstrate this, let's spin up a simple Deployment and Pods in the `developm
 We first check what is the current context:
 
 ```shell
-$ kubectl config view
+kubectl config view
+```
+```yaml
 apiVersion: v1
 clusters:
 - cluster:
@@ -133,18 +139,22 @@ users:
   user:
     password: h5M0FtUUIflBSdI7
     username: admin
-
-$ kubectl config current-context
+```
+```shell
+kubectl config current-context
+```
+```
 lithe-cocoa-92103_kubernetes
 ```
 
 The next step is to define a context for the kubectl client to work in each namespace. The value of "cluster" and "user" fields are copied from the current context.
 
 ```shell
-$ kubectl config set-context dev --namespace=development \
+kubectl config set-context dev --namespace=development \
   --cluster=lithe-cocoa-92103_kubernetes \
   --user=lithe-cocoa-92103_kubernetes
-$ kubectl config set-context prod --namespace=production \
+
+kubectl config set-context prod --namespace=production \
   --cluster=lithe-cocoa-92103_kubernetes \
   --user=lithe-cocoa-92103_kubernetes
 ```
@@ -156,7 +166,9 @@ new request contexts depending on which namespace you wish to work against.
 To view the new contexts:
 
 ```shell
-$ kubectl config view
+kubectl config view
+```
+```yaml
 apiVersion: v1
 clusters:
 - cluster:
@@ -196,13 +208,15 @@ users:
 Let's switch to operate in the `development` namespace.
 
 ```shell
-$ kubectl config use-context dev
+kubectl config use-context dev
 ```
 
 You can verify your current context by doing the following:
 
 ```shell
-$ kubectl config current-context
+kubectl config current-context
+```
+```
 dev
 ```
 
@@ -211,18 +225,24 @@ At this point, all requests we make to the Kubernetes cluster from the command l
 Let's create some contents.
 
 ```shell
-$ kubectl run snowflake --image=kubernetes/serve_hostname --replicas=2
+kubectl run snowflake --image=kubernetes/serve_hostname --replicas=2
 ```
 We have just created a deployment whose replica size is 2 that is running the pod called `snowflake` with a basic container that just serves the hostname.
 Note that `kubectl run` creates deployments only on Kubernetes cluster >= v1.2. If you are running older versions, it creates replication controllers instead.
 If you want to obtain the old behavior, use `--generator=run/v1` to create replication controllers. See [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) for more details.
 
 ```shell
-$ kubectl get deployment
+kubectl get deployment
+```
+```
 NAME        DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
 snowflake   2         2         2            2           2m
+```
 
-$ kubectl get pods -l run=snowflake
+```shell
+kubectl get pods -l run=snowflake
+```
+```
 NAME                         READY     STATUS    RESTARTS   AGE
 snowflake-3968820950-9dgr8   1/1       Running   0          2m
 snowflake-3968820950-vgc4n   1/1       Running   0          2m
@@ -233,22 +253,24 @@ And this is great, developers are able to do what they want, and they do not hav
 Let's switch to the `production` namespace and show how resources in one namespace are hidden from the other.
 
 ```shell
-$ kubectl config use-context prod
+kubectl config use-context prod
 ```
 
 The `production` namespace should be empty, and the following commands should return nothing.
 
 ```shell
-$ kubectl get deployment
-$ kubectl get pods
+kubectl get deployment
+kubectl get pods
 ```
 
 Production likes to run cattle, so let's create some cattle pods.
 
 ```shell
-$ kubectl run cattle --image=kubernetes/serve_hostname --replicas=5
+kubectl run cattle --image=kubernetes/serve_hostname --replicas=5
 
-$ kubectl get deployment
+kubectl get deployment
+```
+```
 NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
 cattle    5         5         5            5           10s
 

content/en/docs/tasks/administer-cluster/namespaces.md

@@ -22,7 +22,9 @@ This page shows how to view, work in, and delete {{< glossary_tooltip text="name
 1. List the current namespaces in a cluster using:
 
 ```shell
-$ kubectl get namespaces
+kubectl get namespaces
+```
+```
 NAME          STATUS    AGE
 default       Active    11d
 kube-system   Active    11d
@@ -38,13 +40,15 @@ Kubernetes starts with three initial namespaces:
 You can also get the summary of a specific namespace using:
 
 ```shell
-$ kubectl get namespaces <name>
+kubectl get namespaces <name>
 ```
 
 Or you can get detailed information with:
 
 ```shell
-$ kubectl describe namespaces <name>
+kubectl describe namespaces <name>
+```
+```
 Name:           default
 Labels:         <none>
 Annotations:    <none>
@@ -89,7 +93,7 @@ metadata:
 Then run:
 
 ```shell
-$ kubectl create -f ./my-namespace.yaml
+kubectl create -f ./my-namespace.yaml
 ```
 
 Note that the name of your namespace must be a DNS compatible label.
@@ -103,7 +107,7 @@ More information on `finalizers` can be found in the namespace [design doc](http
 1. Delete a namespace with
 
 ```shell
-$ kubectl delete namespaces <insert-some-namespace-name>
+kubectl delete namespaces <insert-some-namespace-name>
 ```
 
 {{< warning >}}
@@ -122,7 +126,9 @@ Services, and Deployments used by the cluster.
 Assuming you have a fresh cluster, you can introspect the available namespace's by doing the following:
 
 ```shell
-$ kubectl get namespaces
+kubectl get namespaces
+```
+```
 NAME      STATUS    AGE
 default   Active    13m
 ```
@@ -151,19 +157,21 @@ Use the file [`namespace-dev.json`](/examples/admin/namespace-dev.json) which de
 Create the `development` namespace using kubectl.
 
 ```shell
-$ kubectl create -f https://k8s.io/examples/admin/namespace-dev.json
+kubectl create -f https://k8s.io/examples/admin/namespace-dev.json
 ```
 
 And then let's create the `production` namespace using kubectl.
 
 ```shell
-$ kubectl create -f https://k8s.io/examples/admin/namespace-prod.json
+kubectl create -f https://k8s.io/examples/admin/namespace-prod.json
 ```
 
 To be sure things are right, list all of the namespaces in our cluster.
 
 ```shell
-$ kubectl get namespaces --show-labels
+kubectl get namespaces --show-labels
+```
+```
 NAME          STATUS    AGE       LABELS
 default       Active    32m       <none>
 development   Active    29s       name=development
@@ -181,7 +189,9 @@ To demonstrate this, let's spin up a simple Deployment and Pods in the `developm
 We first check what is the current context:
 
 ```shell
-$ kubectl config view
+kubectl config view
+```
+```yaml
 apiVersion: v1
 clusters:
 - cluster:
@@ -206,16 +216,20 @@ users:
   user:
     password: h5M0FtUUIflBSdI7
     username: admin
+```
 
-$ kubectl config current-context
+```shell
+kubectl config current-context
+```
+```
 lithe-cocoa-92103_kubernetes
 ```
 
 The next step is to define a context for the kubectl client to work in each namespace. The values of "cluster" and "user" fields are copied from the current context.
 
 ```shell
-$ kubectl config set-context dev --namespace=development --cluster=lithe-cocoa-92103_kubernetes --user=lithe-cocoa-92103_kubernetes
-$ kubectl config set-context prod --namespace=production --cluster=lithe-cocoa-92103_kubernetes --user=lithe-cocoa-92103_kubernetes
+kubectl config set-context dev --namespace=development --cluster=lithe-cocoa-92103_kubernetes --user=lithe-cocoa-92103_kubernetes
+kubectl config set-context prod --namespace=production --cluster=lithe-cocoa-92103_kubernetes --user=lithe-cocoa-92103_kubernetes
 ```
 
 The above commands provided two request contexts you can alternate against depending on what namespace you
@@ -224,13 +238,13 @@ wish to work against.
 Let's switch to operate in the `development` namespace.
 
 ```shell
-$ kubectl config use-context dev
+kubectl config use-context dev
 ```
 
 You can verify your current context by doing the following:
 
 ```shell
-$ kubectl config current-context
+kubectl config current-context
 dev
 ```
 
@@ -239,18 +253,23 @@ At this point, all requests we make to the Kubernetes cluster from the command l
 Let's create some contents.
 
 ```shell
-$ kubectl run snowflake --image=kubernetes/serve_hostname --replicas=2
+kubectl run snowflake --image=kubernetes/serve_hostname --replicas=2
 ```
 We have just created a deployment whose replica size is 2 that is running the pod called `snowflake` with a basic container that just serves the hostname.
 Note that `kubectl run` creates deployments only on Kubernetes cluster >= v1.2. If you are running older versions, it creates replication controllers instead.
 If you want to obtain the old behavior, use `--generator=run/v1` to create replication controllers. See [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run) for more details.
 
 ```shell
-$ kubectl get deployment
+kubectl get deployment
+```
+```
 NAME        DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
 snowflake   2         2         2            2           2m
-
-$ kubectl get pods -l run=snowflake
+```
+```shell
+kubectl get pods -l run=snowflake
+```
+```
 NAME                         READY     STATUS    RESTARTS   AGE
 snowflake-3968820950-9dgr8   1/1       Running   0          2m
 snowflake-3968820950-vgc4n   1/1       Running   0          2m
@@ -261,26 +280,32 @@ And this is great, developers are able to do what they want, and they do not hav
 Let's switch to the `production` namespace and show how resources in one namespace are hidden from the other.
 
 ```shell
-$ kubectl config use-context prod
+kubectl config use-context prod
 ```
 
 The `production` namespace should be empty, and the following commands should return nothing.
 
 ```shell
-$ kubectl get deployment
-$ kubectl get pods
+kubectl get deployment
+kubectl get pods
 ```
 
 Production likes to run cattle, so let's create some cattle pods.
 
 ```shell
-$ kubectl run cattle --image=kubernetes/serve_hostname --replicas=5
+kubectl run cattle --image=kubernetes/serve_hostname --replicas=5
 
-$ kubectl get deployment
+kubectl get deployment
+```
+```
 NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
 cattle    5         5         5            5           10s
+```
 
+```shell
 kubectl get pods -l run=cattle
+```
+```
 NAME                      READY     STATUS    RESTARTS   AGE
 cattle-2263376956-41xy6   1/1       Running   0          34s
 cattle-2263376956-kw466   1/1       Running   0          34s

content/en/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md

@@ -30,10 +30,14 @@ To start minikube, minimal version required is >= v0.33.1, run the with the
 following arguments:
 
 ```shell
-$ minikube version
+minikube version
+```
+```
 minikube version: v0.33.1
-$
-$ minikube start --network-plugin=cni --memory=4096
+```
+
+```shell
+minikube start --network-plugin=cni --memory=4096
 ```
 
 For minikube you can deploy this simple ''all-in-one'' YAML file that includes
@@ -41,7 +45,9 @@ DaemonSet configurations for Cilium, and the necessary configurations to connect
 to the etcd instance deployed in minikube as well as appropriate RBAC settings:
 
 ```shell
-$ kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.4/examples/kubernetes/1.13/cilium-minikube.yaml
+kubectl create -f  https://raw.githubusercontent.com/cilium/cilium/v1.4/examples/kubernetes/1.13/cilium-minikube.yaml
+```
+```
 configmap/cilium-config created
 daemonset.apps/cilium created
 clusterrolebinding.rbac.authorization.k8s.io/cilium created

content/en/docs/tasks/administer-cluster/safely-drain-node.md

@@ -117,7 +117,7 @@ itself. To attempt an eviction (perhaps more REST-precisely, to attempt to
 You can attempt an eviction using `curl`:
 
 ```bash
-$ curl -v -H 'Content-type: application/json' http://127.0.0.1:8080/api/v1/namespaces/default/pods/quux/eviction -d @eviction.json
+curl -v -H 'Content-type: application/json' http://127.0.0.1:8080/api/v1/namespaces/default/pods/quux/eviction -d @eviction.json
 ```
 
 The API can respond in one of three ways:

content/en/docs/tasks/administer-cluster/sysctl-cluster.md

@@ -36,7 +36,7 @@ process file system. The parameters cover various subsystems such as:
 To get a list of all parameters, you can run
 
 ```shell
-$ sudo sysctl -a
+sudo sysctl -a
 ```
 
 ## Enabling Unsafe Sysctls
@@ -76,14 +76,14 @@ application tuning. _Unsafe_ sysctls are enabled on a node-by-node basis with a
 flag of the kubelet, e.g.:
 
 ```shell
-$ kubelet --allowed-unsafe-sysctls \
+kubelet --allowed-unsafe-sysctls \
   'kernel.msg*,net.ipv4.route.min_pmtu' ...
 ```
 
 For minikube, this can be done via the `extra-config` flag:
 
 ```shell
-$ minikube start --extra-config="kubelet.AllowedUnsafeSysctls=kernel.msg*,net.ipv4.route.min_pmtu"...
+minikube start --extra-config="kubelet.AllowedUnsafeSysctls=kernel.msg*,net.ipv4.route.min_pmtu"...
 ```
 
 Only _namespaced_ sysctls can be enabled this way.