Skip to content

Commit

Permalink
Flag names changed (s/admission-control/enable-admission-plugins); di…
Browse files Browse the repository at this point in the history
…sable-admissions-plugin entry added; removed reference to admission controller/plugins requiring set order (for v1.10), redundant example enabling specific plugin, and redundant version-specific info (#7449)
  • Loading branch information
aburdenthehand authored and k8s-ci-robot committed Mar 8, 2018
1 parent 44b51d6 commit d634fb7
Show file tree
Hide file tree
Showing 14 changed files with 35 additions and 36 deletions.
35 changes: 17 additions & 18 deletions docs/admin/admission-controllers.md
Original file line number Diff line number Diff line change
Expand Up @@ -31,8 +31,7 @@ controllers may modify the objects they admit; validating controllers may not.
The admission control process proceeds in two phases. In the first phase,
mutating admission controllers are run. In the second phase, validating
admission controllers are run. Note again that some of the controllers are
both. In both phases, the controllers are run in the order specified by the
`--admission-control` flag of `kube-apiserver`.
both.

If any of the controllers in either phase reject the request, the entire
request is rejected immediately and an error is returned to the end-user.
Expand All @@ -54,13 +53,12 @@ support all the features you expect.

## How do I turn on an admission controller?

The Kubernetes API server supports a flag, `admission-control` that takes a comma-delimited,
ordered list of admission control choices to invoke prior to modifying objects in the cluster.
For example, the following command line turns on the `NamespaceLifecycle` and the `LimitRanger`
admission controller:
The Kubernetes API server flag `enable-admission-plugins` takes a comma-delimited list of admission control plugins to invoke prior to modifying objects in the cluster.
For example, the following command line enables the `NamespaceLifecycle` and the `LimitRanger`
admission control plugins:

```shell
kube-apiserver --admission-control=NamespaceLifecyle,LimitRanger ...
kube-apiserver --enable-admission-plugins=NamespaceLifecyle,LimitRanger ...
```

**Note**: Depending on the way your Kubernetes cluster is deployed and how the
Expand All @@ -70,6 +68,14 @@ 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?

The Kubernetes API server flag `disable-admission-plugins` takes a comma-delimited list of admission control plugins to be disabled, even if they are in the list of plugins enabled by default.

```shell
kube-apiserver --disable-admission-plugins=PodNodeSelector,AlwaysDeny ...
```

## What does each admission controller do?

### AlwaysAdmit (DEPRECATED)
Expand Down Expand Up @@ -134,7 +140,7 @@ enabling this admission controller.

### EventRateLimit (alpha)

This admission controller is introduced in v1.9 to mitigate the problem where the API server gets flooded by
This admission controller mitigates the problem where the API server gets flooded by
event requests. The cluster admin can specify event rate limits by:

* Ensuring that `eventratelimit.admission.k8s.io/v1alpha1=true` is included in the
Expand Down Expand Up @@ -180,19 +186,15 @@ for more details.
### ExtendedResourceToleration
This plug-in is introduced in v1.9 to facilitate creation of dedicated nodes with extended resources.
This plug-in facilitates creation of dedicated nodes with extended resources.
If operators want to create dedicated nodes with extended resources (like GPUs, FPGAs etc.), they are expected to
taint the node with the extended resource name as the key. This admission controller, if enabled, automatically
adds tolerations for such taints to pods requesting extended resources, so users don't have to manually
add these tolerations.
### ImagePolicyWebhook
The ImagePolicyWebhook admission controller allows a backend webhook to make admission decisions. You enable this admission controller by setting the admission-control option as follows:
```shell
--admission-control=ImagePolicyWebhook
```
The ImagePolicyWebhook admission controller allows a backend webhook to make admission decisions.
#### Configuration File Format
Expand Down Expand Up @@ -314,7 +316,6 @@ In any case, the annotations are provided by the user and are not validated by K

### Initializers (alpha)

This admission controller is introduced in v1.7.
The admission controller determines the initializers of a resource based on the existing
`InitializerConfiguration`s. It sets the pending initializers by modifying the
metadata of the resource to be created.
Expand Down Expand Up @@ -554,8 +555,6 @@ objects in your Kubernetes deployment, you MUST use this admission controller to

See the [resourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) and the [example of Resource Quota](/docs/concepts/policy/resource-quotas/) for more details.

It is strongly encouraged that this admission controller is configured last in the sequence of admission controllers. This is
so that quota is not prematurely incremented only for the request to be rejected later in admission control.

### SecurityContextDeny

Expand Down Expand Up @@ -590,7 +589,7 @@ versions >= 1.9).
## Is there a recommended set of admission controllers to use?

Yes.
For Kubernetes >= 1.9.0, we strongly recommend running the following set of admission controllers (order matters):
For Kubernetes >= 1.9.0, we strongly recommend running the following set of admission controllers (order matters for 1.9 but not >1.10):

```shell
--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota
Expand Down
2 changes: 1 addition & 1 deletion docs/admin/authorization/node.md
Original file line number Diff line number Diff line change
Expand Up @@ -45,7 +45,7 @@ This group and user name format match the identity created for each kubelet as p

To enable the Node authorizer, start the apiserver with `--authorization-mode=Node`.

To limit the API objects kubelets are able to write, enable the [NodeRestriction](/docs/admin/admission-controllers#NodeRestriction) admission plugin by starting the apiserver with `--admission-control=...,NodeRestriction,...`
To limit the API objects kubelets are able to write, enable the [NodeRestriction](/docs/admin/admission-controllers#NodeRestriction) admission plugin by starting the apiserver with `--enable-admission-plugins=...,NodeRestriction,...`

## Migration considerations

Expand Down
8 changes: 4 additions & 4 deletions docs/admin/extensible-admission-controllers.md
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,7 @@ the following:
* They need to be compiled into kube-apiserver.
* They are only configurable when the apiserver starts up.

1.7 introduces two alpha features, *Initializers* and *External Admission
1.7 introduced two alpha features, *Initializers* and *External Admission
Webhooks*, that address these limitations. These features allow admission
controllers to be developed out-of-tree and configured at runtime.

Expand Down Expand Up @@ -81,7 +81,7 @@ perform its assigned task and remove its name from the list.
*Initializers* is an alpha feature, so it is disabled by default. To turn it on,
you need to:

* Include "Initializers" in the `--admission-control` flag when starting
* Include "Initializers" in the `--enable-admission-plugins` flag when starting
`kube-apiserver`. If you have multiple `kube-apiserver` replicas, all should
have the same flag setting.

Expand Down Expand Up @@ -184,7 +184,7 @@ admission request.
*External Admission Webhooks* is an alpha feature, so it is disabled by default.
To turn it on, you need to

* Include "GenericAdmissionWebhook" in the `--admission-control` flag when
* Include "GenericAdmissionWebhook" in the `--enable-admission-plugins` flag when
starting the apiserver. If you have multiple `kube-apiserver` replicas, all
should have the same flag setting.

Expand Down Expand Up @@ -278,7 +278,7 @@ differences:
Make sure that all expansions of the `<apiGroup, apiVersions,resources>` tuple
in a `rule` are valid. If they are not, separate them to different `rules`.

You can also specify the `failurePolicy`. In 1.7, the system supports `Ignore`
You can also specify the `failurePolicy`. As of 1.7, the system supports `Ignore`
and `Fail` policies, meaning that upon a communication error with the webhook
admission controller, the `GenericAdmissionWebhook` can admit or reject the
operation based on the configured policy.
Expand Down
2 changes: 1 addition & 1 deletion docs/admin/high-availability/kube-apiserver.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ spec:
- /bin/sh
- -c
- /usr/local/bin/kube-apiserver --address=127.0.0.1 --etcd-servers=http://127.0.0.1:4001
--cloud-provider=gce --admission-control=NamespaceLifecycle,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota
--cloud-provider=gce --enable-admission-plugins=NamespaceLifecycle,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota
--service-cluster-ip-range=10.0.0.0/16 --client-ca-file=/srv/kubernetes/ca.crt
--basic-auth-file=/srv/kubernetes/basic_auth.csv --cluster-name=e2e-test-bburns
--tls-cert-file=/srv/kubernetes/server.cert --tls-private-key-file=/srv/kubernetes/server.key
Expand Down
2 changes: 1 addition & 1 deletion docs/concepts/configuration/pod-priority-preemption.md
Original file line number Diff line number Diff line change
Expand Up @@ -45,7 +45,7 @@ Also enable scheduling.k8s.io/v1alpha1 API and Priority [admission controller](/


```
--runtime-config=scheduling.k8s.io/v1alpha1=true --admission-control=Controller-Foo,Controller-Bar,...,Priority
--runtime-config=scheduling.k8s.io/v1alpha1=true --enable-admission-plugins=Controller-Foo,Controller-Bar,...,Priority
```

After the feature is enabled, you can create [PriorityClasses](#priorityclass)
Expand Down
4 changes: 2 additions & 2 deletions docs/concepts/policy/resource-quotas.md
Original file line number Diff line number Diff line change
Expand Up @@ -42,8 +42,8 @@ Neither contention nor changes to quota will affect already created resources.

## Enabling Resource Quota

Resource quota support is enabled by default for many Kubernetes distributions. It is
enabled when the apiserver `--admission-control=` flag has `ResourceQuota` as
Resource Quota support is enabled by default for many Kubernetes distributions. It is
enabled when the apiserver `--enable-admission-plugins=` flag has `ResourceQuota` as
one of its arguments.

A resource quota is enforced in a particular namespace when there is a
Expand Down
2 changes: 1 addition & 1 deletion docs/concepts/storage/persistent-volumes.md
Original file line number Diff line number Diff line change
Expand Up @@ -54,7 +54,7 @@ dynamic provisioning for themselves.
To enable dynamic storage provisioning based on storage class, the cluster administrator
needs to enable the `DefaultStorageClass` [admission controller](/docs/admin/admission-controllers/#defaultstorageclass)
on the API server. This can be done, for example, by ensuring that `DefaultStorageClass` is
among the comma-delimited, ordered list of values for the `--admission-control` flag of
among the comma-delimited, ordered list of values for the `--enable-admission-plugins` flag of
the API server component. For more information on API server command line flags,
please check [kube-apiserver](/docs/admin/kube-apiserver/) documentation.

Expand Down
2 changes: 1 addition & 1 deletion docs/concepts/workloads/pods/podpreset.md
Original file line number Diff line number Diff line change
Expand Up @@ -68,7 +68,7 @@ In order to use Pod Presets in your cluster you must ensure the following:
example, this can be done by including `settings.k8s.io/v1alpha1=true` in
the `--runtime-config` option for the API server.
1. You have enabled the admission controller `PodPreset`. One way to doing this
is to include `PodPreset` in the `--admission-control` option value specified
is to include `PodPreset` in the `--enable-admission-plugins` option value specified
for the API server.
1. You have defined your Pod Presets by creating `PodPreset` objects in the
namespace you will use.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -91,7 +91,7 @@ coreos:
ExecStart=/opt/bin/kube-apiserver \
--service-account-key-file=/opt/bin/kube-serviceaccount.key \
--service-account-lookup=false \
--admission-control=NamespaceLifecycle,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota \
--enable-admission-plugins=NamespaceLifecycle,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota \
--runtime-config=api/v1 \
--allow-privileged=true \
--insecure-bind-address=0.0.0.0 \
Expand Down
2 changes: 1 addition & 1 deletion docs/getting-started-guides/scratch.md
Original file line number Diff line number Diff line change
Expand Up @@ -607,7 +607,7 @@ Here are some apiserver flags you may need to set:
- `--etcd-servers=http://127.0.0.1:4001`
- `--tls-cert-file=/srv/kubernetes/server.cert`
- `--tls-private-key-file=/srv/kubernetes/server.key`
- `--admission-control=$RECOMMENDED_LIST`
- `--enable-admission-plugins=$RECOMMENDED_LIST`
- See [admission controllers](/docs/admin/admission-controllers/) for recommended arguments.
- `--allow-privileged=true`, only if you trust your cluster user to run pods as root.

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -233,7 +233,7 @@ Other API server flags that are set unconditionally are:
- `--enable-bootstrap-token-auth=true` to enable the `BootstrapTokenAuthenticator` authentication module. see [TLS Bootstrapping](/docs/admin/kubelet-tls-bootstrapping.md) for more details
- `--allow-privileged` to `true` (required e.g. by kube proxy)
- `--requestheader-client-ca-file` to `front-proxy-ca.crt`
- `--admission-control` to:
- `--enable-admission-plugins` to:
- [`Initializers`](/docs/admin/admission-controllers/#initializers-alpha) to enable [Dynamic Admission Control](/docs/admin/extensible-admission-controllers/).
- [`NamespaceLifecycle`](/docs/admin/admission-controllers/#namespacelifecycle) e.g. to avoid deletion of
system reserved namespaces
Expand Down
2 changes: 1 addition & 1 deletion docs/tasks/administer-cluster/running-cloud-controller.md
Original file line number Diff line number Diff line change
Expand Up @@ -33,7 +33,7 @@ Successfully running cloud-controller-manager requires some changes to your clus

* `kube-apiserver` and `kube-controller-manager` MUST NOT specify the `--cloud-provider` flag. This ensures that it does not run any cloud specific loops that would be run by cloud controller manager. In the future, this flag will be deprecated and removed.
* `kubelet` must run with `--cloud-provider=external`. This is to ensure that the kubelet is aware that it must be initialized by the cloud controller manager before it is scheduled any work.
* `kube-apiserver` SHOULD NOT run the `PersistentVolumeLabel` admission controller since the cloud controller manager takes over labeling persistent volumes. To prevent the PersistentVolumeLabel admission plugin from running, make sure the `kube-apiserver` has a `--admission-control` flag with a value that does not include `PersistentVolumeLabel`.
* `kube-apiserver` SHOULD NOT run the `PersistentVolumeLabel` admission controller since the cloud controller manager takes over labeling persistent volumes. To prevent the PersistentVolumeLabel admission plugin from running in `kube-apiserver`, include the `PersistentVolumeLabel` as a listed value in the `--disable-admission-plugins` flag.
* For the `cloud-controller-manager` to label persistent volumes, initializers will need to be enabled and an InitializerConifguration needs to be added to the system. Follow [these instructions](/docs/admin/extensible-admission-controllers.md#enable-initializers-alpha-feature) to enable initializers. Use the following YAML to create the InitializerConfiguration:

{% include code.html language="yaml" file="persistent-volume-label-initializer-config.yaml" ghlink="/docs/tasks/administer-cluster/persistent-volume-label-initializer-config.yaml" %}
Expand Down
4 changes: 2 additions & 2 deletions docs/tasks/federation/set-up-placement-policies-federation.md
Original file line number Diff line number Diff line change
Expand Up @@ -51,10 +51,10 @@ Admission Controller.

Update the Federation API server command line arguments to enable the Admission
Controller and mount the ConfigMap into the container. If there's an existing
`--admission-control` flag, append `,SchedulingPolicy` instead of adding
`--enable-admission-plugins` flag, append `,SchedulingPolicy` instead of adding
another line.

--admission-control=SchedulingPolicy
--enable-admission-plugins=SchedulingPolicy
--admission-control-config-file=/etc/kubernetes/admission/config.yml

Add the following volume to the Federation API server pod:
Expand Down
2 changes: 1 addition & 1 deletion docs/tutorials/clusters/apparmor.md
Original file line number Diff line number Diff line change
Expand Up @@ -320,7 +320,7 @@ If the PodSecurityPolicy extension is enabled, cluster-wide AppArmor restriction
enable the PodSecurityPolicy, the following flag must be set on the `apiserver`:
```
--admission-control=PodSecurityPolicy[,others...]
--enable-admission-plugins=PodSecurityPolicy[,others...]
```
The AppArmor options can be specified as annotations on the PodSecurityPolicy:
Expand Down

0 comments on commit d634fb7

Please sign in to comment.