如何理解Kubernetes API

如何理解Kubernetes API，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

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組。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。