Add admonition type to shortcode (#9482)

* Change existing admon blocks

* Fix includes issue
This commit is contained in:
Luc Perkins
2018-11-06 11:33:04 -08:00
committed by k8s-ci-robot
parent e839031292
commit d65e1790ff
192 changed files with 673 additions and 543 deletions
@@ -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
@@ -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
@@ -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:
@@ -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 %}}
@@ -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.
@@ -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 >}}
@@ -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.
@@ -147,7 +147,7 @@ A *Beta* feature means:
that can be upgraded independently, you may be able to relax this restriction.
{{< note >}}
**Note:** Please do try *Beta* features and give feedback on them!
Please do try *Beta* features and give feedback on them!
After they exit beta, it may not be practical for us to make more changes.
{{< /note >}}
@@ -221,7 +221,7 @@ specified by `--kubeconfig`. The certificate and key file will be placed in the
directory specified by `--cert-dir`.
{{< note >}}
**Note:** The following flags are required to enable this bootstrapping when starting the kubelet:
The following flags are required to enable this bootstrapping when starting the kubelet:
```
--bootstrap-kubeconfig="/path/to/bootstrap/kubeconfig"
@@ -251,7 +251,7 @@ certificate. To enable this feature pass the following flag to the kubelet:
```
{{< note >}}
**Note:** The CSR approving controllers implemented in core Kubernetes do not
The CSR approving controllers implemented in core Kubernetes do not
approve node serving certificates for [security
reasons](https://github.com/kubernetes/community/pull/1982). To use
`RotateKubeletServerCertificate` operators need to run a custom approving
@@ -16,5 +16,7 @@ tags:
Their primary responsibility is keeping a cluster up and running, which may involve periodic maintenance activities or upgrades.<br>
**NOTE:** Cluster operators are different from the [Operator pattern](https://coreos.com/operators) that extends the Kubernetes API.
{{< note >}}
Cluster operators are different from the [Operator pattern](https://coreos.com/operators) that extends the Kubernetes API.
{{< /note >}}
@@ -50,12 +50,14 @@ If you do not specify a generator flag, other flags prompt you to use a specific
| Job | `--restart=OnFailure` | `--restart=OnFailure` | `--restart=OnFailure` OR `--restart=Never` | N/A |
| Cron Job | `--schedule=<cron>` | N/A | N/A | N/A |
**Note:** These flags use a default generator only when you have not specified
any flag. This means that when you combine `--generator` with other flags the generator that you specified later does not change. For example, in a cluster v1.4, if you initially specify
{{< note >}}
These flags use a default generator only when you have not specified any flag.
This means that when you combine `--generator` with other flags the generator that you specified later does not change. For example, in a cluster v1.4, if you initially specify
`--restart=Always`, a Deployment is created; if you later specify `--restart=Always`
and `--generator=run/v1`, a Replication Controller is created.
This enables you to pin to a specific behavior with the generator,
even when the default generator is changed later.
{{< /note >}}
The flags set the generator in the following order: first the schedule flag then restart policy and finally the generator.
@@ -36,7 +36,7 @@ deployment "nginx-app" created
```
{{< note >}}
**Note:** `kubectl` commands print the type and name of the resource created or mutated, which can then be used in subsequent commands. You can expose a new Service after a Deployment is created.
`kubectl` commands print the type and name of the resource created or mutated, which can then be used in subsequent commands. You can expose a new Service after a Deployment is created.
{{< /note >}}
```shell
@@ -222,7 +222,7 @@ $ kubectl get po -l run=nginx-app
```
{{< note >}}
**Note:** When you use kubectl, you don't delete the pod directly.You have to first delete the Deployment that owns the pod. If you delete the pod directly, the Deployment recreates the pod.
When you use kubectl, you don't delete the pod directly.You have to first delete the Deployment that owns the pod. If you delete the pod directly, the Deployment recreates the pod.
{{< /note >}}
## docker login
@@ -45,7 +45,10 @@ where `command`, `TYPE`, `NAME`, and `flags` are:
Example: `$ kubectl get pod -f ./pod.yaml`
* `flags`: Specifies optional flags. For example, you can use the `-s` or `--server` flags to specify the address and port of the Kubernetes API server.<br/>
**Important**: Flags that you specify from the command line override default values and any corresponding environment variables.
{{< caution >}}
Flags that you specify from the command line override default values and any corresponding environment variables.
{{< /caution >}}
If you need help, just run `kubectl help` from the terminal window.
@@ -299,7 +302,7 @@ $ kubectl describe pods --include-uninitialized=false
```
{{< note >}}
**Note:** The `kubectl get` command is usually used for retrieving one or more
The `kubectl get` command is usually used for retrieving one or more
resources of the same resource type. It features a rich set of flags that allows
you to customize the output format using the `-o` or `--output` flag, for example.
You can specify the `-w` or `--watch` flag to start watching updates to a particular
@@ -145,7 +145,7 @@ You can install all the available addons with the `all` subcommand, or
install them selectively.
{{< note >}}
**Note:** If `kubeadm` is invoked with `--feature-gates=CoreDNS=false`, kube-dns is installed.
If `kubeadm` is invoked with `--feature-gates=CoreDNS=false`, kube-dns is installed.
{{< /note >}}
{{< tabs name="tab-addon" >}}
@@ -158,7 +158,7 @@ install them selectively.
## kubeadm alpha phase self-hosting {#cmd-phase-self-hosting}
{{< caution >}}
**Caution:** Self-hosting is an alpha feature. See [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) documentation for self-hosting limitations.
Self-hosting is an alpha feature. See [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/) documentation for self-hosting limitations.
{{< /caution >}}
{{< tabs name="tab-self-hosting" >}}
@@ -92,8 +92,7 @@ following steps:
### Using kubeadm init with a configuration file {#config-file}
{{< caution >}}
**Caution:** The config file is
still considered alpha and may change in future versions.
The config file is still considered alpha and may change in future versions.
{{< /caution >}}
It's possible to configure `kubeadm init` with a configuration file instead of command
@@ -284,14 +283,10 @@ configured in the kubelet via static files.
To create a self-hosted cluster, pass the flag `--feature-gates=SelfHosting=true` to `kubeadm init`.
{{< caution >}}
**Caution:** `SelfHosting` is an alpha feature. It is deprecated in 1.12
`SelfHosting` is an alpha feature. It is deprecated in 1.12
and will be removed in 1.13.
{{< /caution >}}
{{< warning >}}
**Warning:** See self-hosted caveats and limitations.
{{< /warning >}}
#### Caveats
Self-hosting in 1.8 has some important limitations. In particular, a
@@ -309,7 +304,7 @@ authorization configuration for your cluster, and may not be appropriate for
your environment.
{{< caution >}}
**Caution:** `StoreCertsInSecrets` is an alpha feature. It is deprecated in 1.12
`StoreCertsInSecrets` is an alpha feature. It is deprecated in 1.12
and will be removed in 1.13.
{{< /caution >}}
@@ -204,8 +204,7 @@ These commands should be run after `kubeadm init` but before `kubeadm join`.
### Using kubeadm join with a configuration file {#config-file}
{{< caution >}}
**Caution:** The config file is
still considered alpha and may change in future versions.
The config file is still considered alpha and may change in future versions.
{{< /caution >}}
It's possible to configure `kubeadm join` with a configuration file instead of command
@@ -40,7 +40,7 @@ The version is set at the API level rather than at the resource or field level t
The JSON and Protobuf serialization schemas follow the same guidelines for schema changes. The following descriptions cover both formats.
{{< note >}}
**Note:** The API versioning and software versioning are indirectly related. The [API and release
The API versioning and software versioning are indirectly related. The [API and release
versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) describes the relationship between API versioning and software versioning.
{{< /note >}}
@@ -64,7 +64,7 @@ Here's a summary of each level:
- The software is recommended for only non-business-critical uses because of potential for incompatible changes in subsequent releases. If you have multiple clusters which can be upgraded independently, you may be able to relax this restriction.
{{< note >}}
**Note:** Try the beta features and provide feedback. After the features exit beta, it may not be practical to make more changes.
Try the beta features and provide feedback. After the features exit beta, it may not be practical to make more changes.
{{< /note >}}
- Stable:
@@ -97,7 +97,7 @@ on the apiserver. `--runtime-config` accepts comma separated values. For example
The flag accepts comma separated set of key=value pairs describing runtime configuration of the apiserver.
{{< note >}}
**Note:** When you enable or disable groups or resources, you need to restart the apiserver and controller-manager
When you enable or disable groups or resources, you need to restart the apiserver and controller-manager
to pick up the `--runtime-config` changes.
{{< /note >}}
@@ -57,7 +57,7 @@ can not be removed from that version or have its behavior significantly
changed, regardless of track.
{{< note >}}
**Note:** For historical reasons, there are 2 "monolithic" API groups - "core" (no
For historical reasons, there are 2 "monolithic" API groups - "core" (no
group name) and "extensions". Resources will incrementally be moved from these
legacy API groups into more domain-specific API groups.
{{< /note >}}
@@ -90,7 +90,7 @@ no less than:**
This covers the maximum supported version skew of 2 releases.
{{< note >}}
**Note:** Until [#52185](https://github.com/kubernetes/kubernetes/issues/52185) is
Until [#52185](https://github.com/kubernetes/kubernetes/issues/52185) is
resolved, no API versions that have been persisted to storage may be removed.
Serving REST endpoints for those versions may be disabled (subject to the
deprecation timelines in this document), but the API server must remain capable