【Kubernetes】基于SpringBoot的Mutating Admission Webhook Server实现

1. 背景
2. 注意事项
3. 思路
4. 过程
5. 2022/01/21 更新 toAdmissionReview方法

背景

公司内网的Kubernetes集群因为Istio sidecar的原因，经常会达到公司运维给我们组设置的资源上限。一个我们的业务服务通常由两部分容器组成，一个是我们真实对外服务的容器，另一个则是由Istio sidecar inject也就是Istio框架自动注入的Istio-sidecar。不提我们的业务容器，只针对Istio sidecar，他的resource/limit/cpu就被设置为了2，要知道我们组所属的namespace下，资源limit上限被设置为了100cpu，超过100之后服务就无法被部署成功。同时，作为一个内网的服务，他的上限也根本不用2，这一个较高的数字。

在Istio后续的1.4版本中，有一个专门为Pod.spec.resource.cpu.limit和memory设置的注解，但是在之前的版本中不提供这样的支持，所以只能通过我们自己来实现。最简单的方法自然是为每一个环境(内网或者外网)做一份不同的设置，考虑到我们服务过于多，一个一个添加不大科学，也不符合k8s不影响到业务集成过程的理念。综上所述，最终考虑到k8s原生支持的Mutating Admission Webhook来实现。

Mutating Admission Webhook对我而言，简而言之，就是Kube-api 在执行真正的部署命令之前，提前对你要部署的东西做一个修改。Istio的Istio sidecar injector也是通过这个来实现的。那对我来说，只要在Istio sidecar injector注入sider，也就是他对Pod做完修改之后，我在将他的istio proxy中的container.resource.cpu.limit修改为我要的值就好了。

在google和github上搜索一番，基本都是基于Go语言来实现Admission Webhook Server，没有发现有Java实现的，所以打算自己动手实现一个。

注意事项

• 第一次搞Mutating Webhook Admission Webhook，可以将在Pod中注入一个新的Label作为成功标准
• 接上条，可以把Webhook Admission Webhook Configuration中的failPolicy设置为Fail，即在Server端中有意外情况，算作失败，这样可以在Replicas看到部署失败的原因

思路

从官方文档上来说，比较关键的东西有三个

1. Mutating Admission Webhook Configuration，一份Webhook的配置文件，他决定谁会被拦截，和将请求转发到那里去
2. Mutating Admission Webhook Server，在本文中专指Springboot 实现的一个Server，他的作用是怎么修改即将要被部署的kubernetes 资源
3. 请求，也就是第一点提供到谁会被拦截到的谁，一般来说是指某一个被打了特定label的namespace
   比较琐碎的细节，包括但不限于Kube-api 里面是否开启了admission webhook的限制，configuration和server的证书配置，server端要求返回的格式

过程

几个关键节点大概分为这几个历程

1. Object生成请求拦截（这里就是Pod生成之前会给我们的server发消息）
2. RequestBody 反序列化 （可以看到我们的server接收到k8s发来的消息是什么样子的）
3. 尝试修改pod参数 (尝试修改一下pod的label)
4. 尝试修改 istio-proxy resource参数

在第一个关键节点上我们理论上就应该完成大部分的工作，后面的过程是在做细节上的处理。

我的Configuration文件是这个样子的

apiVersion: admissionregistration.k8s.io/v1beta1
kind: MutatingWebhookConfiguration
metadata:
  name: