1. k8s的Mutating 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，或者阻止不合规的资源。
Admission Webhook 包涵两种 CRD： mutatingwebhookconfiguration 和 。
下面是一个 mutatingwebhookconfiguration 的CRD文件：
Admission Webhook 本质是 api-server 的一个 webhook 调用，下面是 api-server 的处理流程：
api-server 通过读取 mutatingwebhookconfiguration 和 的 CR 文件的目标地址，然后回调用户自定义的服务。
api-server 发起的请求是一串json数据格式，header需要设置 content-type 为 application/json , 我们看看请求的 body :
返回的结果：
这里的 patch 是用base64编码的一个json，我们解码看看，是一个 json patch：
处理函数：
主程序：
基于私钥生成一个证书签名请求（Certificate Signing Request，CSR），目标地址的域名为： mutating-test.testing-tools.svc , csr的配置：
创建命令：
基于csr创建 CertificateSigningRequest :
认证完成可以查看：
生成证书：
获取api-server的CA证书：
将这个证书填入 Webhook 的 caBundle。
MutatingAdmissionWebhook作为kubernetes的ApiServer中Admission Controller的一部分，提供了非常灵活的扩展机制，通过配置MutatingWebhookConfiguration对象，理论上可以监听并修改任何经过ApiServer处理的请求
MutatingWebhookConfiguration是kubernetes的一个官方的资源提供的对象，下面对该对象的字段做一些简单的说明：
结合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值很快就被消耗完，节点的资源利用率会变得很低。
上图中最大的蓝色框（allocatable）为计算节点可分配资源，橙色框（requests）为用户配置的requests属性，红色框（current）为业务容器实际使用的资源。因此节点的资源利用率为 current / allocatable。而由于requests设置太大，占满了allocatable，导致新的pod无法被调度到这个节点，就会出现节点实际资源占用很低，却因为allocatable太低导致pod无法调度到该节点的现象。
因此我们能否通过动态调整allocatable的值来让计算节点的可分配资源变得"虚高"，骗过k8s的调度器，让它以为该节点可分配资源很大，让尽可能多的pod调度到该节点上呢？
上图通过将allocatable值扩大（fake allcatable），让更多的pod调度到了改节点，节点的资源利用率 current / allocatable 就变大了。
实现资源超卖的关键在于动态修改节点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字段的值）
但是，Node资源对象比较特殊，计算节点会不断给ApiServer发送心跳（默认每隔10s发一次），将带有Status字段的真实信息发送给ApiServer，并更新到etcd中。也就是无论你怎么通过patch/put方法去修改Node的Status字段，计算节点都会定时通过发送心跳将真实的Status数据覆盖你修改的数据，也就是说我们无法通过直接调用RESTful API修改Node对象中的Status数据。
那我们是否可以直接监听这个计算节点的心跳数据，通过修改心跳数据中的Status字段中的allocatable值，从而实现资源超卖呢？
答案是肯定的，k8s在ApiServer中就提供了Admission Controller（准入控制器）的机制，其中包括了MutatingAdmissionWebhook，通过这个webhook，所有和集群中所有和ApiSever交互的请求都被发送到一个指定的接口中，我们只要提供一个这样的接口，就可以获取到Node往ApiServer发送心跳的Staus数据了。然后将这个数据进行我们的自定义修改，再往后传给etcd，就能让etcd以为我们修改过的Status数据就是节点的真实Status，最终实现资源的超卖。
我们都知道，Istio的流量管理、策略、遥测等功能无须应用程序做任何改动，这种无侵入式的方式全部依赖于Sidecar。应用程序发送或者接收的流量都被Sidecar拦截，并由Sidecar进行认证、鉴权、策略执行及遥测数据上报等众多治理功能。
如图所示，在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容器：
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可以通过MutatingWebhookConfiguration API动态配置生效，Istio中的MutatingWebhook配置如下：
从以上配置可知，Sidecar Injector只对标签匹配“istio-injection: enabled”的命名空间下的Pod资源对象的创建生效。Webhook服务的访问路径为“/inject”，地址及访问凭证等都在clientConfig字段下进行配置。
Istio Sidecar Injector组件是由sidecar-injector进程实现的，本书在之后将二者视为同一概念。Sidecar Injector的实现主要由两部分组成：
MutatingWebhookConfiguration对象的维护主要指监听本地证书的变化及Kubernetes MutatingWebhookConfiguration资源的变化，以检查CA证书或者CA数据是否有更新，并且在本地CA证书与MutatingWebhookConfiguration中的CA证书不一致时，自动更新MutatingWebhookConfiguration对象。
2. Kubernetes Operator 快速入门教程（Operator 101）
在 Kubernetes 的监控方案中我们经常会使用到一个Promethues Operator的项目，该项目可以让我们更加方便的去使用 Prometheus，而不需要直接去使用最原始的一些资源对象，比如 Pod、Deployment，随着 Prometheus Operator 项目的成功，CoreOS 公司开源了一个比较厉害的工具：Operator Framework，该工具可以让开发人员更加容易的开发 Operator 应用。
在本篇文章中我们会为大家介绍一个简单示例来演示如何使用 Operator Framework 框架来开发一个 Operator 应用。
Kubernetes Operator
Operator 是由 CoreOS 开发的，用来扩展 Kubernetes API，特定的应用程序控制器，它用来创建、配置和管理复杂的有状态应用，如数据库、缓存和监控系统。Operator 基于 Kubernetes 的资源和控制器概念之上构建，但同时又包含了应用程序特定的领域知识。创建Operator 的关键是CRD（自定义资源）的设计。
Kubernetes 1.7 版本以来就引入了自定义控制器的概念，该功能可以让开发人员扩展添加新功能，更新现有的功能，并且可以自动执行一些管理任务，这些自定义的控制器就像 Kubernetes 原生的组件一样，Operator 直接使用 Kubernetes API进行开发，也就是说他们可以根据这些控制器内部编写的自定义规则来监控集群、更改 Pods/Services、对正在运行的应用进行扩缩容。
Operator Framework
Operator Framework 同样也是 CoreOS 开源的一个用于快速开发 Operator 的工具包，该框架包含两个主要的部分：
Workflow
Operator SDK 提供以下工作流来开发一个新的 Operator：
Demo
我们平时在部署一个简单的 Webserver 到 Kubernetes 集群中的时候，都需要先编写一个 Deployment 的控制器，然后创建一个 Service 对象，通过 Pod 的 label 标签进行关联，最后通过 Ingress 或者 type=NodePort 类型的 Service 来暴露服务，每次都需要这样操作，是不是略显麻烦，我们就可以创建一个自定义的资源对象，通过我们的 CRD 来描述我们要部署的应用信息，比如镜像、服务端口、环境变量等等，然后创建我们的自定义类型的资源对象的时候，通过控制器去创建对应的 Deployment 和 Service，是不是就方便很多了，相当于我们用一个资源清单去描述了 Deployment 和 Service 要做的两件事情。
这里我们将创建一个名为 AppService 的 CRD 资源对象，然后定义如下的资源清单进行应用部署：
通过这里的自定义的 AppService 资源对象去创建副本数为2的 Pod，然后通过 nodePort=30002 的端口去暴露服务，接下来我们就来一步一步的实现我们这里的这个简单的 Operator 应用。
开发环境
环境需求
要开发 Operator 自然 Kubernetes 集群是少不了的，还需要 Golang 的环境，这里的安装就不多说了，然后还需要一个 Go 语言的依赖管理工具包：dep，由于 Operator SDK 是使用的 dep 该工具包，所以需要我们提前安装好，可以查看资料：https://github.com/golang/dep，另外一个需要说明的是，由于 dep 去安装的时候需要去谷歌的网站拉取很多代码，所以正常情况下的话是会失败的，需要做什么工作大家应该清楚吧？要科学。
安装 operator-sdk
operator sdk 安装方法非常多，我们可以直接在 github 上面下载需要使用的版本，然后放置到 PATH 环境下面即可，当然也可以将源码 clone 到本地手动编译安装即可，如果你是 Mac，当然还可以使用常用的 brew 工具进行安装：
我们这里使用的 sdk 版本是v0.7.0，其他安装方法可以参考文档：https://github.com/operator-framework/operator-sdk/blob/master/doc/user/install-operator-sdk.md
演示
创建新项目
环境准备好了，接下来就可以使用 operator-sdk 直接创建一个新的项目了，命令格式为： operator-sdk new
按照上面我们预先定义的 CRD 资源清单，我们这里可以这样创建：
到这里一个全新的 Operator 项目就新建完成了。
项目结构
使用operator-sdk new命令创建新的 Operator 项目后，项目目录就包含了很多生成的文件夹和文件。
我们主要需要编写的是 pkg 目录下面的 api 定义以及对应的 controller 实现。
添加 API
接下来为我们的自定义资源添加一个新的 API，按照上面我们预定义的资源清单文件，在 Operator 相关根目录下面执行如下命令：
添加完成后，我们可以看到类似于下面的这样项目结构：
添加控制器
上面我们添加自定义的 API，接下来可以添加对应的自定义 API 的具体实现 Controller，同样在项目根目录下面执行如下命令：
这样整个 Operator 项目的脚手架就已经搭建完成了，接下来就是具体的实现了。
自定义 API
打开源文件pkg/apis/app/v1/appservice_types.go，需要我们根据我们的需求去自定义结构体 AppServiceSpec，我们最上面预定义的资源清单中就有 size、image、ports 这些属性，所有我们需要用到的属性都需要在这个结构体中进行定义：
代码中会涉及到一些包名的导入，由于包名较多，所以我们会使用一些别名进行区分，主要的包含下面几个：
这里的 resources、envs、ports 的定义都是直接引用的"k8s.io/api/core/v1"中定义的结构体，而且需要注意的是我们这里使用的是ServicePort，而不是像传统的 Pod 中定义的 ContanerPort，这是因为我们的资源清单中不仅要描述容器的 Port，还要描述 Service 的 Port。
然后一个比较重要的结构体AppServiceStatus用来描述资源的状态，当然我们可以根据需要去自定义状态的描述，我这里就偷懒直接使用 Deployment 的状态了：
定义完成后，在项目根目录下面执行如下命令：
改命令是用来根据我们自定义的 API 描述来自动生成一些代码，目录pkg/apis/app/v1/下面以zz_generated开头的文件就是自动生成的代码，里面的内容并不需要我们去手动编写。
实现业务逻辑
NewDeploy 方法实现如下：
newService 对应的方法实现如下：
这样我们就实现了 AppService 这种资源对象的业务逻辑。
调试
如果我们本地有一个可以访问的 Kubernetes 集群，我们也可以直接进行调试，在本地用户~/.kube/config文件中配置集群访问信息，下面的信息表明可以访问 Kubernetes 集群：
首先，在集群中安装 CRD 对象：
上面的命令会在本地运行 Operator 应用，通过~/.kube/config去关联集群信息，现在我们去添加一个 AppService 类型的资源然后观察本地 Operator 的变化情况，资源清单文件就是我们上面预定义的（deploy/crds/app_v1_appservice_cr.yaml）
直接创建这个资源对象：
我们可以看到我们的应用创建成功了，这个时候查看 Operator 的调试窗口会有如下的信息出现：
然后我们可以去查看集群中是否有符合我们预期的资源出现：
看到了吧，我们定义了两个副本（size=2），这里就出现了两个 Pod，还有一个 NodePort=30002 的 Service 对象，我们可以通过该端口去访问下应用：
如果应用在安装过程中出现了任何问题，我们都可以通过本地的 Operator 调试窗口找到有用的信息，然后调试修改即可。
清理：
部署
自定义的资源对象现在测试通过了，但是如果我们将本地的operator-sdk up local命令终止掉，我们可以猜想到就没办法处理 AppService 资源对象的一些操作了，所以我们需要将我们的业务逻辑实现部署到集群中去。
执行下面的命令构建 Operator 应用打包成 Docker 镜像：
镜像构建成功后，推送到 docker hub：
镜像推送成功后，使用上面的镜像地址更新 Operator 的资源清单：
现在 Operator 的资源清单文件准备好了，然后创建对应的 RBAC 的对象：
到这里我们的 CRD 和 Operator 实现都已经安装成功了。
现在我们再来部署我们的 AppService 资源清单文件，现在的业务逻辑就会在上面的opdemo-64db96d575-9vtq6的 Pod 中去处理了。
然后同样的可以通过 30002 这个 NodePort 端口去访问应用，到这里应用就部署成功了。
清理
有资源清单文件，直接删除即可：
开发
Operator SDK 为我们创建了一个快速启动的代码和相关配置，如果我们要开始处理相关的逻辑，我们可以在项目中搜索TODO(user)这个注释来实现我们自己的逻辑，比如在我的 VSCode 环境中，看上去是这样的：
本篇文章示例代码地址：https://github.com/cnych/opdemo
参考资料