Admission Webhook

Admission Webhook 是 api-server 对外提供的一个扩展能力，api-server 作为 kubernetes 的核心，几乎所有组件都需要跟他打交道，基本可以说掌控了 k8s 的 api-server，你就可以控制 k8s 的行为。

在早期的版本 api-server 并没有提供 admissionresgistration 的能力（v1.9之前），当我们要对 k8s 进行控制的时候，只能重新编译 api-server。比如你想阻止某个控制器的行为，或拦截某个控制器的资源修改。admission webhook 就是提供了这样的能力，比如你希望某个特定 label 标签的 pod 再创建的时候都注入 sidercar，或者阻止不合规的资源。

CRD解析

Admission Webhook 包涵两种 CRD：mutatingwebhookconfiguration 和 validatingwebhookconfiguration。

下面是一个 mutatingwebhookconfiguration 的CRD文件：

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  name: mutating-test.shikanon.com
webhooks:
- admissionReviewVersions: # admissionReviewVersions 请求的版本
  - v1beta1
  - v1
  clientConfig: # 客户端配置
    caBundle: # ca证书
    service: # 调用服务相关配置，这里是一个k8s的service，访问地址是<name>.<namespace>.svc:<port>/<path>
      name: mutating-test 
      namespace: testing-tools
      path: /mutation-deployment
      port: 8000
  failurePolicy: Ignore # 调用失败策略，Ignore为忽略错误, failed表示admission会处理错误
  matchPolicy: Exact
  name: mutating-test.shikanon.com # webhook名称
  namespaceSelector: {} # 命名空间过滤条件
  objectSelector: # 对象过滤条件
    matchExpressions:
    - key: mutating-test-webhook
      operator: In
      values:
      - enabled
      - "true"
  # reinvocationPolicy表示再调度策略，因为webhook本身没有顺序性，因此每个修改后可能又被其他webhook修改，所以提供
  # 一个策略表示是否需要被多次调用，Never 表示只会调度一次，IfNeeded 表示资源被修改后会再调度这个webhook
  reinvocationPolicy: Never 
  rules: # 规则
  - apiGroups:
    - apps
    apiVersions:
    - v1
    operations:
    - CREATE
    - UPDATE
    resources:
    - deployments
    scope: '*' # 匹配范围，"*" 匹配所有资源，但不包括子资源，"*/*" 匹配所有资源，包括子资源
  sideEffects: None # 这个表示webhook是否存在副作用，主要针对 dryRun 的请求
  timeoutSeconds: 30

Webhook 的流程和格式

Admission Webhook 本质是 api-server 的一个 webhook 调用，下面是 api-server 的处理流程：

image.png

api-server 通过读取 mutatingwebhookconfiguration 和 validatingwebhookconfiguration 的 CR 文件的目标地址，然后回调用户自定义的服务。

                                            ┌──────────────────────────────────┐
             ┌─────────────────┐            │                                  │
    apply    │                 │    read    │  validatingwebhookconfiguration  │
────────────►│    api-server   │◄───────────┤                                  │
             │                 │            │  mutatingwebhookconfiguration    │
             └────────┬────────┘            │                                  │
                      │                     └──────────────────────────────────┘
                      │
                      │  回调
                      │
                      │
             ┌────────▼────────┐
             │                 │
             │  webhookservice │
             │                 │
             └─────────────────┘

api-server 发起的请求是一串json数据格式，header需要设置content-type为application/json, 我们看看请求的 body :

curl -X POST \
  http://webhook-url \
  -H 'content-type: application/json' \
  -d '{
  "apiVersion": "admission.k8s.io/v1",
  "kind": "AdmissionReview",
  "request": {
    ...
  }
}'

返回的结果：

{
    "kind": "AdmissionReview",
    "apiVersion": "admission.k8s.io/v1",
    "response": {
        "uid": "b955fb34-0135-4e78-908e-eeb2f874933f",
        "allowed": true,
        "status": {
            "metadata": {},
            "code": 200
        },
        "patch": "W3sib3AiOiJyZXBsYWNlIiwicGF0aCI6Ii9zcGVjL3JlcGxpY2FzIiwidmFsdWUiOjJ9XQ==",
        "patchType": "JSONPatch"
    }
}

这里的 patch 是用base64编码的一个json，我们解码看看，是一个 json patch：

$ echo "W3sib3AiOiJyZXBsYWNlIiwicGF0aCI6Ii9zcGVjL3JlcGxpY2FzIiwidmFsdWUiOjJ9XQ==" | base64 -d
[
    {
        "op": "replace",
        "path": "/spec/replicas",
        "value": 2
    }
]

编写Admission Webhook服务

处理函数：

func (h *MutatingHandler) Handle(ctx context.Context, req kubeadmission.Request) kubeadmission.Response {
    reqJson, err := json.Marshal(req.AdmissionRequest)
    if err != nil {
        return kubeadmission.Errored(http.StatusBadRequest, err)
    }
    fmt.Println(string(reqJson))
    obj := &appsv1.Deployment{}

    err = h.Decoder.Decode(req, obj)
    if err != nil {
        return kubeadmission.Errored(http.StatusBadRequest, err)
    }
    fmt.Println(obj.Name)
    originObj, err := json.Marshal(obj)
    if err != nil {
        return kubeadmission.Errored(http.StatusBadRequest, err)
    }
  // 将新的资源副本数量改为1
    newobj := obj.DeepCopy()
    replicas := int32(1)
    newobj.Spec.Replicas = &replicas
    currentObj, err := json.Marshal(newobj)
    if err != nil {
        return kubeadmission.Errored(http.StatusBadRequest, err)
    }
  // 对比之前的资源类型和之后的资源类型的差异生成返回数据
    resp := kubeadmission.PatchResponseFromRaw(originObj, currentObj)
    respJson, err := json.Marshal(resp.AdmissionResponse)
    if err != nil {
        return kubeadmission.Errored(http.StatusBadRequest, err)
    }
    return resp
}

主程序：

func main() {
    scheme := kuberuntime.NewScheme()
    decoder, err := kubeadmission.NewDecoder(scheme)
    if err != nil {
        log.Fatalln(err)
    }
    mutation := MutatingHandler{
        Decoder: decoder,
    }
    var logger = klogr.New()
    webhook := kubeadmission.Webhook{
        Handler: &mutation,
    }

    logger.Info("test", "unable to decode the request")
    _, err = inject.LoggerInto(logger, &webhook)
    if err != nil {
        log.Fatalln(err)
    }
    http.HandleFunc("/mutation-deployment", webhook.ServeHTTP)
  // 这里需要用到TLS证书和密钥
    err = http.ListenAndServeTLS(":8000", "cert.pem", "private.key", nil)
    if err != nil {
        log.Fatalln(err)
    }
}

基于私钥生成一个证书签名请求（Certificate Signing Request，CSR），目标地址的域名为：mutating-test.testing-tools.svc, csr的配置：

openssl genrsa -out private.key 2048

创建命令：

[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name
[req_distinguished_name]
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = mutating-test
DNS.2 = mutating-test.testing-tools
DNS.3 = mutating-test.testing-tools.svc
DNS.4 = mutating-test.testing-tools.svc.cluster.local

用api-server的CA进行签发

基于csr创建 CertificateSigningRequest:

cat <<EOF | kubectl create -f -
apiVersion: certificates.k8s.io/v1beta1
kind: CertificateSigningRequest
metadata:
  name: mutating-test
spec:
  groups:
  - system:authenticated
  request: $(cat server.csr | base64 | tr -d '\n')
  usages:
  - digital signature
  - key encipherment
  - server auth
EOF

认证完成可以查看：

kubectl certificate approve mutating-test

生成证书：

$ kubectl get csr
NAME          AGE   SIGNERNAME                     REQUESTOR    CONDITION
mutating-test   1m   kubernetes.io/legacy-unknown   user-f9mr4   Approved,Issued

获取api-server的CA证书：

kubectl get csr mutating-test -o jsonpath='{.status.certificate}' | openssl base64 -d -A -out cert.pem

将这个证书填入 Webhook 的 caBundle。

MutatingAdmissionWebhook特性

image.png

MutatingAdmissionWebhook作为kubernetes的ApiServer中Admission Controller的一部分，提供了非常灵活的扩展机制，通过配置MutatingWebhookConfiguration对象，理论上可以监听并修改任何经过ApiServer处理的请求

MutatingWebhookConfiguration对象简介

apiVersion: admissionregistration.k8s.io/v1beta1
kind: MutatingWebhookConfiguration
metadata:
  creationTimestamp: null
  name: mutating-webhook-oversale
webhooks:
- clientConfig:
    caBundle: ...
    service:
      name: webhook-oversale-service
      namespace: oversale
      path: /mutate
  failurePolicy: Ignore
  name: oversale
  rules:
  - apiGroups:
    - *
    apiVersions:
    - v1
    operations:
    - UPDATE
    resources:
    - nodes/status

MutatingWebhookConfiguration是kubernetes的一个官方的资源提供的对象，下面对该对象的字段做一些简单的说明：

• clientConfig.caBundle：apiServer访问我们自定义的webhook服务时需要的加密认证数据
• clientConfig.service：apiServer访问我们自定义的webhook服务的Service相关信息（包括具体接口信息）
• failurePolicy：当apiServer调用我们自定义的webhook服务异常时，采取的策略（Ignore：忽略异常继续处理，Fail：直接失败退出不继续处理）
• rules.operations：监听apiServer的操作类型，样例中，只有符合UPDATE类型的apiServer调用才会交给我们自定义的webhook服务处理。
• rules.resources：监听apiServer的资源和子资源类型，样例中，只有符合nodes的status字段资源类型的apiServer调用才会交给我们自定义的webhook服务处理。

结合rules.operations和rules.resources的属性，我们可以知道样例中的MutatingWebhookConfiguration监听了集群中nodes资源的status数据向apiServer提交的更新操作（就是我们前面提到的心跳信息），并且将所有的心跳信息发给了名为webhook-oversale-service的Service下的/mutate接口处理，这个接口就是我们自定义的webhook服务提供的。

上图中的Pod跑着的容器就是我们自定义的webhook服务，一个自定义webhook服务样例供参考

例子

资源超卖问题分析

在生产环境中，kubernetes集群的计算节点上运行着许许多多的Pod，分别跑着各种业务容器，我们通常用Deployment、DeamonSet、StatefulSet等资源对象去控制Pod的增删改。因此，开发或运维往往需要配置这些资源对象的Containers字段中业务容器的CPU和内存的资源配额：requests和limit

requests：节点调度pod需要的资源，每次成功调度则将节点的Allocatable属性值（可分配资源）重新计算，
新的Allocatable值 = 旧的Allocatable值 - 设置的requests值
limit：节点中运行pod能够获得的最大资源，当cpu
我们不难发现，当requests字段设置太大的时候，pod实际使用的资源却很小，导致计算节点的Allocatable值很快就被消耗完，节点的资源利用率会变得很低。

image.png

上图中最大的蓝色框（allocatable）为计算节点可分配资源，橙色框（requests）为用户配置的requests属性，红色框（current）为业务容器实际使用的资源。因此节点的资源利用率为 current / allocatable。而由于requests设置太大，占满了allocatable，导致新的pod无法被调度到这个节点，就会出现节点实际资源占用很低，却因为allocatable太低导致pod无法调度到该节点的现象。
因此我们能否通过动态调整allocatable的值来让计算节点的可分配资源变得"虚高"，骗过k8s的调度器，让它以为该节点可分配资源很大，让尽可能多的pod调度到该节点上呢？

image.png

上图通过将allocatable值扩大（fake allcatable），让更多的pod调度到了改节点，节点的资源利用率 current / allocatable 就变大了。

apiVersion: v1
kind: Node
metadata:
  annotations:
    ...
  creationTimestamp: ...
  labels:
    ...
  name: k8s-master.com
  resourceVersion: "7564956"
  selfLink: /api/v1/nodes/k8s-master.com
  uid: ...
spec:
  podCIDR: 10.244.0.0/24
status:
  addresses:
  - address: 172.16.0.2
    type: InternalIP
  - address: k8s-master.com
    type: Hostname
  allocatable: ## 这就是需要动态修改的字段！！！
    cpu: "1"
    ephemeral-storage: "47438335103"
    hugepages-2Mi: "0"
    memory: 3778260Ki
    pods: "110"
  capacity:
    cpu: "1"
    ephemeral-storage: 51473888Ki
    hugepages-2Mi: "0"
    memory: 3880660Ki
    pods: "110"
  conditions:
    ...
  daemonEndpoints:
    ...
  images: 
    ...

实现资源超卖的思路

实现资源超卖的关键在于动态修改节点Node对象的allocatable字段值，而我们看到allocatable字段属于Status字段，显然不能直接通过kubectl edit命令来直接修改。因为Status字段和Spec字段不同，Spec是用户设置的期望数据，而Status是实际数据（Node节点通过不断向apiServer发送心跳来更新自己的实时状态，最终存在etcd中）。那么我们要怎么去修改Stauts字段呢？
首先，要修改k8s中任何资源对象的Status值，k8s官方提供了一套RESTful API：https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.13
可以通过patch或者put方法来调用k8s的RESTful API，实现Stauts字段的修改。（这里是通过ApiServer去修改etcd中保存的Status字段的值）

image.png

但是，Node资源对象比较特殊，计算节点会不断给ApiServer发送心跳（默认每隔10s发一次），将带有Status字段的真实信息发送给ApiServer，并更新到etcd中。也就是无论你怎么通过patch/put方法去修改Node的Status字段，计算节点都会定时通过发送心跳将真实的Status数据覆盖你修改的数据，也就是说我们无法通过直接调用RESTful API修改Node对象中的Status数据。

image.png

那我们是否可以直接监听这个计算节点的心跳数据，通过修改心跳数据中的Status字段中的allocatable值，从而实现资源超卖呢？

答案是肯定的，k8s在ApiServer中就提供了Admission Controller（准入控制器）的机制，其中包括了MutatingAdmissionWebhook，通过这个webhook，所有和集群中所有和ApiSever交互的请求都被发送到一个指定的接口中，我们只要提供一个这样的接口，就可以获取到Node往ApiServer发送心跳的Staus数据了。然后将这个数据进行我们的自定义修改，再往后传给etcd，就能让etcd以为我们修改过的Status数据就是节点的真实Status，最终实现资源的超卖。

Sidecar Injector自动注入

Sidecar注入

我们都知道，Istio的流量管理、策略、遥测等功能无须应用程序做任何改动，这种无侵入式的方式全部依赖于Sidecar。应用程序发送或者接收的流量都被Sidecar拦截，并由Sidecar进行认证、鉴权、策略执行及遥测数据上报等众多治理功能。

image.png

如图所示，在Kubernetes中，Sidecar容器与应用容器共存于同一个Pod中，并且共享同一个Network Namespaces，因此Sidecar容器与应用容器共享同一个网络协议栈，这也是Sidecar能够通过iptables拦截应用进出口流量的根本原因。

Istio的Sidecar模式

在Istio中进行Sidecar注入有两种方式：一种是通过istioctl命令行工具手动注入;另一种是通Istio Sidecar Injector自动注入。

这两种方式的最终目的都是在应用Pod中注入init容器及istio-proxy容器这两个Sidecar容器。如下所示，通过部署Istio的sleep应用，Sidecar是通过sidecar-injector自动注入的，查看注入的Sidecar容器：

istio-proxy 容器：

- args:                 # istio-proxy 容器命令行参数

    - proxy

- sidecar

    - --domain

- $(POD_NAMESPACE).svc.cluster.local

    - --configPath

- /etc/istio/proxy

- --binaryPath

    - /usr/local/bin/envoy

    - --serviceCluster

  - sleep.default

    - --drainDuration

- 45s

    - --parentShutdownDuration

- 1m0s

    - --discoveryAddress

    - istio-pilot.istio-system:15011

    - --zipkinAddress

    - zipkin.istio-system:9411

    - --connectTimeout

    - 10s

    - --proxyAdminPort

- "15000"

    - --controlPlaneAuthPolicy

    - MUTUAL_TLS

    - --statusPort

- "15020"

    - --applicationPorts

    - ""

    env:                       # istio-proxy 容器环境变量

  - name: POD_NAME

      valueFrom:

        fieldRef:

          apiVersion: v1

          fieldPath: metadata.name

  - name: POD_NAMESPACE

      valueFrom:

        fieldRef:

          apiVersion: v1

          fieldPath: metadata.namespace

  - name: INSTANCE_IP

      valueFrom:

        fieldRef:

          apiVersion: v1

          fieldPath: status.podIP

    - name: ISTIO_META_POD_NAME

      valueFrom:

        fieldRef:

          apiVersion: v1

          fieldPath: metadata.name

- name: ISTIO_META_CONFIG_NAMESPACE

      valueFrom:

        fieldRef:

          apiVersion: v1

          fieldPath: metadata.namespace

- name: ISTIO_META_INTERCEPTION_MODE

      value: REDIRECT

- name: ISTIO_METAJSON_LABELS

      value: |

        {"app":"sleep","pod-template-hash":"7f59fddf5f"}

    image: gcr.io/istio-release/proxyv2:release-1.1-20190124-15-51

    imagePullPolicy: IfNotPresent

    name: istio-proxy

    ……

    volumeMounts:                  # istio-proxy挂载的证书及配置文件

- mountPath: /etc/istio/proxy

      name: istio-envoy

    - mountPath: /etc/certs/

      name: istio-certs

      readOnly: true

- mountPath: /var/run/secrets/kubernetes.io/serviceaccount

      name: sleep-token-266l9

      readOnly: true

istio-init容器：

initContainers:                # istio-init容器，用于初始化Pod网络

- args:

  - -p

- "15001"

    - -u

- "1337"

    - -m

- REDIRECT

    - -i

    - '*'

    - -x

    - ""

    - -b

    - ""

    - -d

- "15020"

image: gcr.io/istio-release/proxy_init:release-1.1-20190124-15-51

    imagePullPolicy: IfNotPresent

    name: istio-init

    ……

    securityContext:

      capabilities:

        add:

  - NET_ADMIN

      procMount: Default

Sidecar Injector自动注入的原理

Sidecar Injector是Istio中实现自动注入Sidecar的组件，它是以Kubernetes准入控制器Admission Controller的形式运行的。Admission Controller的基本工作原理是拦截Kube-apiserver的请求，在对象持久化之前、认证鉴权之后进行拦截。Admission Controller有两种：一种是内置的，另一种是用户自定义的。Kubernetes允许用户以Webhook的方式自定义准入控制器，Sidecar Injector就是这样一种特殊的MutatingAdmissionWebhook。

如图所示，Sidecar Injector只在创建Pod时进行Sidecar容器注入，在Pod的创建请求到达Kube-apiserver后，首先进行认证鉴权，然后在准入控制阶段，Kube-apiserver以REST的方式同步调用Sidecar Injector Webhook服务进行init与istio-proxy容器的注入，最后将Pod对象持久化存储到etcd中。

Sidecar Injector的工作原理

Sidecar Injector可以通过MutatingWebhookConfiguration API动态配置生效，Istio中的MutatingWebhook配置如下：

apiVersion: admissionregistration.k8s.io/v1beta1

kind: MutatingWebhookConfiguration

metadata:

  creationTimestamp: "2019-02-12T06:00:51Z"

  generation: 4

  labels:

    app: sidecarInjectorWebhook

    chart: sidecarInjectorWebhook

    heritage: Tiller

    release: istio

  name: istio-sidecar-injector

resourceVersion: "2974010"

  selfLink: /apis/admissionregistration.k8s.io/v1beta1/mutatingwebhookconfigurations/istio-sidecar-injector

  uid: 8d62addb-2e8b-11e9-b464-fa163ed0737f

webhooks:

- clientConfig:

    caBundle: ……

    service:

      name: istio-sidecar-injector

      namespace: istio-system

      path: /inject

  failurePolicy: Fail

  name: sidecar-injector.istio.io

  namespaceSelector:

    matchLabels:

      istio-injection: enabled

  rules:

  - apiGroups:

    - ""

apiVersions:

    - v1

    operations:

- CREATE

    resources:

  - pods

  sideEffects: Unknown

从以上配置可知，Sidecar Injector只对标签匹配“istio-injection: enabled”的命名空间下的Pod资源对象的创建生效。Webhook服务的访问路径为“/inject”，地址及访问凭证等都在clientConfig字段下进行配置。

Istio Sidecar Injector组件是由sidecar-injector进程实现的，本书在之后将二者视为同一概念。Sidecar Injector的实现主要由两部分组成：

• 维护MutatingWebhookConfiguration；

• 启动Webhook Server，为应用工作负载自动注入Sidecar容器。

MutatingWebhookConfiguration对象的维护主要指监听本地证书的变化及Kubernetes MutatingWebhookConfiguration资源的变化，以检查CA证书或者CA数据是否有更新，并且在本地CA证书与MutatingWebhookConfiguration中的CA证书不一致时，自动更新MutatingWebhookConfiguration对象。