借助 Kubernetes 標簽，DevOps 團隊可以更快地解決問題、集中應用配置更改并快速響應問題。標簽還可以讓您深入了解成本，提高您的監控、分配和管理能力。在使用標簽時遵循最佳實踐可幫助您從基礎架構可見性和高效運營中獲得巨大收益。

以下是您需要了解的有關 Kubernetes 標簽的所有信息 - 它們是什么、它們如何工作、何時使用它們，以及構建可靠標簽策略應遵循的 10 條最佳實踐。

什么是 Kubernetes 標簽?

Kubernetes 標簽是將標識元數據鏈接到 Kubernetes 對象的鍵值字符串對。Kubernetes 為團隊提供了集成支持，可以使用標簽從 Kubernetes API 中檢索和過濾數據，并對所選對象進行批量操作。

許多團隊使用 Kubernetes 標簽為 DevOps 提供有關節點、Pod 或其他 Kubernetes 對象的所有權的信息，以便于跟蹤和運營決策制定。

創建新標簽時，您必須遵守 Kubernetes 對長度和允許值的限制。標簽值必須：

• 包含 63 個字符或更少(標簽的值也可以為空)，
• 以字母數字字符開頭和結尾(除非它為空)，
• 僅包含破折號 (-)、下劃線 (_)、點 (.) 和字母數字。

您可以使用 找到 Kubernetes 對象具有的標簽kubectl。例如，要獲取名為 的 pod 的所有標簽pod1，您可以運行：

> kubectl get pod1 -o json | jq .metadata.labels

要創建標簽，您可以在配置文件規范的metadata.labels對象中指定它們。讓我們考慮pod.yaml描述單個 pod 的文件：

apiVersion: v1kind: Podmetadata: name: nginx labels: environment: dev 
critical: "true"spec: containers: - image: nginx name: nginx resources: 
requests: cpu: 500m

請注意，critical標簽的值是“true”而不是true。這是因為標簽及其值必須是字符串。

讓我們應用配置文件：

> kubectl apply -f pod.yamlpod/nginx created

您現在可以使用 直接在已經存在的 Kubernetes 對象上應用或覆蓋標簽kubectl。首先，獲取 pod 具有的所有標簽：

> kubectl get pod nginx -o json | jq .metadata.labels{ "critical": "true", 
"environment": "dev"}

現在，要更改environment標簽的值并添加新的鍵值標簽對deprecated=true，我們執行以下命令：

> kubectl label pod nginx environment=prod --overwritepod/nginx 
labeled> kubectl label pod nginx deprecated=truepod/nginx labeled

–overwrite請記住，除非您明確地用標志覆蓋它，否則不允許更新標簽的值。生成的標簽如下：

> kubectl get pod nginx -o json | jq .metadata.labels{ "deprecated": 
"true", "critical": "true", "environment": "prod"}

Kubernetes 標簽與注解

Kubernetes 提供了兩種將元數據與對象連接起來的策略：標簽和注釋。

注釋是將非標識元數據與對象連接起來的鍵值對。例如，注釋可以包含給定資源的日志記錄或監視信息。

標簽和注解的主要區別在于注解不用于過濾、分組或操作 Kubernetes 資源。相反，您可以使用它們來訪問有關它的其他信息。

例如之前部署的pod已經調度到的節點注解如下：

> kubectl get node demo-node -o json | jq .metadata.annotations{ 
"kubeadm.alpha.kubernetes.io/cri-socket": "unix:///var/run/cri-dockerd.sock", 
"node.alpha.kubernetes.io/ttl": "0", 
"volumes.kubernetes.io/controller-managed-attach-detach": "true"}

這些注釋不提供有關節點特征的任何信息。相反，他們提供了一些關于節點如何工作的數據。

什么時候使用 Kubernetes 標簽?

對象查詢的組資源

如果將相同的標簽鍵值對添加到多個資源中，其他人可以輕松查詢到所有資源。例如，DevOps 工程師發現開發環境不可用。此時，他們可以快速查看包括 label 在內的所有 pod 的狀態environment:dev。

這是一個示例命令：

> kubectl get pods -l 'environment=dev'NAME READY STATUS RESTARTS AGEnginx 
0/1 CrashLoopBackOff 1 5m

這讓團隊可以立即看到受影響的 pod 并解決問題，這比瀏覽所有資源并僅選擇dev環境中的資源要快得多。

在具有許多不同部署的復雜情況下，dev如果工程團隊沒有將environment:dev標簽添加到資源中，那么找到合適的 pod 將花費 DevOps 工程師很長時間。DevOps 工程師必須使用通用kubectl get pods命令，然后使用grep.

執行批量操作

Kubernetes 標簽的另一個用例是根據資源標簽執行批量操作。

假設工程師每晚移除所有暫存環境以降低云成本。通過使用 Kubernetes 標簽，他們可以輕松地自動執行此任務。

例如，這是一個刪除所有標記為environment:local,environment:dev或的對象的命令environment:staging：

> kubectl delete deployment,services,statefulsets -l 'environment in 
(local,dev,staging)'

根據節點標簽調度 pod

Kubernetes 標簽的隱藏寶石是它們在 Kubernetes 本身中被大量使用，用于將 pod 調度到適當的節點。通過使用標簽，您可以通過讓 Kubernetes 將特定部署安排到特定節點來更好地控制您創建的資源。

讓我們看看這在實踐中是如何工作的：

> kubectl get nodesNAME STATUS ROLES AGE VERSIONgke-node-1fe68171 Ready 
1d v1.22.12-gke.2300gke-node-3cdf3d2b Ready 3d 
v1.22.12-gke.2300gke-node-5f7b4cf1 Ready 5d v1.22.12-gke.500> kubectl 
get nodes -l ‘critical=true’No resources found

當前，不存在具有標簽的節點critical:true。

讓我們嘗試critical:true使用節點選擇器創建一個必須在具有標簽的節點上調度的 pod。這是一個pod.yaml配置文件：

apiVersion: v1kind: Podmetadata: name: nginx labels: environment: prodspec: 
nodeSelector: critical: "true" containers: - image: nginx name: nginx resources: 
requests: cpu: 500m

現在讓我們應用它并檢查會發生什么：

> kubectl apply -f pod.yamlpod/nginx created> kubectl get pod nginxNAME 
READY STATUS RESTARTS AGEnginx 0/1 Pending 0 1m> kubectl get events 
--field-selector involvedObject.name=nginxLAST SEEN TYPE REASON OBJECT 
MESSAGE46s Warning FailedScheduling pod/nginx 0/1 nodes are available: 1 node(s) 
didn't match Pod's node affinity/selector. preemption: 0/1 nodes are available: 
1 Preemption is not helpful for scheduling.

請注意，pod 無法在任何節點上調度，因為它們都沒有所需的標簽。現在，讓我們用所需的標簽標記其中一個節點：

> kubectl label node gke-node-5f7b4cf1 critical=truenode/gke-node-5f7b4cf1 
labeled> kubectl get nodes -l 'critical=true'NAME STATUS ROLES AGE 
VERSIONgke-node-5f7b4cf1 Ready 5h v1.22.12-gke.500

現在，讓我們檢查 pod：

> kubectl get pod nginxNAME READY STATUS RESTARTS AGEnginx 1/1 Running 0 
3m31s

Pod 已成功調度到該節點。

請記住，如果在節點選擇器中指定了多個標簽，則它們都必須被一個節點滿足，以便 pod 被調度到它上面。

Kubernetes 標簽的 10 個最佳實踐

1.使用Kubernetes推薦的標簽

Kubernetes 提供了一個推薦的標簽列表，用于對對象進行分組。例如，Kubernetes 推薦使用app.kubernetes.io/name和

app.kubernetes.io/instance分別表示應用程序的名稱和實例。只需刪除前綴“app.kubernetes.io”并添加您公司的子域即可自定義標簽。

2.注意語法正確

要創建 Kubernetes 標簽鍵值對，您需要使用以下語法：/. 讓我們深入了解細節：

• <前綴>

前綴是可選的;如果您選擇使用它，它需要是一個有效的 DNS 子域(例如“cast.ai”)并且總共不超過 253 個字符。對于非用戶私有的工具和命令，前綴會派上用場。它們也很有用，因為它們允許團隊使用多個標簽，否則會發生沖突(想想第三方包中的標簽)。

請注意，前綴kubernetes.io/和k8s.io前綴是為 Kubernetes 核心組件保留的。

• <名稱>

這部分是指標簽的任意屬性名。為了清楚起見，團隊可以使用名稱“環境”和標簽值，例如“生產”或“測試”。

名稱必須滿足與標簽值相同的要求，但不能為空。因此，名稱需要包含 63 個字符或更少，以字母數字字符 ([a-z0-9A-Z]) 開頭和結尾，中間有破折號 (-)、下劃線 (_)、點 (.) 和字母數字.

3.標準化標簽命名約定

使用 Kubernetes 的多個團隊需要遵循相同的標簽約定。否則，所有的標簽工作都不會給你帶來任何價值。

讓您的開發管道對資源配置文件執行靜態代碼分析以確保所有必需的標簽都存在是一個很好的做法。如果您未能正確應用標簽，自動化流程可能會中斷——您使用的任何監控解決方案都可能向您發送誤報警報。

4.避免對標簽進行不必要的改動

Kubernetes 中的標簽用于識別和選擇用于調度、部署和管理目的的資源。因此，修改資源標簽可能會產生深遠且無法預料的影響。

例如，如果您將一組 pod 的“app”標簽從“frontend”切換到“backend”，Kubernetes 可以將這些 pod 重新安排到未設置為運行“backend”應用程序的節點上。吊艙可能會崩潰;結果，使它們不可用。

只有在絕對必要時才修改標簽，并在進行任何更改之前仔細評估其后果以避免此類問題，這一點至關重要。

5.使用標簽選擇選項

團隊可以根據相等性和集合來選擇帶標簽的對象。

基于相等性的選擇允許您檢索標簽等于或不等于指定值(或多個值)的對象。深入語法，= 和 == 都表示相等，而 != 表示不等?？梢蕴砑右远禾柗指舻亩鄠€標簽(所有條件都需要在此處匹配)。例如，如果您執行以下命令：

> kubectl get pods -l ‘environment=dev,release=daily’

它將返回所有帶有標簽environment:devAND的 pod release:daily。

另一方面，基于集合的選擇允許一次查找具有多個值的資源。集合類似于INSQL 中的關鍵字。例如，以下命令：

> kubectl get pods -l ‘environment in (prod,dev)’

將找到所有包含標簽environment=prodOR的 pod environment=dev。

6. 不要在標簽中存儲應用程序級語義

Kubernetes 標簽可能與對象的元數據一起出現，但它們不應該用作應用程序的數據存儲。鑒于 Kubernetes 資源的使用時間通常很短，并且與應用程序沒有緊密關聯，標簽很快就會變得不同步，因此變得無用。

7. 不要在標簽中存儲敏感信息

如果有人在您將密碼或 API 憑據或其他敏感數據存儲在標簽中時獲得了對您的 Kubernetes 集群的訪問權限，他們將能夠以純文本形式看到它。這是一個重大的安全風險，可能會產生身份盜用或數據泄露等負面影響。

建議以秘密而不是標簽的形式保存敏感信息。秘密是加密的，只有需要它們的 pod 才能解密。通過這樣做，即使有人設法訪問您的 Kubernetes 集群，他們也無法查看保密的私有數據。

8. 給 pod 模板添加標簽

將基本標簽添加到作為工作負載資源一部分的 pod 模板。這樣，Kubernetes 控制器可以始終如一地創建具有您指定狀態的 pod。

目標不應該是創建盡可能多的標簽，而是創建能為您的團隊帶來價值的標簽。從小處著手，創建一個標簽列表作為模板的一部分。例如，您可以從確定資源所有者、資源運行環境和版本開始。

9. 自動化你的標簽實踐

自動化可以為您節省大量時間，標簽也不例外。如果您設置了持續集成/持續交付 (CI/CD) 管道，則可以輕松地自動化一些橫切關注點標簽。

使用 CD 工具自動附加標簽是明智的，因為它可以保證一致性并提高工程師的工作效率。讓 CI 作業通過使構建失敗并在標簽丟失時向負責團隊發送通知來強制執行正確的標簽也是一種很好的做法。

10.使用標簽進行成本監控

標簽對于更好地了解您的 Kubernetes 云成本非常有幫助。成本監控、分配和管理都依賴于適當的標簽策略。

如果多個租戶在單個集群中共享資源，您需要使用相關標簽來創建成本分配報告。這就是您可以確定哪個團隊、服務或應用程序產生了特定成本的方式，這在調查意外成本激增時非常有幫助。

使用此免費監控工具按標簽跟蹤您的成本

CAST AI 提供了一個成本監控工具，讓您可以隨時了解任何工作負載的成本。成本可以通過任何工作負載上存在的任何標簽進行過濾，從而可以輕松跟蹤每個團隊、服務或您使用的任何其他標簽的云成本。按標簽對工作負載進行分組的選項即將推出。

通過將集群連接到 CAST AI 的免費成本監控解決方案，了解良好的標簽和成本監控可以帶來的不同。