From 6bdde193aa75f2fd1a9d8ea5cb7a0c353cb90246 Mon Sep 17 00:00:00 2001 From: Di Xu Date: Sun, 14 Jan 2018 17:21:09 +0800 Subject: [PATCH] fix admission plugins orders and update explanation --- docs/admin/admission-controllers.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/admin/admission-controllers.md b/docs/admin/admission-controllers.md index 2d5369469a..6250aa5543 100644 --- a/docs/admin/admission-controllers.md +++ b/docs/admin/admission-controllers.md @@ -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.