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來設計策略
• 可有意義的方式來組織資源。團隊可以更輕鬆地大量檢測和排除問題

參考資料：

• Namespaces
• Annotations
• Labels and Selectors
• Just-in-Time Kubernetes: Namespaces, Labels, Annotations, and Basic Application Deployment
• Kubernetes Annotations Vs. Labels: What’s The Difference?nnotations Vs. Labels: What’s The Difference?