物件「標籤」含義與制定
標籤 (Label) 是什麼
開始討論如何制定 Kubernetes 物件的標籤前，我們必須先瞭解「標籤」是什麼以及它在 Kubernetes 扮演什麼樣的角色！
仔細觀察文章開頭的圖片，會發現每張黑膠唱片都被貼上了對應的歌手的標籤，有需要的人們便可以按照標籤找到所需的專輯。
此外，有時顧客可能會想以曲風作為尋找的依據，因此圖中可以看到店員在專輯前的木頭桌面貼上 Jazz 的貼紙。
從上面簡單的例子可以看到，標籤的存在讓店員便於 分門別類 同時也讓顧客易於 快速查找 所需的專輯。並且根據不同面向給予最適合的標籤，
將有助於在複雜的場景下提高效率，而「歌手」與「曲風」兩種標籤正是這個例子最好的呈現方式。
標籤用途
我們可以將相同概念套用在 Kubernetes 上面，只是管理的對象變成一個個物件。在 K8S 中標籤主要有幾種用途:
- 物件層級管理
- 流量導通
- 部署限制
- 維護管理
物件層級管理
selector:
matchLabels:
app: redis
上層資源透過標籤找到對應管理的下層資源，比方說 Deployment 透過 selector.matchLabels 找到下層管理的 ReplicaSet，
再由 ReplicaSet 通過相同的標籤找到下面管理的 Pod。
流量導通
在 Service 內指定好目標 Pod 的標籤，kube-proxy 便能夠依此找到對應的 Pod 並建立流量導通規則。更可以進一步透過調整「標籤組合 (label set)」
方式調整細粒度進而達成如「藍綠部署」或「簡易 A/B Testing」的功能。
部署限制
spec:
nodeSelector:
disktype: ssd
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/e2e-az-name
operator: In
values:
- e2e-az1
- e2e-az2
在叢集建立時，每個節點本身的硬體與所在地域可能有所不同，比方說有的節點有 GPU，有的位於北美機房等不同條件。
而不同應用程式也自然有硬體、地域性等等不同需求，在部署容器到叢集時我們就可以透過給予對應的「部署限制」規則，
讓 scheduler 匹配容器到對應的節點上。
維護管理
管理者在日常系統維護時，當叢集規模變得十分龐大時，勢必需要透過標籤快速找到目標物件。
$ kubectl get deploy -l app=nginx,version=1
另外，許多第三方監控應用也支援利用標籤將應用分門別類的管理。因此好的標籤將會帶來許多管理上的便利性！
如何制定標籤
從前面的例子，可以看到企業要正確制定標籤的話，主要環繞幾個面向:
- 硬體
- 維運管理
- 應用程式
硬體 (label 設定在節點)
這個層面是最直覺的部分，通常會根據 worker node 所擁有的資源來給予標籤，GPU、SSD、Network throughput 等等。
gpu: nvidia
disk: ssd
networkspeed: 10G
但我們有時候會需要針對數字來做比大小，以便於部署到適合的節點時，networkspeed 可以改寫成
networkspeed: 10
改寫後就能使用 affinity 內的 Gt (greater than) 或 Lt (lower than) 進行比較，如此一來在部署時就能更有彈性的去分配與調度。
維運管理 (label 設定在節點、叢集)
此層面以如何進一步提高維運效率為出發點，常見的標籤類型有
- 節點 (node: xxxyyy)
- 數據中心位置或 AZ (available zone) (dc-location: asia-east-1-b)
- 所在國家 (country: us)
如果會部署給專門客戶或部門，甚至可以加上對方的 ID，比如
- client-id: xxxx-yyyy-zzzz
應用程式 (label 設定在 K8S Objects)
應用程式可用的標籤就非常多元，需根據實際場景做設定，但常見的有
- 版本號 (version: v1)
- Commit SHA (commit: 32989bb3d4c4bf84824974bb25f43b7e06919e41)
- 程式語言 (lang: nodejs)
- 應用程式類型 (application: mysql)
- 此應用歸屬於哪個應用底下，比方說「mysql」 歸屬於「網頁部落格系統」的一部分 (part-of: blog-system)
- 此應用是被誰(工具)管理 (managed-by: helm)
- 環境 (env: production)
Kubernetes 推薦標籤種類
下面是官方推薦標籤種類，適合絕大多數應用場景的需求
總結
標籤主要效益是讓我們或 Kubernetes 簡化系統管理複雜度、提高維護便利性，因此在設計前新的標籤種類前可以思考幾個問題
- 新標籤的應用場景與實際效益
- 是否能篩選出我們所需要的物件
- 標籤的語義是否足夠明確，讓他人能夠馬上理解
只要能夠滿足上述條件，相信都會是不錯的 label 類型。
後續我們將介紹企業使用「標籤」時的最佳實踐原則，敬請期待！
