Add admonition type to shortcode (#9482)

* Change existing admon blocks

* Fix includes issue

content/en/docs/reference/access-authn-authz/abac.md

@@ -49,12 +49,14 @@ properties:
           - `/foo/*` matches all subpaths of `/foo/`.
     - `readonly`, type boolean, when true, means that the Resource-matching policy only applies to get, list, and watch operations, Non-resource-matching policy only applies to get operation.
 
-**NOTES:** An unset property is the same as a property set to the zero value for its type
+{{< note >}}
+An unset property is the same as a property set to the zero value for its type
 (e.g. empty string, 0, false). However, unset should be preferred for
 readability.
 
 In the future, policies may be expressed in a JSON format, and managed via a
 REST interface.
+{{< /note >}}
 
 ## Authorization Algorithm
 

content/en/docs/reference/access-authn-authz/admission-controllers.md

@@ -66,11 +66,11 @@ kube-apiserver --enable-admission-plugins=NamespaceLifecycle,LimitRanger ...
 ```
 
 {{< note >}}
-**Note**: Depending on the way your Kubernetes cluster is deployed and how the
-API server is started, you may need to apply the settings in different ways.
-For example, you may have to modify the systemd unit file if the API server is
-deployed as a systemd service, you may modify the manifest file for the API
-server if Kubernetes is deployed in a self-hosted way.
+Depending on the way your Kubernetes cluster is deployed and how the API server is
+started, you may need to apply the settings in different ways. For example, you may
+have to modify the systemd unit file if the API server is deployed as a systemd
+service, you may modify the manifest file for the API server if Kubernetes is deployed
+in a self-hosted way.
 {{< /note >}}
 
 ## How do I turn off an admission controller?
@@ -489,7 +489,7 @@ plugin configuration file as the node selector.
 Conflicts result in rejection.
 
 {{< note >}}
-**Note:** PodNodeSelector allows forcing pods to run on specifically labeled nodes. Also see the PodTolerationRestriction 
+PodNodeSelector allows forcing pods to run on specifically labeled nodes. Also see the PodTolerationRestriction 
 admission plugin, which allows preventing pods from running on specifically tainted nodes.
 {{< /note >}}
 
@@ -498,7 +498,7 @@ admission plugin, which allows preventing pods from running on specifically tain
 This admission controller implements additional validations for checking incoming `PersistentVolumeClaim` resize requests.
 
 {{< note >}}
-**Note:** Support for volume resizing is available as an alpha feature. Admins must set the feature gate `ExpandPersistentVolumes`
+Support for volume resizing is available as an alpha feature. Admins must set the feature gate `ExpandPersistentVolumes`
 to `true` to enable resizing.
 {{< /note >}}
 
@@ -610,7 +610,7 @@ Yes.
 For Kubernetes version 1.10 and later, we recommend running the following set of admission controllers using the `--enable-admission-plugins` flag (**order doesn't matter**).
 
 {{< note >}}
-**Note:** `--admission-control` was deprecated in 1.10 and replaced with `--enable-admission-plugins`.
+`--admission-control` was deprecated in 1.10 and replaced with `--enable-admission-plugins`.
 {{< /note >}}
 
 ```shell

content/en/docs/reference/access-authn-authz/authentication.md

@@ -97,7 +97,7 @@ The token file is a csv file with a minimum of 3 columns: token, user name, user
 followed by optional group names.
 
 {{< note >}}
-**Note:** If you have more than one group the column must be double quoted e.g.
+If you have more than one group the column must be double quoted e.g.
 
 ```conf
 token,user,uid,"group1,group2,group3"
@@ -190,7 +190,7 @@ talk to the API server. Accounts may be explicitly associated with pods using th
 `serviceAccountName` field of a `PodSpec`.
 
 {{< note >}}
-**Note:** `serviceAccountName` is usually omitted because this is done automatically.
+`serviceAccountName` is usually omitted because this is done automatically.
 {{< /note >}}
 
 ```yaml
@@ -246,7 +246,7 @@ type: kubernetes.io/service-account-token
 ```
 
 {{< note >}}
-**Note:** Values are base64 encoded because secrets are always base64 encoded.
+Values are base64 encoded because secrets are always base64 encoded.
 {{< /note >}}
 
 The signed JWT can be used as a bearer token to authenticate as the given service
@@ -510,8 +510,9 @@ It is designed for use in combination with an authenticating proxy, which sets t
 * `--requestheader-username-headers` Required, case-insensitive. Header names to check, in order, for the user identity. The first header containing a value is used as the username.
 * `--requestheader-group-headers` 1.6+. Optional, case-insensitive. "X-Remote-Group" is suggested. Header names to check, in order, for the user's groups. All values in all specified headers are used as group names.
 * `--requestheader-extra-headers-prefix` 1.6+. Optional, case-insensitive. "X-Remote-Extra-" is suggested. Header prefixes to look for to determine extra information about the user (typically used by the configured authorization plugin). Any headers beginning with any of the specified prefixes have the prefix removed. The remainder of the header name is lowercased and [percent-decoded](https://tools.ietf.org/html/rfc3986#section-2.1) and becomes the extra key, and the header value is the extra value.
+
 {{< note >}}
-**Note:** Prior to 1.11.3 (and 1.10.7, 1.9.11), the extra key could only contain characters which were [legal in HTTP header labels](https://tools.ietf.org/html/rfc7230#section-3.2.6).
+Prior to 1.11.3 (and 1.10.7, 1.9.11), the extra key could only contain characters which were [legal in HTTP header labels](https://tools.ietf.org/html/rfc7230#section-3.2.6).
 {{< /note >}}
 
 For example, with this configuration:
@@ -601,7 +602,7 @@ The following HTTP headers can be used to performing an impersonation request:
 * `Impersonate-Extra-( extra name )`: A dynamic header used to associate extra fields with the user. Optional. Requires "Impersonate-User". In order to be preserved consistently, `( extra name )` should be lower-case, and any characters which aren't [legal in HTTP header labels](https://tools.ietf.org/html/rfc7230#section-3.2.6) MUST be utf8 and [percent-encoded](https://tools.ietf.org/html/rfc3986#section-2.1).
 
 {{< note >}}
-**Note:** Prior to 1.11.3 (and 1.10.7, 1.9.11), `( extra name )` could only contain characters which were [legal in HTTP header labels](https://tools.ietf.org/html/rfc7230#section-3.2.6).
+Prior to 1.11.3 (and 1.10.7, 1.9.11), `( extra name )` could only contain characters which were [legal in HTTP header labels](https://tools.ietf.org/html/rfc7230#section-3.2.6).
 {{< /note >}}
 
 An example set of headers:

content/en/docs/reference/access-authn-authz/authorization.md

@@ -168,12 +168,11 @@ secrets the user cannot themselves read, or that run under a service account
 with different/greater permissions.
 
 {{< caution >}}
-**Caution:** System administrators, use care when granting access to pod
-creation.  A user granted permission to create pods (or controllers that create
-pods) in the namespace can: read all secrets in the namespace; read all config
-maps in the namespace; and impersonate any service account in the namespace and
-take any action the account could take. This applies regardless of authorization
-mode.
+System administrators, use care when granting access to pod creation. A user
+granted permission to create pods (or controllers that create pods) in the
+namespace can: read all secrets in the namespace; read all config maps in the
+namespace; and impersonate any service account in the namespace and take any
+action the account could take. This applies regardless of authorization mode.
 {{< /caution >}}
 {{% /capture %}}
 

content/en/docs/reference/access-authn-authz/bootstrap-tokens.md

@@ -179,7 +179,7 @@ verify the JWS using the `HS256` scheme (HMAC-SHA256) with the full token (e.g.
 is used.
 
 {{< warning >}}
-**Warning:** Any party with a bootstrapping token can create a valid signature for that
+Any party with a bootstrapping token can create a valid signature for that
 token. When using ConfigMap signing it's discouraged to share the same token with
 many clients, since a compromised client can potentially man-in-the middle another
 client relying on the signature to bootstrap TLS trust.

content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md

@@ -120,7 +120,7 @@ webhooks:
 ```
 
 {{< note >}}
-**Note:** When using `clientConfig.service`, the server cert must be valid for
+When using `clientConfig.service`, the server cert must be valid for
 `<svc_name>.<svc_namespace>.svc`.
 {{< /note >}}
 
@@ -132,7 +132,7 @@ After you create the webhook configuration, the system will take a few seconds
 to honor the new configuration.
 
 {{< note >}}
-**Note:** When the webhook plugin is deployed into the Kubernetes cluster as a
+When the webhook plugin is deployed into the Kubernetes cluster as a
 service, it has to expose its service on the 443 port. The communication
 between the API server and the webhook service may fail if a different port
 is used.
@@ -228,7 +228,7 @@ admission controller), or to inject defaults (e.g., the
 admission controller), etc.
 
 {{< note >}}
-**Note:** If your use case does not involve mutating objects, consider using
+If your use case does not involve mutating objects, consider using
 external admission webhooks, as they have better performance.
 {{< /note >}}
 

content/en/docs/reference/access-authn-authz/rbac.md

@@ -807,7 +807,7 @@ In order from most secure to least secure, the approaches are:
 
     If an application does not specify a `serviceAccountName`, it uses the "default" service account.
 
-    {{< note >}}**Note:** Permissions given to the "default" service
+    {{< note >}}Permissions given to the "default" service
     account are available to any pod in the namespace that does not
     specify a `serviceAccountName`.{{< /note >}}
 
@@ -823,7 +823,7 @@ In order from most secure to least secure, the approaches are:
     Many [add-ons](/docs/concepts/cluster-administration/addons/) currently run as the "default" service account in the `kube-system` namespace.
     To allow those add-ons to run with super-user access, grant cluster-admin permissions to the "default" service account in the `kube-system` namespace.
 
-    {{< note >}}**Note:** Enabling this means the `kube-system`
+    {{< note >}}Enabling this means the `kube-system`
     namespace contains secrets that grant super-user access to the
     API.{{< /note >}}
 
@@ -863,9 +863,11 @@ In order from most secure to least secure, the approaches are:
 
     If you don't care about partitioning permissions at all, you can grant super-user access to all service accounts.
 
-    {{< warning >}}**Warning:** This allows any user with read access
+    {{< warning >}}
+    This allows any user with read access
     to secrets or the ability to create a pod to access super-user
-    credentials.{{< /warning >}}
+    credentials.
+    {{< /warning >}}
 
     ```shell
     kubectl create clusterrolebinding serviceaccounts-cluster-admin \
@@ -909,7 +911,7 @@ in the server logs, you can remove the ABAC authorizer.
 You can replicate a permissive policy using RBAC role bindings.
 
 {{< warning >}}
-**Warning:** The following policy allows **ALL** service accounts to act as cluster administrators.
+The following policy allows **ALL** service accounts to act as cluster administrators.
 Any application running in a container receives service account credentials automatically,
 and could perform any action against the API, including viewing secrets and modifying permissions.
 This is not a recommended policy.