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

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

眾所周知 kubernetes 是基于 API 的 infrastructure，在此之上的 kubernetes 之中的概念都被抽象成各種 resource，不同的 resource 擁有不同的功能，例如我們熟悉并經常使用的 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 提供網絡和訪問能力，configmap 提供配置能力。
• 非核心資源例如 deployment， statefulset， deamonset 等等提供更高級的功能。對于非核心資源來說 kubernetes 提供了基于 group 和 version 的管理概念，把不同的資源歸納為同一個組，在同一個組內，同樣的資源又有不同 version。這樣對資源的組織和結構，非常有利于 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 文件的背后卻是轉換成 RESTfull API，一般一個 YAML 文件的格式如下：

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

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

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

本文轉載自微信公眾號「TA碼字」，可以通過以下二維碼關注。轉載本文請聯系TA碼字公眾號。