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 來指定你希望執行三個應用程式副本。Kubernetes 系統讀取 Deployment 規格並啟動三個你想要的應用程式例項——更新狀態以匹配你的規格。如果任何這些例項失敗（狀態更改），Kubernetes 系統會透過進行糾正來響應規格和狀態之間的差異——在這種情況下，啟動一個替換例項。

有關物件規格、狀態和元資料的更多資訊，請參閱 Kubernetes API 約定。

描述 Kubernetes 物件

當你在 Kubernetes 中建立物件時，你必須提供描述其期望狀態的物件規格，以及一些關於物件的基本資訊（例如名稱）。當你使用 Kubernetes API 建立物件時（無論是直接還是透過 kubectl），該 API 請求必須在請求體中包含這些資訊作為 JSON。通常，你會在一個稱為清單的檔案中向 kubectl 提供資訊。按照慣例，清單是 YAML 格式（你也可以使用 JSON 格式）。像 kubectl 這樣的工具在透過 HTTP 發出 API 請求時，會將清單中的資訊轉換為 JSON 或其他支援的序列化格式。

這是一個顯示 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

使用像上面這樣的清單檔案建立 Deployment 的一種方法是使用 kubectl 命令列介面中的 kubectl apply 命令，並將 .yaml 檔案作為引數傳遞。示例如下：

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

輸出類似於：

deployment.apps/nginx-deployment created

必填欄位

在你想要建立的 Kubernetes 物件的清單（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 控制器將為了滿足 StatefulSet 規格而建立的 Pod。不同型別的物件也可以具有不同的 .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，可能需要安裝它。

要全面瞭解 Kubernetes API，請訪問：

Kubernetes API 概述

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

上次修改時間：2024 年 8 月 25 日太平洋標準時間晚上 8:24：重新排序概述頁面 (42da717f16)