Namespace與它的好朋友們(annotation/label/selector)
今天分別針對3個基本中的基本資源物件類型來說明：
- Namespace
- Annotation
- Label
annotation: 什麼都可以寫
1. Namespace
負責在cluster內進行資源群組的隔離。同一個命名空間的名字必須具備唯一性。對於cluster-level的資源就不具備隔離的能力(ex. storageclass, nodes, PV…)。
在Kubernetes建立之後，預設會有以下四個namespaces:
(1) default: 預設的命名空間
(2) kube-node-lease: 內含一些與每個節點交互的物件，允許kubelet傳送heartbeats來確保control plane可以偵測到節點錯誤
(3) kube-public: 所有client都可以讀取這個命名空間的內容。大部分都存放cluster level會用的到的物件。
(4) kube-system: 由kubernetes system創立
Initial namespaces
然後，我們也可以修改預設的namespace，做法如下：
[master]# kubectl create ns test-ns
[master]# kubectl config set-context --current --namespace=test-ns
Context "kubernetes-admin@kubernetes" modified.
[master]# kubectl config view --minify | grep namespace:
namespace: test-ns
基本上Namespace的組成通常會是：
- 某一個應用軟體的資源集合
- 屬於特定使用者的資源，user建立自已的namespace後，在namespace內建立許多將會使用到的資源(pvc…)
- 特定環境所需要的資源群組，例如Dev與Test分別為不同的namespace，但可能內部用的資源類型都相同
Note: 如果要在namespace內再建立不同的sub namespace，則就會利用到HNC(Hierarchical Namespaces Controller)，之後再另外說明。
2. Annotation
簡單來說，就是註解。使用者任意定義的附加資訊，用來給外部工具查詢。可以用來描述這個資源的。
(1) 將metadata附加到物件
label 或 annotation都可以用來附加metadata到K8S 物件，但annotation不是用來識別並選擇物件使用，而且可是結構化或非結構化。連不允許在label使用的字元都可以使用。
"metadata": {
"annotations": {
"key1" : "value1",
"key2" : "value2"
}
}
(2) Label與Annotation的差異
3. Label & Selector
Label為key/value pairs的概念，用來指定特定的物件屬性，一般是在物件建立時順便指派label。每個物件都可以定義label(key/value), 但每個key名稱就必須在該物件內是唯一。
apiVersion: v1
kind: Pod
metadata:
name: label-demo
labels:
environment: production
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
(1) Label可以用在那些地方：
- 從使用者可以理解的方式識別出物件
- 透過定義來將物件再組合成群組
- 在cluster識別物件
- 更容易一次對一群物件進行操作
- 對Kubernetes成本的追蹤、配置與管理
(2) Label selector
透過label selector, 使用者可以識別出一組物件。label selector是K8S的核心群組概念。
目前支援二種類型的selector：equality-based與set-based。一個label selector可以由多個需求以,分隔來組成。
- equality-based
※ Syntax:
environment = production
tier != frontend
※ Example:
# kubectl get pods -l environment=production,tier=frontend
- set-based
※ Syntax:
environment in (production, qa)
tier notin (frontend, backend)
partition
!partition
※ Example:
# kubectl get pods -l 'environment in (production),tier in (frontend)'
# kubectl get pods -l 'environment in (production, qa)'
# kubectl get pods -l 'environment,environment notin (frontend)'
以下範例說明在YAML檔內如何撰寫
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: label-test
spec:
replicas: 2
selector:
matchLabels:
app: labelapp <<< selector
template:
metadata:
labels:
app: labelapp <<< label
spec:
containers:
- name: label-app
image: github/labelapp
imagePullPolicy: Always
ports:
- containerPort: 8080
resources:
limits:
cpu: "0.2"
memory: 20Mi
---
apiVersion: apps/v1
kind: Service
metadata:
name: label-svc
spec:
ports:
- protocol: TCP
port: 8080
targetPort: 8080
type: LoadBalancer
selector:
app: labelapp <<< selector
label selector
官方建議應用服務可以照下圖建立相關的Label：
https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/#labels
# This is an excerpt
apiVersion: apps/v1
kind: StatefulSet
metadata:
labels:
app.kubernetes.io/name: mysql
app.kubernetes.io/instance: mysql-abcxzy
app.kubernetes.io/version: "5.7.21"
app.kubernetes.io/component: database
app.kubernetes.io/part-of: wordpress
app.kubernetes.io/managed-by: helm
4. 一些建議的使用方式
- 透過附加
label與annotation來優化對Kubernetes物件的可視性 - 保持一致的標籤命名規範避免混淆、重覆與重工
- 保持標籤和註釋的簡潔性能夠降低複雜性，特別是對於標籤來說，因為Kubernetes在內部操作中使用它們。
- 盡早使用官方建議的label與annotation的寫法
- 通過按照每個類型的正確字符集和語法來建立共識
- 不要把機密訊息寫在label或annotation
- 設計備份時，記得利用label與annotation來設計策略
- 可有意義的方式來組織資源。團隊可以更輕鬆地大量檢測和排除問題
參考資料：
你可能也想看
