共計 3037 個字符，預計需要花費 8 分鐘才能閱讀完成。
如何理解 Kubernetes API，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面丸趣 TV 小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。
Kubernetes 把其管理的資源均視為 API 對象，并對外提供 REST 風格的 API 來操縱這些對象。Kubernetes API 由 kube-apiserver 組件提供，Kubernetes 內部各組件與 kube-apiserver 通信也是使用 API 來驅動的，除此之外，命令行工具比如 kubectl 以及各種 Kubernetes 客戶端程序均是使用 API 與 Kubernetes 通信。
API 格式
Kubernetes API 格式為 prefix/group/version/resource，比如表示 Deployment 資源列表的 API 為 /apis/apps/v1/deployments，其中 apis 表示前綴，apps 表示 API 組，v1 表示 API 組的版本，deployments 表示資源名稱，如下圖所示：
API 前綴
API 中的前綴無疑會增加 URL 的長度，這不由得會讓我們思考以下幾個問題：
前綴存在的意義是什么呢？
Kubernetes API 都有哪些前綴？
要回答這個問題就要從 API 的定義來說起，API 英文全稱是 Application Programming Interface，即應用程序編程接口。那么從廣義上說，Kubernetes 的 kube-apiserver 組件對外暴露的所有端點都可以稱作 API，比如：
/api/v1 ,
/apis/admissionregistration.k8s.io ,
/apis/apps ,
/apis/authentication.k8s.io ,
/healthz ,
/livez ,
/metrics ,
/version
應用程序可以使用這些接口來實現特定的功能，比如使用 /api/v1 或 apis/apps 接口來創建資源，使用 /healthz 來查詢集群健康狀態，所以這些接口都是 API。
但是，往往我們所說的 Kubernetes API 是狹義上的概念，即專指那些表示 Kubernetes 資源的 API，所以為了與其他 API 有所區分，Kubernetes 特意加了 api 前綴，該前綴表示這些 API 用于管理 Kubernetes 資源。
用于管理 Kubernetes 資源的 API 前綴除了 api 外，還有 apis，在 Kubernetes 早期的設計中，只有 api 前綴，后來為了引入 API 組的設計，又添加了 apis 前綴，簡單地說，使用 api 前綴的 API 是 Kubernetes 最核心的一組 API，而使用 apis 前綴的 API 是 Kubernetes 發展過程中引入的分組 API。
API 組
前文提到 Kubernetes 早期只有以 api 為前綴的 API，這些 API 提供了 Kubernetes 最核心的功能。隨著 Kubernetes 的不斷演進，Kubernetes 需要引入更過的功能，也即需要提供更多的 API，這不僅給 Kubernetes 帶來了沉重的負擔，也給用戶帶了困擾。
一方面，隨著 Kubernetes 提供的功能增多，Kubernetes 自身開發和維護難度越來越大，另一方面，用戶往往只需要 Kubernetes 提供的部分功能。所以為了使 Kubernetes 更容易擴展和演進，同時可以讓用戶有選擇性地開啟和關閉非核心功能，Kubernetes 設計者們提出了 API 分組的理念。
所謂 API 分組理念是指把 Kubernetes 的 API 按照功能分組，該理念被提出時 Kubernetes 已經有了以 api 為前綴的一組核心 API，考慮到兼容策略，這組 API 不適宜修改，所以 API 分組實際上針對非核心的擴展 API，后續新加的功能統一使用 apis 為前綴，并把 API 按組區分，部分 API 組如下所示：
/apis/apps
/apis/autoscaling
/apis/rbac.authorization.k8s.io
...出現在前綴 apis 后面的就是 API 組，比如 apps 表示一組用于應用管理的 API，autoscaling 表示一組用于應用自動擴展的 API，rbac.authorization.k8s.io 表示一組用于基于角色控制的 API。
把 API 分組最大的好處在于用戶可以自由地開啟和關閉相應的非核心功能。用戶可以使用 kube-apiserver 組件提供的 –runtime-config 參數來顯式地控制某項功能是否開啟。比如：
--runtime-config=autoscaling/v1=false,rbac.authorization.k8s.io/v1=true上面的配置顯式地將 autoscaling 功能關閉，同時把 rbac.authorization.k8s.io 功能開啟。需要說明的是，相當大一部分 API 組默認是開啟的，比如默認情況下 rbac.authorization.k8s.io 這組 API 是開啟的，這意味著上面配置中 rbac.authorization.k8s.io/v1=true 是多余的，出現在本例中僅用于說明 API 組可以顯式地控制開啟和關閉。
把 API 分組另一非常重要的好處在于，它可以給每組 API 按照功能成熟度劃分成不同的版本，比如 v1alpha1，v1beta1，v1 等。
API 版本
每組 API 都有相應的版本表示其成熟度，比如 autoscaling 就有多個版本：
/apis/autoscaling/v1 ,
/apis/autoscaling/v2beta1 ,
/apis/autoscaling/v2beta2 ,為 API 提供版本并且多版本共存的意義在于為用戶提供清晰的成熟度參考，比如版本名包含 alpha 表示該功能正在實驗過程中，不推薦應用在生產環境中，因此 Kubernetes 默認不會開啟這些功能，版本名包含 beta 表示該功能基本可用，希望用戶嘗試并提供反饋，因此 Kubernetes 往往默認啟用這些功能，版本名為 vx 表示功能已固定，相應的 API 也不會再修改，用戶可以放心使用。
為 API 分組同時為每個 API 提供多個版本，這允許每組功能可以不同的速度演進，而不必互相影響。
了解一個應用的功能，從 API 入手往往能快速地掌握住該應用的概況，包括它是什么，它能用來做什么以及怎么使用它。本節簡要地介紹了 Kubernetes 的 API 設計，借此讀者可以從宏觀上對 Kubernetes API 有個基本的了解，為將來詳細了解每個功能點，也就是每個具體的 API 打下基礎。
Kubernetes API 的分組設計為其提供了無限的擴展能力，借此機制可以輕松地為 Kubernetes 提供擴展功能，用戶不僅可以使用 CRD（Custom Resource Definition）功能來提供新的 API，還可以通過擴展 apiserver 來擴展功能。
前文也提到，提出 API 分組理念以前，Kubernetes 就存在了以 api 為前綴的一組 API，這了保持兼容性，這組核心 API 并沒有劃分到特定的組，它的 API 格式則是 prefix/version/resource（少了 group 名字），比如 /api/v1/Pods。通常我們在說 API 版本時往往是指 group/version，即帶上組名和版本，為了描述上的方便，社區開發者日常交流時往往稱這組特別的 API 為 core 組。
看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注丸趣 TV 行業資訊頻道，感謝您對丸趣 TV 的支持。
