1. 准入控制
一般我们操作Kubernetes资源的流程是如下这样的：
- API Server认证；
- API Server鉴权；
- APT Server实际处理请求并持久化到ETCD；
而准入控制则具有一种能力，它可以在认证、鉴权之后对象被持久化之前对请求进行拦截，只有这些准入控制都通过之后才允许放行请求。截止Kubernetes v1.17版本，它自身已经内置支持很多admission插件，详情可移步Kubernetes内置准入控制器列表，但这些不是笔者在此述说的重点，今天主要谈谈admission插件在实际环境的动态扩展实现：admission webhook。
2. Admission Webhook
Admission webhook 是一种用于接收准入请求并对其进行处理的 HTTP 回调机制。 可以定义两种类型的 admission webhook，即 validating admission webhook 和 mutating admission webhook。 Mutating admission webhook 会先被调用。它们可以更改发送到 API 服务器的对象以执行自定义的设置默认值操作。
在完成了所有对象修改并且 API 服务器也验证了所传入的对象之后，validating admission webhook 会被调用，并通过拒绝请求的方式来强制实施自定义的策略。
如下针对admission webhook做一个简单的实践。
3. 实践
本文实例源码可参考：https://github.com/VeinFu/admission_webhook_example
3.1 功能需求
-
ValidatingAdmissionWebhook：创建
Pod时，当这个Pod存在于test-misssion命名空间中且标签run: test-admission时则对该Pod其他标签进行校验，如果不存在必须满足的标签test-admission、admission-wenhook时则拦截该创建Pod的请求； -
MutatingAdmissionWebhook：创建
Pod时，当这个Pod存在于test-misssion命名空间中且标签run: test-admission时则对该Pod添加额外两个标签：test-admission、admission-wenhook；
3.2 代码部分
代码很简单，主要用到如下两个golang库：net/http和k8s.io/api/admission/v1beta1，前者用来启动一个HTTPS Server，后者用来处理admission的请求和响应的。
具体代码的逻辑就不在此逐一分析了，如下几点简单说明一下：
- webhook服务是https协议接口，因此
Kubernetes API Server和Webhook Server之间要做TLS认证，这里直接使用了集群根证书颁发机构(CA)来进行证书的签发，具体操作步骤如下：
# 一般集群CA私钥、证书存放在master节点的/etc/kubernetes/ssl目录下
# 生成webhook server的私钥
openssl genrsa -out server.key 2048
# 创建webhook server csr
openssl req -new -key server.key -subj "/CN=admission-service.default.svc" -out server.csr
# 创建webhook server证书
openssl x509 -req -in server.csr -CA /etc/kubernetes/ssl/ca.pem -CAkey /etc/kubernetes/ssl/ca-key.pem -CAcreateserial -out server.crt -days 10000
# 创建对应的secret
kubectl create secret generic webhook-server --from-file=server.key --from-file=server.crt
# 在部署webhook server应用时对此secret进行挂载，如此就可以实现kube-apiserver和webhook server的双向认证了。
- 上面进行证书签发时
common name填的是admission-service.default.svc，如此就得保证集群层面是可以识别到这个域名，借助Core-DNS可以解决这个问题，先获取core-dns服务对应的Cluster-IP，然后将其配置到域名配置文件/etc/resolv.conf中：
如果域名设置不生效可以尝试systemctl stop/disable Network-Manager。
3.3 部署
首先下载源码至$GOPATH/src目录中进行镜像构建。
然后参照如下步骤部署webhook server即可：
# 创建test-admisssion命名空间
kubectl create ns test-admisssion
# 部署webhook server应用
kubectl create -f deploy/admission-server-deploy.yaml
3.4 测试
如下对两个admission webhook各自简单测试一下：
ValidatingWebhook测试
# 创建validationwebhook配置实例
[root@m01 ~] kubectl create -f deploy/validate-config.yaml # 这个配置会存在caBundle的字段，值直接填入kubeconfig对应字段`certificate-authority-data`的值即可。
[root@m01 ~] cat deploy/test/test-admission-label-no.yaml
kind: Pod
apiVersion: v1
metadata:
namespace: test-admisssion
name: nginx-app
spec:
containers:
- name: nginx
image: nginx
restartPolicy: "Always"
[root@m01 ~] cat deploy/test/test-admission-label-no.yaml | kubectl create -f -
pod/nginx-app created
[root@m01 ~] kubectl get pod -n test-admisssion
NAME READY STATUS RESTARTS AGE
nginx-app 1/1 Running 0 6s
[root@m01 ~]
很显然，这个pod没有标签run: test-admission，因此不受该validatewebhook的限制，与期望相符。
[root@m01 ~] cat deploy/test/test-admission-label-yes.yaml
kind: Pod
apiVersion: v1
metadata:
namespace: test-admisssion
name: nginx-app-test
labels:
run: test-admission
spec:
containers:
- name: nginx
image: nginx
restartPolicy: "Always"
[root@m01 ~] cat deploy/test/test-admission-label-yes.yaml | kubectl create -f -
Error from server (required label is not set): error when creating "STDIN": admission webhook "admission-service.default.svc" denied the request: required label is not set
[root@m01 ~]
这个pod具有标签run: test-admission但是没有其他必备的标签，因此该api请求被拦截导致创建pod失败，也与期望相符。
MutatingWebhook测试
测试方法类似不再赘述，按如下步骤操作即可：
kubectl create -f deploy/mutate-config.yaml
kubectl create -f deploy/test/test-admission-label-no.yaml
kubectl create -f deploy/test/test-admission-label-yes.yaml
之后去查询新建的容器组nginx-app-test可以看到其新增了两个标签，与期望相符。
好啦，有关这次Kubernetes admission webhook的讲解就先到此了，后续有机会再继续深入。
网友评论