如何理解Kubernetes API

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

Kubernetes把其管理的資源均視為API對象，并對外提供REST風(fēng)格的API來操縱這些對象。Kubernetes API由kube-apiserver組件提供，Kubernetes內(nèi)部各組件與kube-apiserver通信也是使用API來驅(qū)動的，除此之外，命令行工具比如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的長度，這不由得會讓我們思考以下幾個(gè)問題：

• 前綴存在的意義是什么呢？

• Kubernetes API都有哪些前綴？

要回答這個(gè)問題就要從API的定義來說起，API英文全稱是Application Programming Interface，即應(yīng)用程序編程接口。那么從廣義上說，Kubernetes 的kube-apiserver組件對外暴露的所有端點(diǎn)都可以稱作API，比如：

"/api/v1",
"/apis/admissionregistration.k8s.io",
"/apis/apps",
"/apis/authentication.k8s.io",
"/healthz",
"/livez",
"/metrics",
"/version"

應(yīng)用程序可以使用這些接口來實(shí)現(xiàn)特定的功能，比如使用/api/v1或apis/apps接口來創(chuàng)建資源，使用/healthz來查詢集群健康狀態(tài)，所以這些接口都是API。

但是，往往我們所說的Kubernetes API是狹義上的概念，即專指那些表示Kubernetes資源的API，所以為了與其他API有所區(qū)分，Kubernetes特意加了api前綴，該前綴表示這些API用于管理Kubernetes資源。

用于管理Kubernetes資源的API前綴除了api外，還有apis，在Kubernetes早期的設(shè)計(jì)中，只有api前綴，后來為了引入API組的設(shè)計(jì)，又添加了apis前綴，簡單地說，使用api前綴的API是Kubernetes最核心的一組API，而使用apis前綴的API是Kubernetes發(fā)展過程中引入的分組API。

API組

前文提到Kubernetes早期只有以api為前綴的API，這些API提供了Kubernetes最核心的功能。隨著Kubernetes的不斷演進(jìn)，Kubernetes需要引入更過的功能，也即需要提供更多的API，這不僅給Kubernetes帶來了沉重的負(fù)擔(dān)，也給用戶帶了困擾。

一方面，隨著Kubernetes提供的功能增多，Kubernetes自身開發(fā)和維護(hù)難度越來越大，另一方面，用戶往往只需要Kubernetes提供的部分功能。所以為了使Kubernetes更容易擴(kuò)展和演進(jìn)，同時(shí)可以讓用戶有選擇性地開啟和關(guān)閉非核心功能，Kubernetes設(shè)計(jì)者們提出了API分組的理念。

所謂API分組理念是指把Kubernetes的API按照功能分組，該理念被提出時(shí)Kubernetes已經(jīng)有了以api為前綴的一組核心API，考慮到兼容策略，這組API不適宜修改，所以API分組實(shí)際上針對非核心的擴(kuò)展API，后續(xù)新加的功能統(tǒng)一使用apis為前綴，并把API按組區(qū)分，部分API組如下所示：

"/apis/apps"
"/apis/autoscaling"
"/apis/rbac.authorization.k8s.io"
...

出現(xiàn)在前綴apis后面的就是API組，比如apps表示一組用于應(yīng)用管理的API，autoscaling表示一組用于應(yīng)用自動擴(kuò)展的API，rbac.authorization.k8s.io表示一組用于基于角色控制的API。

把API分組最大的好處在于用戶可以自由地開啟和關(guān)閉相應(yīng)的非核心功能。用戶可以使用kube-apiserver組件提供的--runtime-config參數(shù)來顯式地控制某項(xiàng)功能是否開啟。比如：

--runtime-config=autoscaling/v1=false,rbac.authorization.k8s.io/v1=true

上面的配置顯式地將autoscaling功能關(guān)閉，同時(shí)把rbac.authorization.k8s.io功能開啟。需要說明的是，相當(dāng)大一部分API組默認(rèn)是開啟的，比如默認(rèn)情況下rbac.authorization.k8s.io這組API是開啟的，這意味著上面配置中rbac.authorization.k8s.io/v1=true是多余的，出現(xiàn)在本例中僅用于說明API組可以顯式地控制開啟和關(guān)閉。

把API分組另一非常重要的好處在于，它可以給每組API按照功能成熟度劃分成不同的版本，比如v1alpha1，v1beta1，v1等。

API版本

每組API都有相應(yīng)的版本表示其成熟度，比如autoscaling就有多個(gè)版本：

"/apis/autoscaling/v1",
"/apis/autoscaling/v2beta1",
"/apis/autoscaling/v2beta2",

為API提供版本并且多版本共存的意義在于為用戶提供清晰的成熟度參考，比如版本名包含alpha表示該功能正在實(shí)驗(yàn)過程中，不推薦應(yīng)用在生產(chǎn)環(huán)境中，因此Kubernetes默認(rèn)不會開啟這些功能，版本名包含beta表示該功能基本可用，希望用戶嘗試并提供反饋，因此Kubernetes往往默認(rèn)啟用這些功能，版本名為vx表示功能已固定，相應(yīng)的API也不會再修改，用戶可以放心使用。

為API分組同時(shí)為每個(gè)API提供多個(gè)版本，這允許每組功能可以不同的速度演進(jìn)，而不必互相影響。

了解一個(gè)應(yīng)用的功能，從API入手往往能快速地掌握住該應(yīng)用的概況，包括它是什么，它能用來做什么以及怎么使用它。本節(jié)簡要地介紹了Kubernetes的API設(shè)計(jì)，借此讀者可以從宏觀上對Kubernetes API有個(gè)基本的了解，為將來詳細(xì)了解每個(gè)功能點(diǎn)，也就是每個(gè)具體的API打下基礎(chǔ)。

Kubernetes API的分組設(shè)計(jì)為其提供了無限的擴(kuò)展能力，借此機(jī)制可以輕松地為Kubernetes提供擴(kuò)展功能，用戶不僅可以使用CRD（Custom Resource Definition）功能來提供新的API，還可以通過擴(kuò)展apiserver來擴(kuò)展功能。

前文也提到，提出API分組理念以前，Kubernetes就存在了以api為前綴的一組API，這了保持兼容性，這組核心API并沒有劃分到特定的組，它的API格式則是prefix/version/resource（少了group名字），比如/api/v1/Pods。通常我們在說API版本時(shí)往往是指group/version，即帶上組名和版本，為了描述上的方便，社區(qū)開發(fā)者日常交流時(shí)往往稱這組特別的API為core組。

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