Kubernetes 叢集的穩定執行仰賴完善的監控、日誌和組態管理策略。本文從 kube-state-metrics 指標解析出發,逐步介紹如何利用 Prometheus 和 Grafana 建立監控體系,並探討如何使用 Loki-Stack 收集和查詢日誌。此外,文章也涵蓋了 ConfigMaps 和 Secrets 的組態管理技巧,以及 RBAC 最佳實踐,幫助讀者建立健全的 Kubernetes 叢集管理機制。
Kubernetes 監控與度量指標解析
Kubernetes 環境的監控需要多層次的策略來確保系統的穩定性和效能。kube-state-metrics 提供了豐富的指標來幫助我們瞭解叢集的狀態。
kube-state-metrics 能回答的問題
kube-state-metrics 可以提供多種與 Kubernetes 資源相關的指標,包括:
Pod 相關指標:
- 目前佈署的 Pod 數量
- 處於 Pending 狀態的 Pod 數量
- Pod 請求是否超出可用資源
Deployment 相關指標:
- 執行中的 Pod 數量 vs. 期望狀態的 Pod 數量
- 可用的副本數量
- 最近更新的 Deployment
Node 相關指標:
- 節點的狀態
- 叢集中可用的 CPU 核心數量
- 是否有不可排程的節點
Job 相關指標:
- Job 的開始時間
- Job 的完成時間
- 失敗的 Job 數量
需要監控的指標
監控 Kubernetes 環境時,採用分層方法可以幫助我們更準確地識別問題。需要監控的層麵包括:
- 物理或虛擬節點
- 叢集元件
- 叢集附加元件
- 終端使用者應用程式
具體需要監控的指標包括:
節點層面:
- CPU 使用率
- 記憶體使用率
- 網路使用率
- 磁碟使用率
叢集元件:
- etcd 延遲
叢集附加元件:
- Cluster Autoscaler 狀態
- Ingress Controller 狀態
應用程式層面:
- Container 的記憶體使用率和飽和度
- Container 的 CPU 使用率
- Container 的網路使用率和錯誤率
- 特定應用框架的指標
Kubernetes 的監控工具
有多種監控工具可以與 Kubernetes 整合,包括:
Prometheus
Prometheus 是開源的系統監控和警示工具包,最初由 SoundCloud 建立。它具有活躍的開發者和使用者社群,現在是 Cloud Native Computing Foundation (CNCF) 的專案之一。
InfluxDB
InfluxDB 是專為處理高寫入和查詢負載而設計的時間序列資料函式庫。它是 TICK (Telegraf, InfluxDB, Chronograf, 和 Kapacitor) 堆積疊的重要組成部分。
Datadog
Datadog 提供雲端規模應用的監控服務,透過 SaaS 為基礎的資料分析平台來監控伺服器、資料函式庫、工具和服務。
Sysdig
Sysdig Monitor 是商業工具,提供 Docker 和 Kubernetes 的監控功能,支援原生容器應用。它允許收集、關聯和查詢 Prometheus 指標,並與 Kubernetes 直接整合。
雲端供應商工具
主要雲端供應商都提供監控工具,例如:
- GCP Stackdriver:為 Google Kubernetes Engine (GKE) 提供監控和日誌服務。
- Microsoft Azure Monitor for containers:用於監控 Azure Container Instances 和 Azure Kubernetes Service (AKS) 上佈署的容器工作負載。
使用Prometheus監控Kubernetes叢集
在現代化的雲原生應用中,監控是一項至關重要的任務。Prometheus作為一個開源的監控系統,提供了對Kubernetes叢集的強大監控能力。本文將介紹如何使用Prometheus監控Kubernetes叢集。
Prometheus簡介
Prometheus是一個由Cloud Native Computing Foundation(CNCF)託管的開源專案。它最初由SoundCloud開發,並借鑒了Google內部監控系統Borgmon的概念。Prometheus採用多維度資料模型,使用鍵值對來表示指標,這與Kubernetes的標籤系統類別似。
Prometheus的優點
- 多維度資料模型:Prometheus的資料模型支援多維度查詢,能夠靈活地表示各種指標。
- 簡潔的架構:Prometheus的架構設計簡潔,易於佈署和維護。
- 豐富的生態系統:Prometheus支援多種Exporter,能夠收集各種系統和應用的指標。
Prometheus架構
圖示說明
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam rectangleBackgroundColor #F5F5F5
skinparam rectangleBorderColor #333333
skinparam arrowColor #333333
title 圖示說明
rectangle "pull" as node1
rectangle "alert" as node2
rectangle "visualize" as node3
node1 --> node2
node2 --> node3
@enduml
圖表翻譯: 此圖示展示了Prometheus的架構。Prometheus Server透過pull模式收集來自Node Exporter、kube-state-metrics和Kubernetes API的指標。Alertmanager負責處理警示並將其轉發到外部通知系統。Grafana則用於視覺化展示Prometheus中的指標資料。
在Kubernetes叢集中佈署Prometheus
步驟1:安裝minikube
首先,我們需要在本地機器上安裝minikube。可以使用Homebrew進行安裝:
brew install minikube
步驟2:建立名稱空間並安裝Prometheus Operator
建立一個名為monitoring的名稱空間:
kubectl create ns monitoring
新增Prometheus社群的Helm chart倉函式庫:
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
更新Helm倉函式庫:
helm repo update
安裝kube-prometheus-stack:
helm install --namespace monitoring prometheus prometheus-community/kube-prometheus-stack
步驟3:驗證安裝
檢查monitoring名稱空間下的Pod狀態:
kubectl get pods -n monitoring
預期輸出:
NAME READY STATUS RESTARTS AGE
alertmanager-prometheus-kube-prometheus-alertmanager-0 2/2 Running 0 10m
prometheus-grafana-6f7cf9b968-xtnzj 3/3 Running 0 10m
prometheus-kube-prometheus-operator-7bdb94567b-... 1/1 Running 0 10m
prometheus-kube-state-metrics-6bdd65d76-s5r5j 1/1 Running 0 10m
prometheus-prometheus-kube-prometheus-prometheus... 2/2 Running 0 10m
prometheus-prometheus-node-exporter-dgrlf 1/1 Running 0 10m
使用Grafana視覺化指標資料
建立一個到Grafana例項的隧道:
kubectl --namespace monitoring port-forward svc/prometheus-grafana 3000:80 &
現在,可以透過瀏覽器存取http://127.0.0.1:3000來檢視Grafana儀錶板。
Kubernetes 監控與日誌管理的重要性
在前面的章節中,我們討論瞭如何使用 USE 方法來監控 Kubernetes 叢集的效能。現在,我們將進一步探討如何收集節點的 CPU 使用率和飽和度等指標。Kube-prometheus-stack 提供了一系列預建的 Grafana 儀錶板,可以幫助我們更好地監控叢集的狀態。
使用 Grafana 監控 Kubernetes 叢集
首先,我們需要建立一個隧道來連線 Grafana 例項:
kubectl port-forward -n monitoring svc/prometheus-grafana 3000:80
然後,在瀏覽器中輸入 http://localhost:3000,並使用以下憑證登入:
- 使用者名稱:admin
- 密碼:prom-operator
在 Grafana 儀錶板中,我們可以找到一個名為「Kubernetes / USE Method / Cluster」的儀錶板,它提供了對 Kubernetes 叢集的利用率和飽和度的全面概覽。
圖表翻譯:
此圖表顯示了 Kubernetes 叢集的 CPU 使用率和飽和度的相關指標,可以幫助我們快速瞭解叢集的狀態。
避免建立過多的儀錶板
在建立儀錶板時,我們應該避免建立過多的儀錶板,因為這可能會導致工程師在故障排除時難以理解。我們應該專注於設計出能夠快速解決問題的儀錶板。
日誌管理概述
除了監控指標之外,日誌管理也是 Kubernetes 叢集管理的重要組成部分。我們需要收集和集中來自 Kubernetes 叢集和應用程式的日誌,以更好地瞭解環境中的問題。
日誌收集的挑戰
- 日誌過多,難以快速找到問題
- 日誌儲存需要大量的資源和成本
日誌收集的最佳實踐
- 收集必要的日誌,避免收集過多的日誌
- 實施日誌保留和歸檔策略,通常保留 30-45 天的日誌是合適的
Kubernetes 叢集中的日誌收集
在 Kubernetes 叢集中,有多個元件需要收集日誌,包括:
- 節點日誌
- Kubernetes 控制平面日誌(API 伺服器、控制器管理器、排程器)
- Kubernetes 稽核日誌
- 應用程式容器日誌
節點日誌收集
節點日誌可以幫助我們瞭解節點上的事件,例如 Docker 守護程式的日誌。
Kubernetes 控制平面日誌收集
Kubernetes 控制平面日誌可以幫助我們瞭解控制平面的問題,例如 API 伺服器、控制器管理器和排程器的日誌。
Kubernetes 稽核日誌收集
Kubernetes 稽核日誌可以幫助我們瞭解誰在系統中做了什麼,這些日誌可能會很嘈雜,需要進行調校。
應用程式容器日誌收集
應用程式容器日誌可以幫助我們瞭解應用程式的行為,可以透過將日誌傳送到 STDOUT 或使用 sidecar 模式來收集。
日誌管理工具
有多種工具可以用於收集 Kubernetes 和應用程式的日誌,我們應該選擇適合自己的工具,並瞭解其實作方式。
日誌管理工具的最佳實踐
- 選擇能夠以 Kubernetes DaemonSet 模式執行的工具
- 選擇能夠以 sidecar 模式執行於不將日誌傳送到 STDOUT 的應用程式的工具
Kubernetes 日誌管理與監控實務
在現代化的雲端原生應用程式開發中,Kubernetes 已成為容器協調的標準。然而,隨著叢集規模的擴大,日誌管理和監控成為了一項挑戰。本文將探討如何在 Kubernetes 環境中有效地進行日誌管理和監控。
常見的 Kubernetes 日誌管理工具
目前有多種工具支援與 Kubernetes 整合進行日誌管理,包括:
- Loki
- Elastic Stack
- Datadog
- Sumo Logic
- Sysdig
- 各大雲端供應商的服務(如 GCP Stackdriver、Azure Monitor for containers、Amazon CloudWatch)
選擇適當的日誌管理工具時,託管服務可以提供相當大的價值,因為它們能夠分擔大部分的維運成本。自建日誌管理方案在初期看似方便,但隨著環境的成長,維護成本會顯著增加。
使用 Loki-Stack 進行日誌管理
本篇文章將採用 Loki-Stack 結合 prom-tail 來進行叢集日誌管理。Loki-Stack 的佈署相對簡單,但隨著時間的推移,自建方案可能會變得過於複雜。因此,評估業務需求並選擇適當的方案至關重要。Grafana 提供了託管的 Loki 服務,可以在需要時輕鬆遷移。
佈署 Loki-Stack
我們將使用以下元件來建立日誌管理堆積疊:
- Loki
- prom-tail
- Grafana
透過 Helm 佈署 Loki-Stack 至 Kubernetes 叢集的步驟如下:
# 新增 Loki-Stack Helm 倉函式庫
helm repo add grafana https://grafana.github.io/helm-charts
# 更新 Helm 倉函式庫
helm repo update
# 安裝 Loki-Stack
helm upgrade --install loki --namespace=monitoring grafana/loki-stack
#### 內容解密:
此段程式碼是用於安裝和組態Loki-Stack。首先,我們新增Grafana的Helm倉函式庫以取得Loki-Stack的安裝包。接著,更新本地的Helm倉函式庫資訊,以確保我們能取得最新的Loki-Stack版本。最後,使用helm upgrade --install命令將Loki-Stack佈署到Kubernetes叢集的monitoring名稱空間中。
佈署完成後,可以透過以下命令檢查相關 Pod 是否正常執行:
kubectl get pods -n monitoring
#### 內容解密:
此命令用於檢查monitoring名稱空間中的Pod狀態。透過觀察Pod的STATUS欄位,我們可以確認Loki和prom-tail是否成功啟動並執行。
接下來,我們需要將 Grafana 服務透過 port-forwarding 對應到本地端,以便進行存取:
kubectl port-forward -n monitoring svc/prometheus-grafana 3000:80
#### 內容解密:
此命令將Kubernetes叢集中的prometheus-grafana服務透過port-forwarding技術對應到本地端的3000埠。這樣,我們就可以在本地端的瀏覽器中透過http://localhost:3000存取Grafana介面。
存取 Grafana 後,使用預設帳號密碼(admin/prom-operator)登入,並新增 Loki 為資料來源,設定 URL 為 http://loki:3100。
圖表翻譯:
此圖示展示瞭如何在Grafana中新增Loki作為資料來源。正確設定URL並儲存後,即可開始使用Loki進行日誌查詢和監控儀錶板的建立。
日誌查詢與監控儀錶板
在 Grafana 中,我們可以使用「Explore」功能對 Loki 中的日誌進行查詢。例如,使用 namespace = kube-system 的標籤過濾器來查詢特定名稱空間的日誌。
圖表翻譯:
此圖示展示瞭如何使用Grafana的Explore功能查詢Loki中的日誌。透過設定適當的標籤過濾器,我們可以輕鬆地找到所需的系統日誌。
警示管理
在 Kubernetes 環境中,警示管理是一項重要的任務。過多的警示會導致警示疲勞,因此需要仔細選擇需要警示的事件。通常,應關注那些影響服務水平目標(SLO)的事件,例如前端服務的回應時間超過預期。
自動化修復與警示閾值
為了減少不必要的警示,可以採用自動化修復措施,例如使用 Kubernetes 的 liveness probes 自動重啟異常容器。同時,設定合理的警示閾值(如 5 分鐘、10 分鐘等)可以有效減少誤報。
#### 內容解密:
此段落闡述瞭如何透過自動化修復和合理的警示閾值來最佳化警示管理。自動化修復可以處理一些常見問題,而適當的閾值設定則能減少不必要的警示,從而提高維運效率。
組態、金鑰與RBAC最佳實踐
在容器化環境中,組態管理與安全存取控制是確保應用程式正常運作的關鍵因素。Kubernetes 提供了多種機制來處理組態資料與敏感資訊,同時透過 Role-Based Access Control(RBAC)實作細粒度的許可權管理。本章節將探討如何在 Kubernetes 中有效地管理組態與金鑰,並介紹 RBAC 的最佳實踐。
透過 ConfigMaps 和 Secrets 進行組態管理
Kubernetes 提供了兩種主要的資源型別來處理應用程式組態:ConfigMaps 和 Secrets。這兩者的主要差異在於資料儲存方式及安全性。
ConfigMaps:應用程式組態的最佳選擇
ConfigMaps 允許開發人員將組態資料以鍵值對的形式注入容器中。常見的使用場景包括:
- 環境變數注入
- 組態檔案掛載
- 命令列引數傳遞
使用 ConfigMaps 的優點在於能夠在不修改應用程式映像的前提下,動態調整應用程式的行為。
Secrets:保護敏感資訊的關鍵
Secrets 用於儲存敏感資料,如資料函式庫密碼、API 金鑰等。與 ConfigMaps 相比,Secrets 在 etcd 中的儲存方式更為安全。
使用 Secrets 的最佳實踐包括:
- 限制存取許可權:透過 RBAC 控制誰可以存取特定的 Secrets。
- 加密儲存:確保 etcd 中的資料加密儲存。
- 最小許可權原則:僅向需要的 Pod 掛載必要的 Secrets。
Role-Based Access Control(RBAC)最佳實踐
RBAC 是 Kubernetes 中實作精細許可權控制的主要機制。正確組態 RBAC 可以有效保護叢集資源。
RBAC 實施要點
- 角色定義:明確定義 Role 和 ClusterRole,確保許可權最小化。
- 角色繫結:使用 RoleBinding 和 ClusterRoleBinding 將角色正確分配給使用者或服務帳戶。
- 定期稽核:定期檢查 RBAC 組態,移除不必要的許可權。
圖表說明:Kubernetes 組態管理架構
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam rectangleBackgroundColor #F5F5F5
skinparam rectangleBorderColor #333333
skinparam arrowColor #333333
title 圖表說明:Kubernetes 組態管理架構
rectangle "使用" as node1
rectangle "存取" as node2
rectangle "控制" as node3
rectangle "授權" as node4
node1 --> node2
node2 --> node3
node3 --> node4
@enduml
圖表翻譯: 此圖示展示了 Kubernetes 中的組態管理架構。應用程式透過 ConfigMaps 和 Secrets 取得組態資訊,這些資源由 Kubernetes API 管理存取。同時,RBAC 機制控制著對這些資源的存取許可權,確保只有授權的使用者或服務帳戶能夠進行相關操作。
內容解密:
此圖表說明瞭 Kubernetes 組態管理的核心元件及其相互關係。ConfigMaps 和 Secrets 為應用程式提供靈活的組態方式,而 RBAC 則確保了對這些資源的安全存取控制。