win7網咖專用系統
每日分享最新，最流行的軟體開發知識與最新行業趨勢，希望大家能夠一鍵三連，多多支援，跪求關注，點贊，留言。
藉助 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
當前，不存在具有標籤的節點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
現在，讓我們檢查 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 的免費成本監控解決方案，瞭解良好的標籤和成本監控可以帶來的不同。