在公司开发使用虚机迁移至私有云背景下，所有环境的业务服务及中间件开始纳入自建的kubernetes集群进行统一管理，据粗略统计，核心集群单中间件已达2500多个pod。如此众多的pod如果按照一比一的资源分配方式，也就是每个pod足额分配，占用的cpu和内存资源将非常庞大。另外在大多数情况下，每个pod并不是吃满整个分配资源的，所以资源利用率也不够高，相比于虚机部署方式带来的收益并不明显。在生产实践中，我们可以通过resource的requests（调度pod最少需要分配的资源）和limits（pod运行允许使用的最大资源）的差异化配置使得整个集群能调度更多的pod来充分利用资源，这种方式即为Pod压缩。
我们看到了Pod压缩带来的好处是提高了集群资源利用率，但是也存在着一些问题：
1.每个业务需求都不一样，Requests/Limits压缩比例配置多少合适？
2.谁来设置这个比例，调度Pod的时候如何实现自动化设置？
云上目前包含的业务主要可以分为几类，核心组件、星斗组件、核心中间件、非核心中间件、重点业务和通用业务，根据以往经验和业务重要等级，我们对这六类业务进行的等级划分，从P0-P5每个等级对应相应的压缩比例，例如核心组件P0比例为1：1方式配置，也就是不允许压缩。
在确定了压缩比例后，我们还需要知道workload资源分配的基准值，这个值有来自业务方的需求，也有以往经验得出的默认值。这个值可以理解为limits，通过比例可以计算出requests。为了避免人工每次部署之前去按比例设置，防止遗漏或者错误，我们使用自定义开发的AdmissionWebhook插件来实现对有相应标记的workload自动进行资源配置。
AdmissionWebhook在常见的web服务开发中，我们经常会遇到这样的需求：拦截具有某些规则的API请求，做相应的检查或者修改逻辑后再交于service做业务逻辑处理，java中的拦截器，Go的middlerware可以很好的完成以上需求。相似的，AdmissionWebhook也充当着类似于拦截器的角色。Kubernetes的资源管理最终是通过调用apiserver完成集群数据在etcd中持久化，资源数据持久化之前可以通过AdmissionWebhook对指定资源做校验、修改等操作，例如资源限制，打标等。
kubernetes社区给我们提供一些内置的AdmissionWebhook插件，具体使用和介绍可以参考官网：https://kubernetes.io/zh/docs/reference/access-authn-authz/admission-controllers。
随着公司业务的复杂度增加，内置插件已经不能满足需求， kubernetes的AdmissionWebhook为开发者提供了非常灵活的插件模式，所以我们可以根据实际的业务场景开发一些定制的AdmissionWebhook插件。
自定义开发的AdmissionWebhook主要分为两种，分别是验证准入器ValidatingAdmissionWebhook和修改准入器MutatingAdmissionWebhook。首先通过官网的一张APIrequest流程图来直观的了解这两种控制器所处的位置。
当kubernetes资源发生修改，api请求到达aipserver并经过认证后，开始串行执行MutatingAdmissionWebhook，对资源定义进行相应逻辑的变更，执行完后进行资源校验，然后并行执行所有的ValidatingAdmissionWebhook验证资源定义，最后持久化到etcd中。下面通过一个简单例子帮助理解。
下面这段yaml左边的定义了一个类型为Deployment的kubernetes资源，它规定了最少需要100m的cpu和256Mi内存才能启动mysql，在实际使用中，这种没有设置上限limits的资源是非常危险的，在某些异常情况下，该mysql可能会占用非常大的集群资源。我们通过MutatingAdmissionWebhook，可以自动发现并修改资源定义来满足要求，这样即便是用户忘记设置了，webhook也能自动加上。同理ValidatingAdmissionWebhook做的就不是变更yaml了，它做的那就是直接告诉用户这个修改不通过。
1.对需要部署的workload打标，xsyxxd.com/priority: p3标识了该工作负载的重要等级，然后通过resource-admission-webhook: enabled开关来启用resource-admission-webhook。
kind: Deployment
apiVersion: apps/v1
metadata:
annotations:
xsyxxd.com/priority: p3
namespace: daily-xxx-mw
labels:
resource-admission-webhook: enabled
2.resource-admission-webhook实际上是一个按自身需求开发的http服务，它暴露了一个/mutate接口，同时我们需要部署一个kind为MutatingWebhookConfiguration的k8s资源，这个资源中描述了哪些操作会进入resource-admission-webhook的/mutate中进行回调处理。下面的配置中指定了对deployments和statefulsets的create和update操作请求会进入到/mutate中。
kind: MutatingWebhookConfiguration
......
clientConfig:
service:
name: resource-admission-webhook
namespace: sophon
path: "/mutate"
caBundle: ${CA_BUNDLE}
rules:
- operations: [ "CREATE", "UPDATE" ]
apiGroups: ["apps", ""]
apiVersions: ["v1"]
resources: ["deployments", "statefulsets"]
3.resource-admission-webhook将API请求中的body数据decode为k8s资源对象，根据业务等级换算资源配置后封装为一个patch集合，patch中记录了对k8s资源相应path下的操作，最后封装成AdmissionResponse重新交给主流程。
Pod压缩方案是针对Workload 级别的资源调整方案，能细粒度的控制资源分配，但是对已有的Workload进行调整时会导致Pod重启，需要注意对业务影响。另外对于Workload等级的区分也是一个相对较为粗的粒度，在复杂业务场景下还是有所欠缺。
目前实现的方式仍存在很大的优化空间，接下来的方向可以考虑由静态调整转为动态调整，结合监控系统和Kubernetes的弹性伸缩能力，根据资源实际使用情况来实现横向伸缩，另外开源社区中还有一个VPA项目，能在不重启pod的条件下快速扩容等等。
