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鉤子服務器來處理這些認證.