admission-control flag replaced by enable/disable-admission-plugins flags

docs/admin/admission-controllers.md

@@ -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.
@@ -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
@@ -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)
@@ -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
@@ -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
 
@@ -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.
@@ -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
 
@@ -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

docs/admin/authorization/node.md

@@ -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
 

docs/admin/extensible-admission-controllers.md

@@ -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.
 
@@ -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.
 
@@ -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.
 
@@ -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.

docs/admin/high-availability/kube-apiserver.yaml

@@ -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

docs/concepts/configuration/pod-priority-preemption.md

@@ -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)

docs/concepts/policy/resource-quotas.md

@@ -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

docs/concepts/storage/persistent-volumes.md

@@ -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.
 

docs/concepts/workloads/pods/podpreset.md

@@ -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.

docs/getting-started-guides/coreos/cloud-configs/master.yaml

@@ -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 \

docs/getting-started-guides/scratch.md

@@ -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.
 

docs/reference/setup-tools/kubeadm/implementation-details.md

@@ -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

docs/tasks/administer-cluster/running-cloud-controller.md

@@ -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" %}

docs/tasks/federation/set-up-placement-policies-federation.md

@@ -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:

docs/tutorials/clusters/apparmor.md

@@ -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: