今天是第 19 天，我們進入新的主題：Kubernetes 實務分享。接下來四天，我將結合自身經驗與理解，談談 Kubernetes 的設計哲學與日常操作技巧。

在深入之前，我們先回顧 Kubernetes 的出現背景。它誕生於容器技術普及的背景下。容器本質上是基於 Linux 核心機制的輕量虛擬化技術。與傳統虛擬機相比，容器讓我們不用過度關注作業系統或預安裝服務，只專注於應用程式本身。這是一種抽象化思維：把非核心的細節交給平台管理，把注意力集中在服務上。

當服務規模擴張，需要跨機器協作時，單靠人工已無法管理。Kubernetes 就是這個「中央管理平台」，負責統籌多台機器與多個容器的運行。

操作上，使用 kubectl 幾乎可以完成所有管理任務，而在抽象層次，我們關心的是為服務（Pod）設定的資源，而不是單台機器的 CPU 或記憶體分配，Kubernetes 會自動調度。

簡單整理幾個基礎概念：

• Cluster（叢集）：多台機器的集合，是 Kubernetes 的管理單位
• Node（節點）：單台機器，虛擬或實體皆可
• Pod（服務單位）：資源調度的最小單位，通常包含一個容器
• Namespace（命名空間）：服務的虛擬群組，也界定網路服務範圍
• Service（服務）：網路服務，包括負載均衡等功能

可以把它想像成：Cluster 管理硬體資源，Namespace 做邏輯分組，而 Pod 則是兩者的交集——一個運行中的服務單位。

對於後續分享，這些基礎概念已經足夠。我們將從 annotation、label 的設計哲學 展開，探索 Kubernetes 如何在抽象層面幫助我們更有效管理服務。

建議的學習方式

對於剛接觸 Kubernetes 的朋友，可以先使用雲端或沙盒環境進行練習。官方提供了完整的練習環境，以及管理 K8s 對象的官方指引。

一般的學習路徑建議：

1. 部署一個簡單的 Pod，熟悉基本操作
2. 進階到 Deployment 與 StatefulSet，理解副本管理與狀態管理
3. 學習 Service、Namespace 等邏輯分組與網路抽象
4. 了解 PersistentVolume (PV) 與 PersistentVolumeClaim (PVC)，掌握儲存資源管理

網路上已有豐富資源可跟隨官方文件學習，而本篇文章將分享一些容易被忽略的細節，這些都是在熟悉操作後才會注意到的。

今天主要介紹：

• Annotation 與 Label：用於資源分類、管理與自動化

明天則會介紹：

• ConfigMap：解耦配置與程式碼
• Affinity / Taint：資源調度策略

接下來的分享將以宣告式管理為主，幫助大家在日常運維與架構設計中養成良好習慣。

Annotation 與 Label

在 Kubernetes 裡，Label 和 Annotation 看似都是 key-value 的小字串，但作用完全不同。

在這個範例中，我們使用了 PodMonitoring，它是 Google Managed Prometheus (GMP) 提供的一種 自訂資源（Custom Resource Definition, CRD）。

簡單來說，CRD 是 Kubernetes 的擴展機制，允許使用者定義自己想要的資源型別。PodMonitoring 就是 GMP 定義用來監控 Pod 的資源。透過 CRD，我們可以像操作內建資源（如 Pod、Service）一樣操作自訂資源，設定要監控的目標 Pod、命名空間範圍及 metrics 端點。

⚠️ 本章節僅作簡介，CRD 的詳細運作原理與自訂資源管理，將在後續章節深入介紹。

以下是透過 Helm 部署的 PodMonitoring 範例：

apiVersion: monitoring.coreos.com/v1
kind: PodMonitoring
metadata:
  name: myapp-podmonitor
  namespace: monitoring
  annotations:
    # Helm 自動加入的 annotation
    meta.helm.sh/release-name: "myapp-monitor"
    meta.helm.sh/release-namespace: "monitoring"
    helm.sh/chart: "myapp-monitor-0.1.0"
    # 我們自己加的
    example.company.com/owner: "team-data"
    example.company.com/managed-by: "helm"
  labels:
    app.kubernetes.io/name: myapp
    app.kubernetes.io/instance: myapp-prod
    monitoring: prometheus
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: myapp
  namespaceSelector:
    matchNames:
      - default
  endpoints:
    - port: http-metrics
      path: /metrics
      interval: 30s
      honorLabels: true

Label → Kubernetes 與 Prometheus 用的

• spec.selector.matchLabels 是 Prometheus 依據 label 找到要監控的 Pod
• Label 是 Kubernetes 控制器用來篩選和關聯資源的依據
• 若 label 錯誤，控制器與 Prometheus 將無法找到目標 Pod

Annotation → 給人或外部工具看的

• 例如 example.company.com/owner: team-data，Kubernetes 本身不會處理
• 用於額外 metadata，如負責人、版本、checksum、pipeline id
• Helm 也會自動加入 annotation（meta.helm.sh/release-name）來追蹤資源來源，方便升級或刪除

👉 可以簡單記：

• Label → 控制器選 Pod、建立關聯
• Annotation → 留言給人或外部工具

實務提醒

• Label 不對就抓不到：常見問題是 Pod 有，但 Prometheus 沒抓到，原因多是 label mismatch 或 selector 錯誤
• Annotation 影響 Helm 管理：刪掉或修改 Helm 自動 annotation 可能導致 Helm 無法管理資源
• 🚨 在 GKE 上：使用 Google Managed Prometheus (GMP) 時，Google 會自動收集 metrics 並送往 Cloud Monitoring，不需額外部署 Prometheus Operator

⚠️ 提醒
GMP 是按指標數量計費，若沒有篩選或管理，metrics 數量易暴增，增加成本。建議建立指標治理習慣：

• 只收集必要 metrics
• 定期檢視 metrics 數量
• 對大規模 namespace 設定清單與篩選

小結

今天的分享，我們從 Kubernetes 的背景與設計哲學出發，理解了它如何透過抽象化思維，把非核心的細節交給平台管理，讓我們專注於應用服務本身。透過對 Cluster、Node、Pod、Namespace、Service 等核心概念的介紹，相信大家對 Kubernetes 的整體架構已有基本認識。

在實務部分，我們透過 PodMonitoring 的範例，明確區分了 Label 與 Annotation 的用途：

• Label：Kubernetes 控制器用來選擇 Pod 或建立關聯，對自動化管理至關重要。
• Annotation：提供額外 metadata 給人或外部工具，方便追蹤、管理或升級，但 Kubernetes 控制器本身不會依賴它。

同時，也提醒了在使用 Google Managed Prometheus (GMP) 時，需要注意 metrics 的篩選與成本管理，避免無效指標累積。

透過今天的內容，大家已經可以：

1. 理解 Kubernetes 抽象化設計與核心概念
2. 區分 Label 與 Annotation 的不同用途
3. 注意實務操作中容易忽略的細節與潛在風險

下一篇文章，我們將進一步探討 ConfigMap 如何實現配置與程式碼解耦，以及 Affinity / Taint 在資源調度中的應用，幫助大家在日常運維中建立更靈活、可管理的部署策略。

謝謝各位的閱讀，祝各位中秋佳節愉快，我們明天見!