在k8s中，使用者和k8s元件都利用k8s API進行操作物件來與k8s進行互動。
這些物件代表了整個k8s的設定。 它們包括在k8s中運行的應用程式、k8s的設定、在k8s內部或外部暴露物件的負載平衡器、底層server和這些應用程序所使用的存儲、用戶和應用程式的安全權限以及許多其他細節基礎設施。
圖4.1 利用操作k8s API中的物件來設定k8s叢集
Kubernetes API是與叢集互動的中心點。
k8s API是一個基於HTTP的RESTful API，其中狀態由您對資源使用標準HTTP方法(例如：POST、GET、PUT/PATCH或DELETE)執行對應的CRUD操作(建立、讀取、更新、刪除)所表示。
正是這些資源(或物件)代表了叢集的設定。因此，將應用程式部署到叢集中的叢集管理者和工程師利用操作這些物件來影響設定。
在k8s社區中，術語“資源”和“物件”可以互換使用，但有一些細微的差異需要解釋。
RESTful API中的基本概念是資源resource，每個資源都分配有唯一標識它的URI或Uniform Resource Identifier。例如：在k8s API中，應用程式部署由deployment資源表示。
k8s中所有deployment集合是一個REST資源暴露在/api/v1/deployments。當您使用GET方法向此URI發送HTTP請求時，您會收到一個列出k8s中所有deployment實例的回應。
每個單獨的deployment實例也有自己唯一的URI，透過此URI可以對某個deployment進行操作。
因此，單個deployment當作另一個REST資源公開。您可以利用向資源URI發送GET請求來檢索有關deployment的資訊，並且可以使用PUT請求對deployment進行修改。
圖4.2 單個物件可以被兩個或多個資源公開
因此，一個物件可以透過多個資源公開。
如圖4.2所示，名稱為mydeploy的Deployment物件實例將兩種方式返回：(1)當你查詢deployments資源將返回元素集合，(2)當你直接查詢單獨個別的資源URI時將返回單個物件。
此外，如果一個物件有多個API版本存在，也可以透過多個資源來暴露一個單一物件實例。
直到k8s 1.15版本 ，API暴露Deployment物件兩種不同的表示。
除了apps/v1版本暴露在/apis/apps/v1/deployments以外，API還提供另一個舊版的extensions/v1beta1暴露在/apis/extensions/v1beta1/deployments。
這兩個資源並不代表兩組不同的Deployment物件，而是一組物件用兩種方式表現 → 物件schema的細微差別。 您可以利用第一種URI建立一個Deployment物件的實例，然後使用第二種URI讀取。
在某些情況下，資源根本不代表任何物件。
這方面的一個範例的方式就是k8s API允許客戶端驗證subject(人或服務)是否被授權執行API操作。
這是透過向/apis/authorization.k8s.io/v1/subjectaccessreviews資源提交POST請求來完成的。
回應指示subject是否被授權執行請求內容中指定的操作。這裡的關鍵是POST請求並沒有建立任何物件。
上面描述的範例展示了資源與物件的不同。如果您熟悉關聯式資料庫系統，則可以將資源和物件類型 vs 視圖和資料表進行比較。資源是您與物件互動的視圖。
當您GET請求一個資源時，k8s API Server會以結構化文字形式返回物件。預設是JSON，但您也可以告訴server返回YAML。
當您使用POST或者PUT請求更新物件時，也可以使用 JSON 或 YAML 指定新狀態。
物件manifest中的各種(欄位/關鍵字/字段)取決於物件類型，但一般結構和許多(欄位/關鍵字/字段)都是被所有k8s API物件一起共用。