Kubernetes Admission Webhook在prometheus-operator中的使用

一 Admission Webhook概覽

Kubernetes Admission Webhook機制作爲API Server的擴展機制，可以用來靈活地在對API Server對象進行寫操作時實現對象統一修改和檢驗等功能，詳細的功能介紹可以參見官方文檔。當客戶端連接API Server更改對象時，會經過下圖所示的過程。

總得來說，有兩種Admission Webhook:

• Mutating Admission Webhook和
• Validating Admission Webhook。

在對象持久化進etcd之前，Mutating Admission Webhook被API Server首先調用用來對操作對象進行修改，然後再調用Validating Admission Webhook對對象進行合格性檢查，如果檢查通過則寫入etcd，否則拒絕更新操作。具體來說就是返回HTTP 422 Unprocessable Entity響應碼。

1.1 使用的注意事項

• 實現Webhook的服務（就是個HTTP接口）必須提供HTTPS接口
• API Server必須信任HTTPS的證書，可以讓自己的Webhook使用由Kubernetes簽發的證書來保證API Server信任證書
• 配置Webhook Configuration時，可以指定攔截的API對象類型已經namespace等，如：

apiVersion: admissionregistration.k8s.io/v1beta1
kind: MutatingWebhookConfiguration
metadata:
 name: prometheus-operator-rulesvalidation
webhooks:
- clientConfig:
     service:
       name: prometheus-operator
       namespace: openshift-metrics
       path: /admission-prometheusrules/mutate
       port: 8081
   failurePolicy: Fail
   name: prometheusrulemutate.monitoring.coreos.com
   namespaceSelector: 
     matchExpressions:
     - key: prometheus
       operator: In
       values: ["infra", "business"]   命名空間
   rules:
     - apiGroups:
         - monitoring.coreos.com
       apiVersions:
         - '*'
       operations:
         - CREATE
         - UPDATE   攔截操作
       resources:
         - prometheusrules  對象類型

二 prometheus-operator簡介

prometheus-operator支持用戶通過以下Custom Resource方便快鍵地在K8S集羣中快速創建監控和告警機制。

• 通過Custom Resource: Prometheus和AlertManager的實例用於監控和告警
• 通過PodMonitor，ServiceMonitor快速創建Prometheus採集數據的來源
• 通過PrometheusRule對象快速創建出Prometheus的Recording和Alerting規則
  更多的介紹可以參見prometheus-operator.

Prometheus-operator使用了Kubernetes的三大設計模式

• Operator模式擴展了上面列出的多種自定義對象（Custom Resource Definition機制），並根據這些對象定義快速創建監控和告警體系
• Controller模式：Operator裏的Controller通過Watch API Server中的對象變化做相應的配置更改
• Admission Webhook: 通過Webhook機制來對寫入的PrometheusRule對象進行語法檢驗

prometheus-operator的工作機制如下:

Prometheus-operator生成的Prometheus實例的POD會掛載一個規則配置的ConfigMap，所有PrometheusRule對象會被operator轉換成Prometheus規則後寫進這個ConfigMap，然後operator會通知Prometheus動態去加載新的配置（其中的具體細節，比如通過rules-configmap-reloader container來完成加載等等不再展開）。（上圖頂部的Prometheus Config其實是一個ConfigMap）

2.1 PrometheusRule

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  labels:
      prometheus: app
      role: alert-rules
  name: admission-webhook-test
spec:
  groups:
  - name: admission-webhook-test
    rules:
    - alert: rule-id-1
      annotations:
        description: '{{ $value }}% of {{ $labels.job }} targets are down.'
        summary: Targets are down 
      expr: up{test="nonexisting"} < 2
      for: 24s
      labels:
        level: P3

2.2 Config Map

上面的規則被掛載爲ConfigMap中一個key/value對。

2.3 Prometheus加載日誌

如果在Prometheus中出現上面的日誌，代表新的配置已經被加載成功。

三 Admission Webhook在prometheus-operator中的使用

編寫PrometheusRule對象時，不可避免有時會有一些語法錯誤。如果編寫的規則有錯，kubectl create -f rules.yml 會報告成功，但實際上在Prometheus加載ConfigMap時會報錯，但需要到後臺日誌或者Prometheus的rules菜單中查看才能發現新的錯誤規則遲遲未被加載。
比如下面這個規則，description的templating變量在.號前多了個空格，規則可以成功寫入Kubernetes API Server，

但是Prometheus後臺加載新規則時，會報以下錯誤

這種更新API Server Custom Resource對象成功但實際需要去關注後臺日誌才能知道是否最終成功的方式對管理人員非常不方便，所以這裏prometheus-operator自版本0.31後引入了通過Validating AdmissionWebhook機制來在更新PrometheusRule對象時同步進行規則檢驗，從而保證寫入API Server的對象肯定能被Prometheus正確加載。
可以通過創建以下對象啓用Admission Webhook，

apiVersion: admissionregistration.k8s.io/v1beta1
kind: ValidatingWebhookConfiguration
metadata:
  name: prometheus-operator-rulesvalidation
webhooks:
  - clientConfig:
      service:
        name: prometheus-operator
        namespace: metrics
        path: /admission-prometheusrules/validate
    failurePolicy: Fail
    name: prometheusrulevalidate.monitoring.coreos.com
    namespaceSelector:
      matchExpressions:
      - key: prometheus
        operator: In
        values: ["infra", "business"]
    rules:
      - apiGroups:
          - monitoring.coreos.com
        apiVersions:
          - '*'
        operations:
          - CREATE
          - UPDATE
        resources:
          - prometheusrules

apiVersion: admissionregistration.k8s.io/v1beta1
kind: MutatingWebhookConfiguration
metadata:
  name: prometheus-operator-rulesvalidation
webhooks:
  - clientConfig:
      service:
        name: prometheus-operator
        namespace: metrics
        path: /admission-prometheusrules/mutate
        port: 8081
    failurePolicy: Fail
    name: prometheusrulemutate.monitoring.coreos.com
    namespaceSelector:
      matchExpressions:
      - key: prometheus
        operator: In
        values: ["infra", "business"]
    rules:
      - apiGroups:
          - monitoring.coreos.com
        apiVersions:
          - '*'
        operations:
          - CREATE
          - UPDATE
        resources:
          - prometheusrules

其中Mutating WebHook是在驗證通過的PrometheusRule對象上加入驗證通過的annotation，

加入以上WebHook後，如果一旦插入的規則有誤，則會收到API Server的以下422響應。

< HTTP/2 422 
< cache-control: no-store
< content-type: application/json
< content-length: 490
< date: Sat, 21 Dec 2019 02:10:11 GMT
< 
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {
    
  },
  "status": "Failure",
  "message": "admission webhook \"prometheusrulemutate.monitoring.coreos.com\" denied the request: Rules are not valid",
  "reason": "Invalid",
  "details": {
    "name": "prometheusrules",
    "causes": [
      {
        "message": "group \"admission-webhook-test\", rule 0, \"rule-id-1\": msg=template: __alert_rule-id-1:1: unexpected \u003c.\u003e in operand"
      }
    ]
  },
  "code": 422
}

而這些Webhook都是回調prometheus-operator的以下HTTP接口

/admission-prometheusrules/validate
 /admission-prometheusrules/mutate

這些接口的實現都比較簡單，見源碼

以上即爲Admission Webhook這種設計模式在prometheus-operator中的使用方式。