kubernetes高級之動態准入控制

系列目錄

動態准入控制器文檔介紹了如何使用標準的,插件式的准入控制器.但是,但是由於以下原因,插件式的准入控制器在一些場景下並不靈活:

它們需要編譯到kube-apiserver里

它們僅在apiserver啟動的時候可以配置

准入鈎子(Admission Webhooks 從1.9版本開始)解決了這些問題,它允許准入控制器獨立於核心代碼編譯並且可以在運行時配置.

什麼是准入鈎子

准入鈎子是一種http回調,它接收准入請求然後做一些處理.你可以定義兩種類型的准入鈎子:驗證鈎子和變換鈎子.對於驗證鈎子,你可以拒絕請求以使自定義准入策略生效.對於變換鈎子,你可以改變請求來使自定義的默認配置生效.

體驗准入鈎子

准入控制鈎子是集群管制面板不可缺少的一部分.你在編寫部署它們時必須要警惕.如果你想要編寫/布置生產級別的准入控制器,請閱讀以下用戶指南.下面我們將介紹如何快速體驗准入鈎子.

準備工作:

確保你的kubernetes集群版本至少是1.9版本.

確保變換鈎子(MutatingAdmissionWebhook) 和驗證鈎子(ValidatingAdmissionWebhook)已經啟用.這裡是推薦開啟的一組准入控制器.

編寫一個准入鈎子服務器(admission webhook server)

請參閱已經被kubernetes e2e測試驗證通過的准入服務器鈎子( admission webhook server)的實現.這個web鈎子處理apiserver發出的admissionReview請求,然後把結果封裝成一個admissionResponse返回給請求者.

admissionReview請求可能有多個版本( v1beta1 或者未來的v1),web鈎子可以通過admissionReviewVersions字段來定義它們接受的版本.apiserver會嘗試使用列表中出現的,支持的第一個版本.如果列表中的版本沒有一個是被支持的,驗證將失敗.如果webhook配置已經持久化,對web鈎子的請求將會失敗並被失敗策略控制.

示例鈎子服務器(admission webhook server)把ClientAuth字段留空,默認為NoClientCert.這意味着鈎子服務器不驗證客戶端身份.如果你需要使用mutual TLS或者其它方法來驗證客戶端請求,請參考如何認證apiserver

部署准入控制服務

e2e測試的鈎子服務器通過部署api(https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.14/#deployment-v1beta1-apps)被部署到kubernetes集群中.測試項目也為鈎子服務器創建了一個前端服務,代碼

你也可以把你的鈎子服務部署到集群外,你需要相應地更新web鈎子客戶端配置

運行時配置准入web鈎子

你可以通過ValidatingWebhookConfiguration和MutatingWebhookConfiguration動態地配置哪些資源被哪些web鈎子控制.

以下是一個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
     scope: "Namespaced"
   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>
   admissionReviewVersions:
   - v1beta1
   timeoutSeconds: 1

scope字段指定了集群級別的資源("Cluster")或者名稱空間級別的資源("Namespaced")需要匹配這些規則."*"表示沒有任何範圍限制.

注意,如果使用clientConfig.service,服務端證書必須對<svc_name>.<svc_namespace>.svc有效.

web鈎子請求默認超時時間為30秒,但是從1.14版本開始,你可以自由設置超時時間但是建議設置較小的時間.如果web鈎子請求超時,請求將被web鈎子的失敗策略處理.

當apiserver接收到一個匹配規則的請求,apiserver將會發送一個admissionReview請求到clientConfig配置的web鈎子里.

創建web鈎子配置以後,系統將會經過一段時間使新配置生效.

認證apiserver

如果你的准入web鈎子需要認證,你可以配置apiserver使用基本認證(basic auth), bearer token 或者證書認證.需要三個步驟來完成認證配置.

當啟動apiserver時,通過--admission-control-config-file選項來指定準入控制配置文件的位置.

在准入控制配置文件里,指定變換控制器(MutatingAdmissionWebhook)和驗證控制器(ValidatingAdmissionWebhook)從哪裡讀取證書.證書存儲在kubeConfig文件里(和kubectl使用的相同),字段名為kubeConfigFile.下面是准入控制配置文件示例

apiVersion: apiserver.k8s.io/v1alpha1
 kind: AdmissionConfiguration
 plugins:
 - name: ValidatingAdmissionWebhook
   configuration:
     apiVersion: apiserver.config.k8s.io/v1alpha1
     kind: WebhookAdmission
     kubeConfigFile: <path-to-kubeconfig-file>
 - name: MutatingAdmissionWebhook
   configuration:
     apiVersion: apiserver.config.k8s.io/v1alpha1
     kind: WebhookAdmission
     kubeConfigFile: <path-to-kubeconfig-file>

這裡是admissionConfiguration的schema定義

在kubeConfig文件里,提供證書

apiVersion: v1
 kind: Config
 users:
 # DNS name of webhook service, i.e., <service name>.<namespace>.svc, or the URL
 # of the webhook server.
 - name: 'webhook1.ns1.svc'
   user:
     client-certificate-data: <pem encoded certificate>
     client-key-data: <pem encoded key>
 # The `name` supports using * to wildmatch prefixing segments.
 - name: '*.webhook-company.org'
   user:
     password: <password>
     username: <name>
 # '*' is the default match.
 - name: '*'
   user:
     token: <token>

當然,你需要設置web鈎子服務器來處理這些認證.

【精選推薦文章】

自行創業缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!

評比前十大台北網頁設計、台北網站設計公司知名案例作品心得分享

台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

Orignal From: kubernetes高級之動態准入控制

網路資訊

搜尋此網誌