Kubernetes 物件

Kubernetes 物件是 Kubernetes 系統中的持久性實體。Kubernetes 使用這些實體來表示叢集的狀態。了解 Kubernetes 物件模型以及如何使用這些物件。

本頁說明 Kubernetes 物件如何在 Kubernetes API 中表示，以及您如何在 .yaml 格式中表達它們。

了解 Kubernetes 物件

Kubernetes 物件是 Kubernetes 系統中的持久性實體。Kubernetes 使用這些實體來表示叢集的狀態。具體來說，它們可以描述：

哪些容器化應用程式正在執行 (以及在哪些節點上)
這些應用程式可用的資源
關於這些應用程式行為的策略，例如重新啟動策略、升級與容錯能力

Kubernetes 物件是「意圖記錄」——一旦您建立物件，Kubernetes 系統將不斷努力確保物件存在。透過建立物件，您實際上是在告訴 Kubernetes 系統您希望叢集的工作負載看起來像什麼；這是您叢集的期望狀態。

若要使用 Kubernetes 物件——無論是建立、修改或刪除它們——您都需要使用 Kubernetes API。例如，當您使用 kubectl 命令列介面時，CLI 會為您進行必要的 Kubernetes API 呼叫。您也可以在您自己的程式中使用客戶端函式庫之一，直接使用 Kubernetes API。

物件規格與狀態

幾乎每個 Kubernetes 物件都包含兩個巢狀物件欄位，用於管理物件的組態：物件spec 與物件status。對於具有 spec 的物件，您必須在建立物件時設定此欄位，提供您希望資源擁有的特性描述：其期望狀態。

status 描述物件的目前狀態，由 Kubernetes 系統及其元件提供與更新。Kubernetes 控制平面持續且主動地管理每個物件的實際狀態，以符合您提供的期望狀態。

例如：在 Kubernetes 中，Deployment 是一個可以代表在您的叢集上執行的應用程式的物件。當您建立 Deployment 時，您可以設定 Deployment spec 以指定您希望應用程式的 3 個副本正在執行。Kubernetes 系統讀取 Deployment 規格並啟動您期望的應用程式的 3 個實例——更新狀態以符合您的規格。如果這些實例中的任何一個失敗 (狀態變更)，Kubernetes 系統會透過進行更正來回應規格與狀態之間的差異——在本例中，啟動一個替換實例。

有關物件規格、狀態和中繼資料的更多資訊，請參閱 Kubernetes API 慣例。

描述 Kubernetes 物件

當您在 Kubernetes 中建立物件時，您必須提供描述其期望狀態的物件規格，以及關於物件的一些基本資訊 (例如名稱)。當您使用 Kubernetes API 建立物件時 (直接或透過 kubectl)，該 API 請求必須在請求本文中包含 JSON 格式的資訊。大多數情況下，您在稱為manifest 的檔案中將資訊提供給 kubectl。依照慣例，manifest 是 YAML 格式 (您也可以使用 JSON 格式)。當透過 HTTP 發出 API 請求時，諸如 kubectl 之類的工具會將 manifest 中的資訊轉換為 JSON 或其他支援的序列化格式。

這是一個範例 manifest，顯示 Kubernetes Deployment 的必要欄位與物件規格：

application/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 # tells deployment to run 2 pods matching the template
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

使用如上所示的 manifest 檔案建立 Deployment 的一種方法是使用 kubectl 命令列介面中的 kubectl apply 命令，並將 .yaml 檔案作為引數傳遞。以下是一個範例：

kubectl apply -f https://k8s.io/examples/application/deployment.yaml

輸出類似於這樣：

deployment.apps/nginx-deployment created

必要欄位

在您想要建立的 Kubernetes 物件的 manifest (YAML 或 JSON 檔案) 中，您需要為以下欄位設定值：

apiVersion - 您用於建立此物件的 Kubernetes API 版本
kind - 您想要建立的物件類型
metadata - 協助唯一識別物件的資料，包括 name 字串、UID 與可選的 namespace
spec - 您期望物件處於何種狀態

物件 spec 的精確格式對於每個 Kubernetes 物件都不同，並且包含特定於該物件的巢狀欄位。Kubernetes API 參考文件可以協助您找到您可以使用 Kubernetes 建立的所有物件的規格格式。

例如，請參閱 Pod API 參考文件中 spec 欄位的說明。對於每個 Pod，.spec 欄位會指定 Pod 及其期望狀態（例如該 Pod 中每個容器的容器映像檔名稱）。物件規格的另一個範例是 StatefulSet API 的 spec 欄位。對於 StatefulSet，.spec 欄位會指定 StatefulSet 及其期望狀態。在 StatefulSet 的 .spec 中，有一個用於 Pod 物件的範本。該範本描述 StatefulSet 控制器將建立的 Pod，以滿足 StatefulSet 規格。不同種類的物件也可能具有不同的 .status；同樣地，API 參考頁面詳細說明了 .status 欄位的結構，以及每種不同物件類型的內容。

注意

有關撰寫 YAML 組態檔的更多資訊，請參閱組態最佳實務。

伺服器端欄位驗證

從 Kubernetes v1.25 開始，API 伺服器提供伺服器端欄位驗證，可偵測物件中無法辨識或重複的欄位。它提供伺服器端 kubectl --validate 的所有功能。

kubectl 工具使用 --validate 旗標來設定欄位驗證的層級。它接受值 ignore、warn 和 strict，同時也接受值 true（相當於 strict）和 false（相當於 ignore）。kubectl 的預設驗證設定為 --validate=true。

Strict（嚴格）: 嚴格欄位驗證，驗證失敗時會產生錯誤
Warn（警告）: 執行欄位驗證，但錯誤會以警告形式呈現，而不是使請求失敗
Ignore（忽略）: 不執行伺服器端欄位驗證

當 kubectl 無法連線到支援欄位驗證的 API 伺服器時，它將退回使用用戶端驗證。Kubernetes 1.27 及更高版本始終提供欄位驗證；較舊的 Kubernetes 版本可能不提供。如果您的叢集版本低於 v1.27，請查看您的 Kubernetes 版本的文件。

下一步

如果您是 Kubernetes 新手，請閱讀更多關於以下內容的資訊

Pod，它們是最重要的基本 Kubernetes 物件。
Deployment 物件。
Kubernetes 中的控制器。
kubectl 和 kubectl 命令。

Kubernetes 物件管理說明如何使用 kubectl 管理物件。如果您還沒有 kubectl，您可能需要安裝 kubectl。

若要瞭解 Kubernetes API 的一般資訊，請造訪

Kubernetes API 概觀

若要更深入瞭解 Kubernetes 中的物件，請閱讀本節中的其他頁面

上次修改時間：2024 年 8 月 25 日下午 8:24 PST：重新排序概觀頁面 (42da717f16)