Add admonition type to shortcode (#9482)

* Change existing admon blocks * Fix includes issue
2018-11-06 11:33:04 -08:00
parent e839031292
commit d65e1790ff
192 changed files with 673 additions and 543 deletions
@@ -105,7 +105,7 @@ For example, consider key pairs `k8sclient.key` and `k8sclient.cert` that are tr
 Once etcd is configured correctly, only clients with valid certificates can access it. To give Kubernetes API server the access, configure it with the flags `--etcd-certfile=k8sclient.cert`,`--etcd-keyfile=k8sclient.key` and `--etcd-cafile=ca.cert`.

 {{< note >}}
-**Note**: etcd authentication is not currently supported by Kubernetes. For more information, see the related issue [Support Basic Auth for Etcd v2](https://github.com/kubernetes/kubernetes/issues/23398).
+etcd authentication is not currently supported by Kubernetes. For more information, see the related issue [Support Basic Auth for Etcd v2](https://github.com/kubernetes/kubernetes/issues/23398).
 {{< /note >}}

 ## Replacing a failed etcd member
@@ -212,7 +212,7 @@ The upgrade procedure described in this document assumes that either:
   etcd cluster. During the time the etcd cluster is shut down, the Kubernetes API Server will be read only.

 {{< warning >}}
-**Warning**: Deviations from the assumptions are untested by continuous
+Deviations from the assumptions are untested by continuous
 integration, and deviations might create undesirable consequences. Additional information about operating an etcd cluster is available [from the etcd maintainers](https://github.com/coreos/etcd/tree/master/Documentation).
 {{< /warning >}}

@@ -264,7 +264,7 @@ but the rollback tool has these limitations:
 * Rollback doesn’t preserve resource versions of objects stored in etcd.

 {{< warning >}}
-**Warning**: If the data is not kept in `application/json` format (see [Upgrade
+If the data is not kept in `application/json` format (see [Upgrade
 Procedure](#upgrade-procedure)), you will lose the option to roll back to etcd
 2.2.
 {{< /warning >}}
@@ -276,7 +276,7 @@ resource versions. Since both the kubelet and kube-proxy use the watch API, a
 rollback might require restarting all Kubernetes components on all nodes.

 {{< note >}}
-**Note**: At the time of writing, both Kubelet and KubeProxy are using “resource
+At the time of writing, both Kubelet and KubeProxy are using “resource
 version” only for watching (i.e. are not using resource versions for anything
 else). And both are using reflector and/or informer frameworks for watching
 (i.e. they don’t send watch requests themselves). Both those frameworks if they
@@ -390,7 +390,7 @@ STORAGE_MEDIA_TYPE=application/json
 ```

 {{< note >}}
-**Note:** This procedure upgrades from 2.x to 3.x.  Version `3.0.17` is not recommended for running in production (see [prerequisites](#prerequisites) for minimum recommended etcd versions).
+This procedure upgrades from 2.x to 3.x.  Version `3.0.17` is not recommended for running in production (see [prerequisites](#prerequisites) for minimum recommended etcd versions).
 {{< /note >}}

 ## Notes for etcd Version 2.2.1
@@ -52,7 +52,7 @@ your existing Corefile will be retained.
 ## Installing kube-dns instead of CoreDNS with kubeadm

 {{< note >}}
-**Note:** In Kubernetes 1.11, CoreDNS has graduated to General Availability (GA)
+In Kubernetes 1.11, CoreDNS has graduated to General Availability (GA)
 and is installed by default.
 {{< /note >}}

@@ -75,16 +75,16 @@ The `static` policy allows containers in `Guaranteed` pods with integer CPU
 using the [cpuset cgroup controller](https://www.kernel.org/doc/Documentation/cgroup-v1/cpusets.txt).

 {{< note >}}
-**Note:** System services such as the container runtime and the kubelet itself can continue to run on these exclusive CPUs.  The exclusivity only extends to other pods.
+System services such as the container runtime and the kubelet itself can continue to run on these exclusive CPUs.  The exclusivity only extends to other pods.
 {{< /note >}}

 {{< note >}}
-**Note:** The alpha version of this policy does not guarantee static
+The alpha version of this policy does not guarantee static
 exclusive allocations across Kubelet restarts.
 {{< /note >}}

 {{< note >}}
-**Note:** CPU Manager doesn't support offlining and onlining of
+CPU Manager doesn't support offlining and onlining of
 CPUs at runtime. Also, if the set of online CPUs changes on the node,
 the node must be drained and CPU manager manually reset by deleting the
 state file `cpu_manager_state` in the kubelet root directory.
@@ -102,7 +102,7 @@ both part of a `Guaranteed` pod and have integer CPU `requests` are assigned
 exclusive CPUs.

 {{< note >}}
-**Note:** The kubelet requires a CPU reservation greater than zero be made
+The kubelet requires a CPU reservation greater than zero be made
 using either `--kube-reserved` and/or `--system-reserved` when the static
 policy is enabled. This is because zero CPU reservation would allow the shared
 pool to become empty.
@@ -21,7 +21,9 @@ Make sure you've configured a network provider with network policy support. Ther
 * [Romana](/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy/)
 * [Weave Net](/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy/)

-**Note**: The above list is sorted alphabetically by product name, not by recommendation or preference. This example is valid for a Kubernetes cluster using any of these providers.
+{{< note >}}
+The above list is sorted alphabetically by product name, not by recommendation or preference. This example is valid for a Kubernetes cluster using any of these providers.
+{{< /note >}}
 {{% /capture %}}

 {{% capture steps %}}
@@ -66,9 +66,11 @@ resources from storage each provider that matches the stored data attempts to de
 order. If no provider can read the stored data due to a mismatch in format or secret key, an error 
 is returned which prevents clients from accessing that resource. 

-**IMPORTANT:** If any resource is not readable via the encryption config (because keys were changed), 
+{{< caution >}}
+If any resource is not readable via the encryption config (because keys were changed), 
 the only recourse is to delete that key from the underlying etcd directly. Calls that attempt to 
 read that resource will fail until it is deleted or a valid decryption key is provided.
+{{< /caution >}}

 ### Providers:

@@ -113,7 +115,9 @@ To create a new secret perform the following steps:
 3. Set the `--experimental-encryption-provider-config` flag on the `kube-apiserver` to point to the location of the config file.
 4. Restart your API server.

-**IMPORTANT:** Your config file contains keys that can decrypt content in etcd, so you must properly restrict permissions on your masters so only the user who runs the kube-apiserver can read it.
+{{< caution >}}
+Your config file contains keys that can decrypt content in etcd, so you must properly restrict permissions on your masters so only the user who runs the kube-apiserver can read it.
+{{< /caution >}}


 ## Verifying that data is encrypted 
@@ -74,10 +74,12 @@ curl --header "Content-Type: application/json-patch+json" \
 http://localhost:8001/api/v1/nodes/<your-node-name>/status
 ```

-**Note**: In the preceding request, `~1` is the encoding for the character / in
+{{< note >}}
+In the preceding request, `~1` is the encoding for the character / in
 the patch path. The operation path value in JSON-Patch is interpreted as a
 JSON-Pointer. For more details, see
 [IETF RFC 6901](https://tools.ietf.org/html/rfc6901), section 3.
+{{< /note >}}

 The output shows that the Node has a capacity of 4 dongles:

@@ -73,14 +73,16 @@ kubectl label nodes my-node beta.kubernetes.io/masq-agent-ds-ready=true
 More information can be found in the ip-masq-agent documentation [here](https://github.com/kubernetes-incubator/ip-masq-agent)

 In most cases, the default set of rules should be sufficient; however, if this is not the case for your cluster, you can create and apply a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) to customize the IP ranges that are affected.  For example, to allow only 10.0.0.0/8 to be considered by the ip-masq-agent, you can create the following [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) in a file called "config".
-**Note:** It is important that the file is called config since, by default, that will be used as the key for lookup by the ip-masq-agent:
+
+{{< note >}}
+It is important that the file is called config since, by default, that will be used as the key for lookup by the ip-masq-agent:

 ```
 nonMasqueradeCIDRs:
  - 10.0.0.0/8
 resyncInterval: 60s
-
 ```
+{{< /note >}}

 Run the following command to add the config map to your cluster:

@@ -24,8 +24,7 @@ Before proceeding:
 - Check the prerequisites for [Upgrading/downgrading kubeadm clusters between v1.11 to v1.12](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade-1-12/).

 {{< note >}}
-**Note**: All commands on any control plane or etcd node should be
-run as root.
+All commands on any control plane or etcd node should be run as root.
 {{< /note >}}

 {{% /capture %}}
@@ -82,7 +82,7 @@ CPU request and limit to the Container.
 * Verify that the Container specifies a CPU limit that is less than or equal to 800 millicpu.

 {{< note >}}
-**Note:** When creating a `LimitRange` object, you can specify limits on huge-pages
+When creating a `LimitRange` object, you can specify limits on huge-pages
 or GPUs as well. However, when both `default` and `defaultRequest` are specified
 on these resources, the two values must be the same.
 {{< /note >}}
@@ -106,7 +106,9 @@ More information on `finalizers` can be found in the namespace [design doc](http
 $ kubectl delete namespaces <insert-some-namespace-name>
 ```

-**WARNING, this deletes _everything_ under the namespace!**
+{{< warning >}}
+This deletes _everything_ under the namespace!
+{{< /warning >}}

 This delete is asynchronous, so for a time you will see the namespace in the `Terminating` state.

@@ -14,7 +14,7 @@ allows you to change the configuration of each Kubelet in a live Kubernetes
 cluster by deploying a ConfigMap and configuring each Node to use it.

 {{< warning >}}
-**Warning:** All Kubelet configuration parameters can be changed dynamically,
+All Kubelet configuration parameters can be changed dynamically,
 but this is unsafe for some parameters. Before deciding to change a parameter
 dynamically, you need a strong understanding of how that change will affect your
 cluster's behavior. Always carefully test configuration changes on a small set
@@ -69,7 +69,7 @@ This document only describes a single Node consuming each ConfigMap. Keep in
 mind that it is also valid for multiple Nodes to consume the same ConfigMap.

 {{< warning >}}
-**Warning:** While it is *possible* to change the configuration by
+While it is *possible* to change the configuration by
 updating the ConfigMap in-place, this causes all Kubelets configured with
 that ConfigMap to update simultaneously. It is much safer to treat ConfigMaps
 as immutable by convention, aided by `kubectl`'s `--append-hash` option,
@@ -37,10 +37,12 @@ hardware maintenance, etc.). Safe evictions allow the pod's containers
 to [gracefully terminate](/docs/concepts/workloads/pods/pod/#termination-of-pods)
 and will respect the `PodDisruptionBudgets` you have specified.

-**Note:** By default `kubectl drain` will ignore certain system pods on the node
+{{< note >}}
+By default `kubectl drain` will ignore certain system pods on the node
 that cannot be killed; see
 the [kubectl drain](/docs/reference/generated/kubectl/kubectl-commands/#drain)
 documentation for more details.
+{{< /note >}}

 When `kubectl drain` returns successfully, that indicates that all of
 the pods (except the ones excluded as described in the previous paragraph)
@@ -165,10 +165,12 @@ credentials from the API servers to their etcd server, such as mutual auth via T
 and it is often recommended to isolate the etcd servers behind a firewall that only the API servers
 may access. 

-**CAUTION:** Allowing other components within the cluster to access the master etcd instance with
+{{< caution >}}
+Allowing other components within the cluster to access the master etcd instance with
 read or write access to the full keyspace is equivalent to granting cluster-admin access. Using
 separate etcd instances for non-master components or using etcd ACLs to restrict read and write
 access to a subset of the keyspace is strongly recommended.
+{{< /caution >}}

 ### Enable audit logging

@@ -100,11 +100,10 @@ Labels from the static pod are propagated into the mirror-pod and can be used as

 Notice we cannot delete the pod with the API server (e.g. via [`kubectl`](/docs/user-guide/kubectl/) command), kubelet simply won't remove it.

-{{<note>}}
-**Note**: Make sure the kubelet has permission to create the mirror pod in the API server.
-If not, the creation request is rejected by the API server. See
+{{< note >}}
+Make sure the kubelet has permission to create the mirror pod in the API server. If not, the creation request is rejected by the API server. See
 [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/).
-{{</note>}}
+{{< /note >}}

 ```shell
 [joe@my-master ~] $ kubectl delete pod static-web-my-node1
@@ -58,7 +58,7 @@ The following sysctls are supported in the _safe_ set:
 - `net.ipv4.tcp_syncookies`.

 {{< note >}}
-**Note**: The example `net.ipv4.tcp_syncookies` is not namespaced on Linux kernel version 4.4 or lower.
+The example `net.ipv4.tcp_syncookies` is not namespaced on Linux kernel version 4.4 or lower.
 {{< /note >}}

 This list will be extended in future Kubernetes versions when the kubelet
@@ -141,7 +141,7 @@ spec:
 {{% capture discussion %}}

 {{< warning >}}
-**Warning**: Due to their nature of being _unsafe_, the use of _unsafe_ sysctls
+Due to their nature of being _unsafe_, the use of _unsafe_ sysctls
 is at-your-own-risk and can lead to severe problems like wrong behavior of
 containers, resource shortage or complete breakage of a node.
 {{< /warning >}}
@@ -184,7 +184,7 @@ Do not configure these two fields such that there is overlap, meaning that a
 given sysctl is both allowed and forbidden.

 {{< warning >}}
-**Warning**: If you whitelist unsafe sysctls via the `allowedUnsafeSysctls` field
+If you whitelist unsafe sysctls via the `allowedUnsafeSysctls` field
 in a PodSecurityPolicy, any pod using such a sysctl will fail to start
 if the sysctl is not whitelisted via the `--allowed-unsafe-sysctls` kubelet
 flag as well on that node.