圖解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、v1beta1、cronjobs和apps、v1、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