Kubernetes 源碼分析之resource和API

作者：TA碼字 2022-01-06 07:06:52

云計算 在 kubernetes 的世界里對各種 resoure 的操作都是基于 API 來完成的，kubernetes 提供了一系列的 RESTfull API 來完成對 resource 的基本操作。

10年的惠民網(wǎng)站建設(shè)經(jīng)驗，針對設(shè)計、前端、開發(fā)、售后、文案、推廣等六對一服務(wù)，響應(yīng)快，48小時及時工作處理。成都全網(wǎng)營銷推廣的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動調(diào)整惠民建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計，從而大程度地提升瀏覽體驗。成都創(chuàng)新互聯(lián)公司從事“惠民網(wǎng)站設(shè)計”,“惠民網(wǎng)站推廣”以來，每個客戶項目都認真落實執(zhí)行。

 本文是一個系列文章，以學習為目的，對 kubernetes 源碼進行分析，意在可以更好的去理解 kuberbetes 基本原理。

文章使用主分支(https://github.com/kubernetes/kubernetes)，主要介紹 kubernates 中相關(guān)組件。另外如果感興趣也可以參看 網(wǎng)絡(luò)系列文章 和 部署系列文章。

眾所周知 kubernetes 是基于 API 的 infrastructure，在此之上的 kubernetes 之中的概念都被抽象成各種 resource，不同的 resource 擁有不同的功能，例如我們熟悉并經(jīng)常使用的 deployment 資源， service 資源， configmap 資源， statefulset 資源， service account 資源等等。在 kubernetes 的世界里對各種 resoure 的操作都是基于 API 來完成的，kubernetes 提供了一系列的 RESTfull API 來完成對 resource 的基本操作。

對于 resource 來說基本上有兩個維度的劃分，一個是基于 namespace 的維度，還有一個是基于是否為核心 resource 的維度，首先我們看基于 namespace 的維度。

• 如果某一種 resource 實例是被定義在某一個 namespace 中的，既隸屬于 namespace 級別， 那么這個 resource 就可以看作是一個基于當前 namespace 的資源對象實例，例如我們常見的 deployment， service， pod 等等。
• 如果某一種 resource 實例是被定義在整個 kubernetes cluster 中的， 既隸屬于集群級別， 那么這個 resource 就可以看作是非 namesapce 的資源對象實例，例如我們常見的 node， cluster role， cluster role binding， persistent volume 等等。

接著從 resource 是否為核心資源的維度看，可以把其分為核心資源與非核心資源。

• 對于核心 resource 來說常見的有 pod, podtemplate, service, endpoint, configmap 等等，這些資源提供了 kubernetes 最基本的能力。例如 pod 提供計算能力，service 和 endpoint 提供網(wǎng)絡(luò)和訪問能力，configmap 提供配置能力。
• 非核心資源例如 deployment， statefulset， deamonset 等等提供更高級的功能。對于非核心資源來說 kubernetes 提供了基于 group 和 version 的管理概念，把不同的資源歸納為同一個組，在同一個組內(nèi)，同樣的資源又有不同 version。這樣對資源的組織和結(jié)構(gòu)，非常有利于 kubernetes 功能的演進和變化，即通過不同的 resource version 來演進和增強 resource 的能力。

因為 kubernetes 提供了標準的 RESTfull API，從 API 的角度看，基于以上不同維度各種 resource 的操作 API 模板可以如下：

• Item1 和 Item2 是對于核心 resource 的操作定義格式，都以 /api 為 uri path 前綴，對于核心 resource 來說并沒有 group 的概念，但是卻有 version 的概念，所以里面有 version 的 path 變量 ${version}。
• item1 為對基于 namespace 的核心 resource 的操作，所以定義里面有 namespace 的 path 變量 ${namespace-name}。
• item2 為對基于非 namespace 的核心 resource 的操作，所以定義里面并沒有 namespace 的 path 變量。
• item3 和 item4 為對非核心 resource 的操作定義，以 /apis 為 uri path 前綴。
• iems3 為對基于 namespace 的非核心 resource 的操作定義，所以訪問路徑里面就會有 group， version， namespace 三者的 path 變量定義， 即 ${group-name} 和 ${version} 以及 ${namespace-name}。
• items4 為基于整個cluster 的非核心 resource 的操作，所以定義里面就會有 group， version 的 path 變量 ${group-name} 和 ${version}，卻并沒有 namespace 的 path 變量。

另外我們一般對 kubernetes 資源的操作都是基于 YAML 格式的文件來進行(畢竟 YAML 文件相對于 human 來說更友好)，并不是直接基于 Restfull API 來操作資源，但是在 YAML 文件的背后卻是轉(zhuǎn)換成 RESTfull API，一般一個 YAML 文件的格式如下：

一般對于 resource 典型的 YAML 文件都會分為三個部分，type meta, object meta 還有 spec。

• type meta 里一般定義了 resource 的 group version 還有 kind 信息，和 API 訪問路徑里定義的 ${group-name} ${version} ${resource-kind} 等 path 變量直接對應(yīng)。
• object meta 里一般定義 resource 的名字，所屬的 namespace，以及 label 等元數(shù)據(jù)信息，會和 API 訪問路徑里的 ${namespace-name} 和 ${resource-name} 等 path 變量來直接對應(yīng)。
• spec 里一般就是定義這個 resource 具體的屬性和特性了(不同 resource spec 一定會有所不一樣)，會以 request body 的形式和 API 來對應(yīng)。

目前先我們寫到這里，在下一篇文章中我們繼續(xù)從源碼的角度來梳理 resource 中的 type meta，object meta 等關(guān)鍵信息的定義。

本文轉(zhuǎn)載自微信公眾號「TA碼字」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系TA碼字公眾號。

本文標題：Kubernetes 源碼分析之Resource和API
當前地址：http://fisionsoft.com.cn/article/djegcjo.html