如何分析kubernetes中的api聚合机制设计

70次阅读
没有评论

共计 2125 个字符,预计需要花费 6 分钟才能阅读完成。

丸趣 TV 小编今天带大家了解如何分析 kubernetes 中的 api 聚合机制设计,文中知识点介绍的非常详细。觉得有帮助的朋友可以跟着丸趣 TV 小编一起浏览文章的内容,希望能够帮助更多想解决这个问题的朋友找到问题的答案,下面跟着丸趣 TV 小编一起深入学习“如何分析 kubernetes 中的 api 聚合机制设计”的知识吧。

kubernetes 中 apiserver 的设计无疑是复杂的, 其自身内部就包含了三种角色的 api 服务, 今天我们一起来臆测下其内部的设计, 搞明白 aggregator、apiserver、apiExtensionsServer(crd server)的设计精要

 1. 从 web 服务到 web 网关到 CRD

apiserver 还是蛮复杂的,今天我们只讨论其 kube-aggregator/apiserver/apiextensions 三者架构上的设计,而不关注诸如请求认证、准入控制、权限等等

 1.1 最基础的 REST 服务

一个最基础的 Rest 服务通常会包括一个 resource 资源和一组 HTTP 请求的方法, 在 kubernetes 中被称为一个 REST,其内部还内嵌了一个 Store(可以理解为继承),其提供了针对某个具体资源的所有操作的集合,也就是我们常说的最终执行 CRUD 的具体操作的实现

 1.2 Service

我们有了 Rest 就可以提供各种 k8s 中资源的管理,但是如果我要进行扩展呢,如果要支持一些外部的资源 k8s 中不存在,最简单的方式肯定就是在外部独立一个服务了,由这个服务自己管理数据存储、变更、控制等等逻辑

 1.3 APIAggregator

当通过外部服务来进行集群资源扩展的时候,针对这类资源我们如何集成到当前的 apiserver 中呢?为此 k8s 中设计了 APIAggregator 组件(其实 APIAggreator 组件还包括代理后端服务等功能),来实现外部服务的集成,这样开发人员不用修改 k8s 代码,也可以来自定义服务信息

 1.4 一个服务的基本功能

一个基础的业务服务通常包含数据模型、控制逻辑、持久化存储、基础功能 (认证、监控、日志等等) 等等,为了要创建一个服务,我们通常需要如下操作 (不包含设计阶段):1) 选择合适的框架 (完成基础功能) 2) 定义数据模型 3)选择数据存储 4)编写业务控制逻辑,这里面除了业务控制逻辑,其余部分在大多数情况下可能都是通用,比如框架、数据存储这些,那能不能简化下?来看大招 CRD

 1.5 CustomResourceDefinitions

CRD 中文被称为自定义资源类型,其核心在 k8s 中提供数据模型定义、数据存储、基础功能,这样如果我们要扩展服务就只需要编写一个业务逻辑控制器即可,我们思考下其场景

通常 web 请求的处理流程都是反序列化、验证字段、业务逻辑处理、数据存储,而在 k8s 中业务控制逻辑大多数由 controller 来进行,那为了支持 CRD 剩余工作肯定也是在 k8s 中完成的

在我们完成定义模型之后,k8s 的 crd 模块需要进行对应资源 REST 的构建、验证、转换、存储等操作这些无疑都是耗费资源的,而且在 apiserver 这种数据总线上,由此可以发行 CRD 并不支持大规模的数据存储  

 1.6 CRD server

CRDServer 主要就是负责 CRD 资源的管理,其会监听 CRD 资源的变更,并且为其创建对应的 REST 接口,完成对应的认证、转换、验证、存储等机制

 2. ServerChan

ServerChan 从设计上更类似一种责任链的模式,简单来说如果我处理不了该请求,我就交给下个人处理,这种操作在 k8s 中被称为 delegate(委托), 接下来我们开始了解其关键实现

 2.1 服务的角色划分

到目前我们已经有了三个 server, 其中 APIAggregator 负责外部服务的集成和内部请求的转发,apiserver 服务 k8s 汇总内部资源的控制,CRDServer 则负责用户自定义资源的处理,然后我们就只需要将三者串联起来,就是我们最终的 apiserver

 2.2 责任链上的层层委托

当 APIAggregator 接收到请求之后,如果发现对应的是一个 service 的请求,则会直接转发到对应的服务上否则则委托给 apiserver 进行处理,apiserver 中根据当前 URL 来选择对应的 REST 接口处理,如果未能找到对应的处理,则会交由 CRD server 处理,CRD server 检测是否已经注册对应的 CRD 资源,如果注册就处理

 2.3 APIAggregator 上的服务注册

APIAggreagtor 中会通过 informer 监听后端 Service 的变化,如果发现有新的服务,就会创建对应的代理转发,从而实现对应的服务注册

 2.4 CRD Server 中的资源感知

当在集群中创建了对应的 CRD 资源的时候,会通过内部的 controller 来感知对应的 CRD 资源信息,然后为其创建对应的 REST 处理接口,这样后续接收到对应的资源就可以进行处理了  

 3. 基础概览图

感谢大家的阅读,以上就是“如何分析 kubernetes 中的 api 聚合机制设计”的全部内容了,学会的朋友赶紧操作起来吧。相信丸趣 TV 丸趣 TV 小编一定会给大家带来更优质的文章。谢谢大家对丸趣 TV 网站的支持!

正文完
 
丸趣
版权声明:本站原创文章,由 丸趣 2023-08-03发表,共计2125字。
转载说明:除特殊说明外本站除技术相关以外文章皆由网络搜集发布,转载请注明出处。
评论(没有评论)