(Proudly powered by QKQ)
Kubernetes中的Admission Controller是做什么的呢?有什么用呢?怎么自己定義一個(gè)呢?
Q: 什么是Admission Controller?
A: 官方定義:
An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized.
我理解的:
- Admission Controller是一個(gè)攔截器
- 攔截發(fā)送給Kuberenetes API Server的請求
- 什么時(shí)候攔截?在請求通過認(rèn)證之后,請求被存儲起來之前
所以順理成章,由于攔截的是發(fā)送給API Server的請求,所以Admission Controller存在于API Server內(nèi)部,即compiled into the kube-apiserver binary(被編譯進(jìn)API Server的可執(zhí)行文件里)。
kubernetes將AC分為三種:
- validating,驗(yàn)證型。用于驗(yàn)證k8s的資源定義是否符合規(guī)則
- mutating,修改型。用于修改k8s的資源定義,比如加個(gè)label什么的
- 二者皆是,即同一個(gè)AC,既是驗(yàn)證型又是修改型
多個(gè)Admission Controller會形成一個(gè)Admission Chain(鏈條),修改型的在前面先執(zhí)行,驗(yàn)證型的在后面后執(zhí)行,這樣驗(yàn)證型的才能去驗(yàn)證修改的對不對。
K: interceptor, validating, mutating, Admission Chain
Q: Admission Controller有什么用?
A: API Server內(nèi)置了一些AC,有各種各樣的作用[1]。比如:
- EventRateLimit,用于限制事件的頻率
- LimitRanger,驗(yàn)證所有的請求都沒有超出namespace中定義的LimitRange
還有很多其他AC,具體請參考Kubernetes文檔。
這些AC中,有兩個(gè)對用戶來說比較有用:
- MutatingAdmissionWebhook,這是一個(gè)webhook,即網(wǎng)絡(luò)鉤子,也就是說該AC會去請求服務(wù)端,并執(zhí)行相應(yīng)的邏輯
- ValidatingAdmissionWebhook,也是一個(gè)webhook,只是用于驗(yàn)證
Q: 怎么查看哪些AC是打開了的?
A: 文檔上寫的用:kube-apiserver -h | grep enable-admission-plugins。但是由于本地是minikube,進(jìn)入虛擬機(jī)之后并沒有發(fā)現(xiàn)kube-apiserver命令。
后來發(fā)現(xiàn)api-server是以pod的形式運(yùn)行的:
kubectl get pods -n kube-system
于是,使用kubectl exec登入pod,然后調(diào)用上述的指令,其結(jié)果為:
/ # kube-apiserver -h | grep enable-admission-plugins
--admission-control strings Admission is divided into two phases. In the first phase, only mutating admission plugins run. In the second phase, only validating admission plugins run. The names in the below list may represent a validating plugin, a mutating plugin, or both. The order of plugins in which they are passed to this flag does not matter. Comma-delimited list of: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, DefaultStorageClass, DefaultTolerationSeconds, DenyEscalatingExec, DenyExecOnPrivileged, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, Initializers, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodPreset, PodSecurityPolicy, PodTolerationRestriction, Priority, ResourceQuota, SecurityContextDeny, ServiceAccount, StorageObjectInUseProtection, ValidatingAdmissionWebhook. (DEPRECATED: Use --enable-admission-plugins or --disable-admission-plugins instead. Will be removed in a future version.)
--enable-admission-plugins strings admission plugins that should be enabled in addition to default enabled ones (NamespaceLifecycle, LimitRanger, ServiceAccount, Priority, DefaultTolerationSeconds, DefaultStorageClass, PersistentVolumeClaimResize, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota). Comma-delimited list of admission plugins: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, DefaultStorageClass, DefaultTolerationSeconds, DenyEscalatingExec, DenyExecOnPrivileged, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, Initializers, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodPreset, PodSecurityPolicy, PodTolerationRestriction, Priority, ResourceQuota, SecurityContextDeny, ServiceAccount, StorageObjectInUseProtection, ValidatingAdmissionWebhook. The order of plugins in this flag does not matter.
Q: Admission webhook是啥?
A: 官方定義:
Admission webhooks are HTTP callbacks that receive admission requests and do something with them.
簡單來說webhook就是一個(gè)HTTP回調(diào),接收admission請求,處理并返回。
用戶可以定義兩種webhook:
- validating admission webhook
- mutating admission webhook
一個(gè)用于驗(yàn)證,另一個(gè)用于修改。
webhook回調(diào),接收API Server發(fā)送的admissionReview請求,并返回 admissionResponse。
K: 回調(diào),admissionReview請求,admissionResponse返回。
Q: 如何配置和查看WebhookConfiguration?
A: 以Validating為例,查看:
kubectl get ValidatingWebhookConfiguration
ValidatingWebhookConfiguration的資源定義:
apiVersion: admissionregistration.k8s.io/v1beta1
kind: ValidatingWebhookConfiguration
metadata:
name: <name of this configuration object>
webhooks:
- name: <webhook name, e.g., pod-policy.example.io>
rules:
- apiGroups:
- ""
apiVersions:
- v1
operations:
- CREATE
resources:
- pods
clientConfig:
service:
namespace: <namespace of the front-end service>
name: <name of the front-end service>
caBundle: <pem encoded ca cert that signs the server cert used by the webhook>
其中rules定義了匹配規(guī)則,當(dāng)發(fā)給API Server的請求滿足該規(guī)則的時(shí)候,API Server就會給clientConfig中配置的service發(fā)送Admission請求。
使用webhook有什么要求?
A: 幾點(diǎn):
- kubernetes版本最低是v1.9
- api server使能(enable)了MutatingAdmissionWebhook和ValidatingAdmissionWebhook
- admissionregistration.k8s.io/v1beta1 API處于enable狀態(tài),即使用
kubectl api-versions | grep admissionregistration.k8s.io/v1beta1
Q: 如何自己寫一個(gè)webhook?
A: 需要完成幾個(gè)事情:
- 創(chuàng)建TLS Certificate,即證書
- 編寫服務(wù)端代碼,服務(wù)端代碼需要使用證書
- 根據(jù)證書創(chuàng)建k8s sercret
- 創(chuàng)建k8s Deployment和Service
- 創(chuàng)建k8s WebhookConfiguration,其中需要使用之前創(chuàng)建的證書
具體代碼和流程參見[3][4]
參考文獻(xiàn):
[1] https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/
[2] https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks
[3] https://banzaicloud.com/blog/k8s-admission-webhooks/
[4] https://github.com/morvencao/kube-mutating-webhook-tutorial
[5] https://github.com/banzaicloud/admission-webhook-example