k8sz之operator相关概念

参考链接：从零开始入门 K8s | Kubernetes API 编程利器：Operator 和 Operator Framework - 云+社区 - 腾讯云

深入解析 Kubebuilder：让编写 CRD 变得更简单 - 阿里巴巴云原生 - 博客园

万字长文：K8s 创建 pod 时，背后到底发生了什么？

云计算虚拟化：k8s进阶-CRD开发基础_dustzhu的博客-CSDN博客

kubebuilder实战之七：webhook_程序员欣宸的博客-CSDN博客

玩转K8S AdmissionWebhook - 云+社区 - 腾讯云

k8s--五种控制器类型解析_长恋离亭的博客-CSDN博客_k8s kind 类型

对 Helm 的一些总结 - 简书

k8s helm 学习笔记 - 简书

概念:Admission Controllers(准入控制器) - 简书

k8s与Admission--webhook admission - 知乎

从0到1开发K8S_Webhook最佳实践 - 知乎

---

介绍一下本文内容所涉及到的基本概念。

1.1 CRD

        全拼CustomResourceDefinitions，也就是自定义K8S资源类型。即在Kubernetes 中添加一个和 Pod、service 类似的、新的 API 资源类型，用于统一部署/编排多个内置K8S资源（pod,service等），熟练掌握 CRD 是成为 Kubernetes 高级玩家的必备技能。

1.2  CR (Custom Resourse)

        CRD 的一个具体实例。

1.3  helm 

        Helm是Kubernetes的包管理器，类似于Python的pip centos的yum,主要用来管理 Charts。它是一个命令行工具，帮你同时编排多个K8S资源（比如：Deployment+Service+Ingress这样的经典组合），统一发布到K8S。Helm 使用 Chart 来管理 Kubernetes manifest 文件。

        Helm 有两个重要的概念：chart 和 release。

        chart 是创建一个应用的信息集合，包括各种 Kubernetes 对象的配置模板、参数定义、依赖关系、文档说明等。chart 是应用部署的自包含逻辑单元。可以将 chart 想象成 apt、yum 中的软件安装包。      

        Helm发布的底层原理就是调用K8S的apiserver，逐个YAML推送给K8S，和我们手动去做没多少差别，所以其弊端就是缺乏对资源的全生命期监控。

        具体一点就是，如果我们Helm发布了一个POD，然后我们在K8S中误删了POD，那么Helm是不会替我们重建POD的，这是Helm的主要问题所在。

          release 是 chart 的运行实例，代表了一个正在运行的应用。当 chart 被安装到 Kubernetes 集群，就生成一个 release。chart 能够多次安装到同一个集群，每次安装都是一个 release。

        Helm 是包管理工具，这里的包就是指的 chart。

        Helm 包含两个组件：Helm 客户端 和 Tiller 服务器。

        简单的讲：Helm 客户端负责管理 chart；Tiller 服务器负责管理 release。

---

相关概念

• chart： 一系列用于描述 k8s 资源相关文件的集合，是 Helm 用于打包 k8s 资源的方式；

• release： 一个 chart 被 Helm 运行后将会生成对应的一个 release；

• TillerServer： Helm 的服务端，部署在 k8s 集群内，主要管理 release 相关的存储和与 k8s 的交互；

• helm： Helm 的客服端，通过 gRPC 协议与 TillerServer 进行交互，主要提供了增删查改 chart、release 和 repository 相关的功能；

chart 和 release 的关系可以用代码和进程的关系来类比。chart 是打包了 k8s 资源的集合（比如 deployment、service 等），而 release 则是在 Helm 中运行的集合实体（比如 values ）。

---

1.4 为什么需要CRD?

        helm也可以做到统一部署/编排deployment,service,ingress，但它缺乏对资源的全生命周期的监控。CRD通过apiserver接口，在etcd中注册一种新的资源类型，此后就可以创建对应的资源对象&并监控它们的状态&执行相关动作，比如，你可以定义一个MYSQL的 CRD完成MYSQL集群项目的全部pod&service创建&监控功能。

      仅仅注册资源与创建资源对象通常是没有价值的，重要的是需要实现CRD背后的功能。比如，Deployment的功能是生成一定数量的POD并监控它们的状态。

    所以CRD需要配套实现Controller，相信大家也听过Deployment Controller这些内置的Controller。Controller是需要CRD配套开发的程序，它通过apiserver监听相应类型的资源对象事件，例如：创建、删除、更新等等，然后做出相应的动作，比如Deployment创建/更新时需要对POD进行更新操作等。

1.5 CRD实现方法

        CRD的实现工具&框架有kubebuilder & operator sdk，后者在向前者融合，建议使用kubebuilder。

1.6  Controller

        在K8S 拥有很多controller 他们的职责是保证集群中各种资源的状态和用户定义(yaml)的状态一致, 如果出现偏差, 则修正资源的状态。比如你部署了一个deployment后，然后手动删除一个pod, Deployment Controller会监控到这个deployment的资源状态与之前yaml中的状态不一致，然后会Deployment Controller自动再创建一个pod。

        Kubernetes 通常不会直接创建 Pod，而是通过 Controller 来管理 Pod 的。Controller 中定义了 Pod 的部署特性，比如有几个副本，在什么样的 Node 上运行等。为了满足不同的业务场景，Kubernetes 提供了多种 Controller，包括 Deployment Controller、ReplicaSet Controller、DaemonSet Controller、StatefuleSet Controller、Job Controller等。

1.7 webhook

   K8s中一种鉴权authorizer 类型，发送者身份（认证）是一个问题，但他是否有权限执行这个操作（鉴权），是另一个问题。因此确认发送者身份之后，还需要进行鉴权。鉴权authorizer 关注的是用户是否有操作权限

Tips:   webhook  它本质上是一种 HTTP 回调，会注册到 apiserver 上。在 apiserver 特定事件发生时，会查询已注册的 webhook，并把相应的消息转发过去。

什么是 Webhook？

Webhook 是一个 API 概念，是微服务 API 的使用范式之一，也被成为反向 API，即前端不主动发送请求，完全由后端推送；举个常用例子，比如你的好友发了一条朋友圈，后端将这条消息推送给所有其他好友的客户端，就是 Webhook 的典型场景。

webhook 究竟是什么呢？webhook 是应用给其它应用提供实时信息的一种方式。信息一产生，webhook 就会把它发送给已经注册的应用，这就意味着你能实时得到数据。不像传统的 APIs 方式，你需要用轮询的方式来获得尽可能实时的数据。

简单来说，Webhook 就是一个接收 HTTP POST（或GET，PUT，DELETE）的URL，一个实现了 Webhook 的 API 提供商就是在当事件发生的时候会向这个配置好的 URL 发送一条信息，与请求-响应式不同，使用 Webhook 你可以实时接受到变化。

这又是一种对 客户机-服务器 模式的逆转，在传统方法中，客户端从服务器请求数据，然后服务器提供给客户端数据（客户端是在拉数据），在 Webhook 范式下，服务器更新所需提供的资源，然后自动将其作为更新发送到客户端（服务器是在推数据），客户端不是请求者，而是被动接收方；这种控制关系的反转可以用来促进许多原本需要在远程服务器上进行更复杂的请求和不断的轮询的通信请求；通过简单地接收资源而不是直接发送请求，我们可以更新远程代码库，轻松地分配资源，甚至将其集成到现有系统中来根据 API 的需要来更新端点和相关数据，唯一的缺点是初始建立困难。

2. 主要用途

更新客户端，在资源新建或者更新时提供更新的、指定的数据。

3. 常见 Webhook 使用场景

对于第三方平台验权、登陆等 没有前端界面做中转的场景，或者强安全要求的支付场景等，适合用 Webhook 做数据主动推送，说白了就是在前端无从参与，或者因为前端安全问题不适合参与时，就是 Webhook 的场景；很显然 Webhook 也不是 Http 的替代品，不过的确是一种新的前后端交互方式。

如果客户端要长期监听某个任务的状态，按照正常的 API 调用的方式去做，那么必须不停得轮训服务器来获取当前状态；使用 Webhook 则无需轮训，通过 API 可以确定是否发生了更改，如果更改了只需要等待服务器推送信息过来，然后客户端更新就可以；git webhook其实也是这方面的应用。

4. 使用说明

Webhook 通过请求发送数据到你的应用后，就不再关注这些数据；也就是说如果你的应用存在问题，数据会丢失，许多 Webhook 会处理回应，如果程序出现错误会重传数据；如果你的应用处理这个请求并且依然返回一个错误，你的应用就会收到重复数据。

Webhook 可能会发出大量的请求，这样会造成你的应用阻塞，确保你的应用能处理这些请求。
作者：MayerBin
链接：https://www.jianshu.com/p/9829986b4363
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

    k8s内置的 几种 authorizer 鉴权类型：

• webhook：与其他服务交互，验证是否有权限。

• ABAC：根据静态文件中规定的策略（policies）来进行鉴权。

• RBAC：根据 role 进行鉴权，其中 role 是 k8s 管理员提前配置的。

• Node：确保 node clients，例如 kubelet，只能访问本机内的资源。

1.8 admission webhook （注意与1.7 webhook）

     玩转K8S AdmissionWebhook - 云+社区 - 腾讯云

        什么是AdmissionWebhook，就要先了解K8S中的admission controller(准入控制器）, 按照官方的解释是： admission controller是拦截(经过身份验证)API Server请求的网关，并且可以修改请求对象或拒绝请求。简而言之，它可以认为是拦截器。

        Admission Controllers(准入控制器) 拦截对 k8s API 的请求, 拦截时刻点是在请求被认证和授权之后. 是将请求对象持久化到 etcd 之前的最后堡垒。

        Admission Control 有一个准入控制列表，我们可以通过命令行设置选择执行哪几个准入控制器。只有所有的准入控制器都检查通过之后，apiserver 才执行该请求，否则返回拒绝。

        K8S默认提供很多内置的admission controller，通过kube-apiserver启动命令参数可以 查看到支持的admission controller plugin有哪些。

[root@node220]# kube-apiserver --help |grep enable-admission-plugins

# 支持的plugin有如下
AlwaysAdmit, AlwaysDeny, AlwaysPullImages, 
DefaultStorageClass, DefaultTolerationSeconds, DenyEscalatingExec, 
DenyExecOnPrivileged, EventRateLimit, ExtendedResourceToleration, 
ImagePolicyWebhook, Initializers, LimitPodHardAntiAffinityTopology, 
LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, 
NamespaceExists, NamespaceLifecycle, NodeRestriction, 
OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, 
PersistentVolumeLabel, PodNodeSelector, PodPreset, PodSecurityPolicy, 
PodTolerationRestriction, Priority, ResourceQuota, SecurityContextDeny, 
ServiceAccount, StorageObjectInUseProtection, ValidatingAdmissionWebhook. 

这里不对每个plugin详细说明，网上都可以搜到相关资料。 总体来说，admission-plugins分为三大类：

1.修改类型(mutating)

2.验证类型(validating)

3.既是修改又是验证类型(mutating&validating)

这些admission plugin构成一个顺序链，先后顺序决定谁先调用，但不会影响使用。

这里关心的plugin有两个：

一、MutatingAdmissionWebhook, ValidatingAdmissionWebhook

• MutatingAdmissionWebhook: 做修改操作的AdmissionWebhook 
• ValidatingAdmissionWebhook: 做验证操作的AdmissionWebhook

引用kubernetes官方博客的一张图来说明MutatingAdmissionWebhook和ValidatingAdmissionWebhook所处的位置:

解释下这个过程：

1.api请求到达K8S API Server

2.请求要先经过认证（authentication），以确保用户身份是合法的

• kubectl调用需要kubeconfig
• 直接调用K8S api需要证书+bearToken
• client-go调用也需要kubeconfig

3.执行一连串的admission controller，包括MutatingAdmissionWebhook和ValidatingAdmissionWebhook, 先串行执行MutatingAdmission的Webhook list 4.对请求对象的schema进行校验 5.并行执行ValidatingAdmission的Webhook list 6.最后写入etcd

1.9 operator

        operator 是描述、部署和管理 kubernetes 应用的一套机制，⽤来扩展Kubernetes API，从实现上来说，可以将其理解为 CRD 配合可选的 webhook 与 controller 来实现用户业务逻辑，即 operator = CRD + webhook + controller。

        这其实与k8s内置的资源是一致一模一样的，

比如deployment API = deployment 资源+deployment 控制器。

        开发operator的脚手架：operator-sdk 和 kubebuilder。

         例如：Kubebuilder可以生成基本的CRD，控制器代码和Webhook模板代码。

---

         ps: ⽬前开发operator来扩展 Kubernetes 的 API 的⽅式有创建 CRD、使⽤ Operator SDK 等⽅式，都需要写很多的样本⽂件（boilerplate），使⽤起来⼗分麻烦。为了能够更⽅便构建
Kubernetes API 和⼯具，就需要⼀款能够事半功倍的⼯具，与其他 Kubernetes API
扩展⽅案相⽐，kubebuilder 更加简单易⽤，并获得了社区的⼴泛⽀持。

---

   常见的 operator 工作模式

工作流程：

• 用户创建一个自定义资源 (CRD)；
• apiserver 根据自己注册的一个 pass 列表，把该 CRD 的请求转发给 webhook；
• webhook 一般会完成该 CRD 的缺省值设定和参数检验。webhook 处理完之后，相应的 CR 会被写入etcd，返回给用户。
• 与此同时，controller 会在后台监测该自定义资源，按照业务逻辑，处理与该自定义资源相关联的特殊操作；
• 上述处理一般会引起集群内的状态变化，controller 会监测这些关联的变化，把这些变化记录到 CRD 的状态中。