kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #6958 from dixudx/doc_admission_plugin_order 

fix admission plugins orders and update explanation
This commit is contained in:
Xiaoyu(Tim) Zhang 2018-01-16 13:40:47 +08:00 committed by GitHub
parent 00e62d4a18 6bdde193aa
commit b66117ce57
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
docs/admin/admission-controllers.md
View File

@ -546,14 +546,14 @@ Yes.
For Kubernetes >= 1.9.0, we strongly recommend running the following set of admission controllers (order matters):
```shell
--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,DefaultTolerationSeconds
--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota
```
It's worth reiterating that in 1.9 and up, these happen in a mutating phase
and a validating phase, and that e.g. `ResourceQuota` runs in the validating
phase, and therefore is the last admission controller to run.
`DefaultTolerationSeconds` and `MutatingAdmissionWebhook` appear after it in this
list, but they run in the mutating phase.
`MutatingAdmissionWebhook` appears before it in this list, because it runs
in the mutating phase.
For earlier versions, there was no concept of validating vs mutating and the
admission controllers ran in the exact order specified.