Add admonition type to shortcode (#9482)

* Change existing admon blocks

* Fix includes issue

content/en/docs/tasks/debug-application-cluster/audit.md

@@ -46,8 +46,8 @@ Each request can be recorded with an associated "stage". The known stages are:
 - `Panic` - Events generated when a panic occurred.
 
 {{< note >}}
-**Note** The audit logging feature increases the memory consumption of the API
-server because some context required for auditing is stored for each request.
+The audit logging feature increases the memory consumption of the API server
+because some context required for auditing is stored for each request.
 Additionally, memory consumption depends on the audit logging configuration.
 {{< /note >}}
 
@@ -102,7 +102,7 @@ In both cases, audit events structure is defined by the API in the
 [`v1`][auditing-api].
 
 {{< note >}}
-**Note:** In case of patches, request body is a JSON array with patch operations, not a JSON object
+In case of patches, request body is a JSON array with patch operations, not a JSON object
 with an appropriate Kubernetes API object. For example, the following request body is a valid patch
 request to `/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`.
 
@@ -216,7 +216,7 @@ In this example, we will use fluentd to split audit events by different namespac
 
 1. install [fluentd][fluentd_install_doc],  fluent-plugin-forest and fluent-plugin-rewrite-tag-filter in the kube-apiserver node
 {{< note >}}
-**Note:** Fluent-plugin-forest and fluent-plugin-rewrite-tag-filter are plugins for fluentd. You can get details about plugin installation from [fluentd plugin-management][fluentd_plugin_management_doc].
+Fluent-plugin-forest and fluent-plugin-rewrite-tag-filter are plugins for fluentd. You can get details about plugin installation from [fluentd plugin-management][fluentd_plugin_management_doc].
 {{< /note >}}
 
 1. create a config file for fluentd

content/en/docs/tasks/debug-application-cluster/core-metrics-pipeline.md

@@ -34,7 +34,7 @@ The API is defined in [k8s.io/metrics](https://github.com/kubernetes/metrics/blo
 repository. You can find more information about the API there.
 
 {{< note >}}
-**Note:** The API requires metrics server to be deployed in the cluster. Otherwise it will be not available.
+The API requires metrics server to be deployed in the cluster. Otherwise it will be not available.
 {{< /note >}}
 
 ## Metrics Server

content/en/docs/tasks/debug-application-cluster/crictl.md

@@ -67,7 +67,7 @@ debug: true
 The following examples show some `crictl` commands and example output.
 
 {{< warning >}}
-**Warning:** If you use `crictl` to create pod sandboxes or containers on a running
+If you use `crictl` to create pod sandboxes or containers on a running
 Kubernetes cluster, the Kubelet will eventually delete them. `crictl` is not a
 general purpose workflow tool, but a tool that is useful for debugging.
 {{< /warning >}}

content/en/docs/tasks/debug-application-cluster/debug-application.md

@@ -84,7 +84,7 @@ $ kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${
 ```
 
 {{< note >}}
-**Note:** `-c ${CONTAINER_NAME}` is optional. You can omit it for Pods that only contain a single container.
+`-c ${CONTAINER_NAME}` is optional. You can omit it for Pods that only contain a single container.
 {{< /note >}}
 
 As an example, to look at the logs from a running Cassandra pod, you might run

content/en/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md

@@ -112,8 +112,10 @@ Alternately, you can run commands inside that container with `exec`:
 kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}
 ```
 
-{{< note >}}**Note:** `-c ${CONTAINER_NAME}` is optional. You can omit it for pods that
-only contain a single container.{{< /note >}}
+{{< note >}}
+`-c ${CONTAINER_NAME}` is optional. You can omit it for pods that
+only contain a single container.
+{{< /note >}}
 
 As an example, to look at the logs from a running Cassandra pod, you might run:
 

content/en/docs/tasks/debug-application-cluster/debug-service.md

@@ -79,7 +79,7 @@ deployment.apps/hostnames created
 
 `kubectl` commands will print the type and name of the resource created or mutated, which can then be used in subsequent commands.
 {{< note >}}
-**Note:** This is the same as if you started the `Deployment` with the following YAML:
+This is the same as if you started the `Deployment` with the following YAML:
 
 ```yaml
 apiVersion: apps/v1
@@ -214,7 +214,10 @@ The "cluster.local" is your cluster domain, which COULD be different in your
 own cluster.
 
 You can also try this from a `Node` in the cluster:
-{{< note >}}**Note:** 10.0.0.10 is my DNS `Service`, yours might be different){{< /note >}}
+
+{{< note >}}
+10.0.0.10 is my DNS `Service`, yours might be different).
+{{< /note >}}
 
 ```shell
 u@node$ nslookup hostnames.default.svc.cluster.local 10.0.0.10
@@ -383,8 +386,11 @@ as the `Service` selecting for `run=hostnames`, but the `Deployment` specifying
 
 At this point, we know that your `Service` exists and has selected your `Pods`.
 Let's check that the `Pods` are actually working - we can bypass the `Service`
-mechanism and go straight to the `Pods`.  
-{{< note >}}**Note:** These commands use the `Pod` port (9376), rather than the `Service` port (80).{{< /note >}}
+mechanism and go straight to the `Pods`.
+
+{{< note >}}
+These commands use the `Pod` port (9376), rather than the `Service` port (80).
+{{< /note >}}
 
 ```shell
 u@pod$ wget -qO- 10.244.0.5:9376

content/en/docs/tasks/debug-application-cluster/events-stackdriver.md

@@ -25,7 +25,7 @@ This article describes a solution that exports Kubernetes events to
 Stackdriver Logging, where they can be processed and analyzed.
 
 {{< note >}}
-**Note:** It is not guaranteed that all events happening in a cluster will be
+It is not guaranteed that all events happening in a cluster will be
 exported to Stackdriver. One possible scenario when events will not be
 exported is when event exporter is not running (e.g. during restart or
 upgrade). In most cases it's fine to use events for purposes like setting up

content/en/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md

@@ -18,7 +18,7 @@ them using [Kibana](https://www.elastic.co/products/kibana), as an alternative t
 Stackdriver Logging when running on GCE. 
 
 {{< note >}}
-**Note:** You cannot automatically deploy Elasticsearch and Kibana in the Kubernetes cluster hosted on Google Kubernetes Engine. You have to deploy them manually.
+You cannot automatically deploy Elasticsearch and Kibana in the Kubernetes cluster hosted on Google Kubernetes Engine. You have to deploy them manually.
 {{< /note >}}
 
 {{% /capture %}}

content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md

@@ -12,7 +12,7 @@ Before reading this page, it's highly recommended to familiarize yourself
 with the [overview of logging in Kubernetes](/docs/concepts/cluster-administration/logging).
 
 {{< note >}}
-**Note:** By default, Stackdriver logging collects only your container's standard output and
+By default, Stackdriver logging collects only your container's standard output and
 standard error streams. To collect any logs your application writes to a file (for example),
 see the [sidecar approach](/docs/concepts/cluster-administration/logging#sidecar-container-with-a-logging-agent)
 in the Kubernetes logging overview.
@@ -52,7 +52,7 @@ consider starting a cluster without a pre-configured logging solution and then d
 Stackdriver Logging agents to the running cluster.
 
 {{< warning >}}
-**Warning:** The Stackdriver logging daemon has known issues on platforms other
+The Stackdriver logging daemon has known issues on platforms other
 than Google Kubernetes Engine. Proceed at your own risk.
 {{< /warning >}}
 
@@ -88,9 +88,11 @@ than Google Kubernetes Engine. Proceed at your own risk.
     kubectl label node $NODE_NAME beta.kubernetes.io/fluentd-ds-ready=true
     ```
 
-    {{< note >}}**Note:** If a node fails and has to be recreated, you must re-apply the label to
+    {{< note >}}
+    If a node fails and has to be recreated, you must re-apply the label to
     the recreated node. To make this easier, you can use Kubelet's command-line parameter
-    for applying node labels in your node startup script.{{< /note >}}
+    for applying node labels in your node startup script.
+    {{< /note >}}
 
 1. Deploy a `ConfigMap` with the logging agent configuration by running the following command:
 
@@ -263,8 +265,12 @@ In this case you need to be able to change the parameters of `DaemonSet` and `Co
 If you're using GKE and Stackdriver Logging is enabled in your cluster, you
 cannot change its configuration, because it's managed and supported by GKE.
 However, you can disable the default integration and deploy your own.
-{{< note >}}**Note:** You will have to support and maintain a newly deployed configuration
-yourself: update the image and configuration, adjust the resources and so on.{{< /note >}}
+
+{{< note >}}
+You will have to support and maintain a newly deployed configuration
+yourself: update the image and configuration, adjust the resources and so on.
+{{< /note >}}
+
 To disable the default logging integration, use the following command:
 
 ```
@@ -325,7 +331,10 @@ kubectl get cm fluentd-gcp-config --namespace kube-system -o yaml > fluentd-gcp-
 
 Then in the value for the key `containers.input.conf` insert a new filter right after
 the `source` section.
-{{< note >}}**Note:** Order is important.{{< /note >}}
+
+{{< note >}}
+Order is important.
+{{< /note >}}
 
 Updating `ConfigMap` in the apiserver is more complicated than updating `DaemonSet`. It's better
 to consider `ConfigMap` to be immutable. Then, in order to update the configuration, you should