图解kubernetes中的api多版本机制实现

在web开发中随着版本的更新迭代,一般要在系统中维护多个版本的api,多个版本的api在数据结构上每每也各不相同,今天就来一块儿学习下kubernetes中的Scheme机制是如何解决这个问题的,如何借助HTTP请求里面的数据进行反序列化操做

1. web请求的处理流程

1.1 HTTP请求处理流程

一般首先是webServer先进行Http协议的处理,而后解析成基础的webServer内部的一个Http请求对象, 一般该对象持有对应请求的请求头和底层对应的字节序列(从socket流中读取)
接着首先会一般根据对应的编码格式来进行反序列化，完成从字节序列到当前接口的业务模型的映射, 而后在交给业务逻辑处理，从而最终进行持久化存储, 本文的重点也就在反序列化部分

2.模型映射的实现

2.1 描述资源版本信息

/api/{version}/{resource}/{action}

上面是一个基础的web url一般咱们都会为每一个版本注册一个对应的URL, 其中会包含很关键的两个信息即version与resource,经过这两个信息,一般咱们就能够知道这多是某个资源的那个版本, 若是咱们把后面的action也包裹进来,咱们一般就能够知道对应的资源的那个具体操做

2.2 Group组信息

在微服务流行的今天咱们一般会为按照业务功能来进行微服务的切分，本质上一个微服务可能就是实现某个具体业务场景的功能集合，好比用户系统一般会包含用户的全部相关操做，在kubernetes中也有相似的概念就是所谓的Group

POST /apis/batch/v1beta1/namespaces/{namespace}/cronjobs
POST /apis/apps/v1/namespaces/{namespace}/daemonsets

咱们来看一个实例这是一个建立daemonsets和cronjobs的url, 若是按照Group、resource、version来进行拆分能够拆成以下：batch、v1beta一、cronjobs和apps、v一、daemonsets，也就是你们尝试的GroupVersionKind,其中kind对应的就是resource

2.3 模型映射的实现

咱们经过url里面获取到资源的GroupVersionKind信息，如何将其映射为一个具体的类型呢？ 这貌似就很简单告终合反射和map来进行就能够了，咱们经过url获取到对应想的GVK信息，而后在经过咱们的映射表，就知道对应的模型是哪一个，接下来就只须要进行转换就好了

gvkToType map[schema.GroupVersionKind]reflect.Type

3.反序列化实现

3.1 解码机制

那如何将对应的Http里面的数据流反序列化成内部的一个对象呢，别忘记了是Http协议, 确定就是header头里面的信息了，咱们经过header头里面的序列化就能够知道对应的编码格式，只须要调用对应格式的解码就能够完成了

Content-Type: "application/json"

3.2 默认对象

若是要将json格式的字节数组进行解码一般要进行以下操做，咱们须要传入一个目标对象的指针，而后由json将对应的字节数据解析到目标对象中，咱们也须要这样一个对象，用于存储反序列化的结果

func Unmarshal(data []byte, v interface{}) error {}

那只要我再提供一个当前版本对应的对象构造函数是否是就能够呢？答案是的

func() Object{ return 目标对象 },

4. 设计总结

首先在进行url注册的时候，咱们构造出对应url映射的资源的版本信息即GroupVersionKind,后续的不少操做咱们能够经过对应的版本映射获取对应的目标操做或者对象,而后再经过Header里面的字段获取对应的解码器,并将Body里面的字节序列进行解码到目标对象，就能够实现多版本资源的映射和反序列化操做了

kubernetes学习笔记地址: https://www.yuque.com/baxiaoshi/tyado3