Kubernetes 叢集監控對於維護應用程式穩定性和效能至關重要。本文將探討如何使用 Prometheus、Node Exporter 和 Kube-state-metrics 等工具監控 Kubernetes 叢集的各個層面，包括節點資源、API 伺服器效能和 Kubernetes 物件狀態。同時，我們也將介紹如何使用 Sidecar 模式監控佈署在 Kubernetes 上的 Tornado 應用程式，以及如何監控其相依的 MySQL 資料函式庫和 Redis 資料儲存，確保整個應用程式堆積疊的健康和穩定執行。文章將提供具體的 Prometheus 設定範例和告警規則，幫助讀者快速上手 Kubernetes 監控實務。
監控Kubernetes堆積疊
在Kubernetes環境中，我們可以利用Prometheus自動發現符合特定搜尋條件的目標。由於我們的Prometheus伺服器執行在Kubernetes內部，因此能夠以最小的組態自動取得Kubernetes目標。
自動發現Kubernetes目標
Prometheus支援多種Kubernetes角色的服務發現，包括節點、Pod、服務和Ingress。在這裡，我們指定了role引數，要求服務發現傳回所有的Kubernetes端點。endpoints角色會為服務的所有列出端點傳回目標，每個端點地址對應一個埠。如果端點由Pod支援，就像我們的Node Exporter服務一樣，那麼額外的容器埠也會被發現為目標。
使用中繼資料重新標記目標
服務發現還會填充多種中繼資料。我們利用這些中繼資料來重新標記和識別每個端點。讓我們看看我們的重新標記規則做了什麼，並探索這些中繼資料。
重新標記規則
我們的規則首先檢查我們在Node Exporter服務中設定的prometheus.io/scrape: 'true'註解。在服務發現過程中，prometheus.io/scrape註解會被轉換為prometheus_io_scrape以建立有效的標籤名稱。這是因為點和斜線在Prometheus指標標籤中不是合法的字元。由於這是一個Kubernetes服務上的註解，Prometheus服務程式也會在標籤前加上__meta_kubernetes_service_annotation_字首。
我們的作業只保留具有中繼資料標籤__meta_kubernetes_service_annotation_prometheus_io_scrape且值為true的目標。所有其他目標都會被丟棄。這讓我們只抓取我們想要的端點。
新增作業到ConfigMap
我們將作業新增到用於Prometheus伺服器組態的ConfigMap中，然後替換現有的組態。
$ kubectl replace -f ./prom-config-map-v1.yml -n monitoring
通常，我們需要刪除Prometheus Pod並允許它重新建立，以便載入新的組態。很快，我們應該能在Prometheus表示式瀏覽器上看到一些新的目標。
Kubernetes端點目標
我們可以看到列出了13個目標，其中9個是我們的例項上的Node Exporter端點。第10和第11個是Prometheus和Alertmanager。Prometheus和Alertmanager目標被自動發現，因為它們的介面也是以服務的形式暴露出來的。
$ kubectl get services -n monitoring
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
alertmanager LoadBalancer 100.68.82.44 a6f953a641191... 9093:32288/TCP 27m
node-exporter ClusterIP None <none> 9100/TCP 15h
prometheus LoadBalancer 100.68.154.121 a953a66970c13... 9090:30604/TCP 4d
程式碼解密：
kubectl replace命令用於替換現有的ConfigMap組態。-f ./prom-config-map-v1.yml指定了組態檔案的位置。-n monitoring指定了名稱空間。- 這段程式碼展示瞭如何更新Prometheus的組態。
Node Exporter規則
我們沒有新增任何新的記錄或警示規則給Kubernetes節點，而是將在第4章中建立的規則新增到用於填充Prometheus規則檔案的ConfigMap中。
Kubernetes可用性警示規則
- alert: KubernetesServiceDown
expr: up{job="kubernetes-service-endpoints"} == 0
for: 10m
labels:
severity: critical
annotations:
summary: Pod {{ $labels.instance }} is down!
- alert: KubernetesServicesGone
expr: absent(up{job="kubernetes-service-endpoints"})
for: 10m
labels:
severity: critical
annotations:
summary: No Kubernetes services are reporting!
description: Werner Heisenberg says - OMG Where are my servicez?
程式碼解密：
alert: KubernetesServiceDown定義了一個警示，當up指標的值為0時觸發，表示Prometheus無法抓取服務。expr: up{job="kubernetes-service-endpoints"} == 0指定了觸發警示的條件。for: 10m表示警示需要在10分鐘內持續觸發。labels和annotations提供了關於警示的額外資訊。
Kube-state-metrics
我們將使用佈署和服務在Kubernetes叢集上安裝Kube-state-metrics。佈署使用Kube-state-metrics Docker映像並在叢集上執行它。
程式碼解密：
- Kube-state-metrics是一個用於監控Kubernetes叢集的工具。
- 它透過佈署和服務在叢集上安裝。
- 使用Kube-state-metrics Docker映像來執行該工具。
Kubernetes 監控實務：Kube-state-metrics 與 API 伺服器監控
在 Kubernetes 叢集中，監控工作負載的狀態與節點健康狀況至關重要。Kube-state-metrics 提供了一系列指標，能夠讓我們深入瞭解叢集內資源的執行狀況。同時，監控 Kubernetes API 伺服器的效能與可用性也是確保叢集穩定執行的關鍵。
Kube-state-metrics 佈署與監控
Kube-state-metrics 是一個服務，它暴露了 Kubernetes 資源的各種指標，例如佈署（Deployment）、副本集（ReplicaSet）和 Pod 的狀態。這些指標可以被 Prometheus 抓取，用於監控和分析叢集的健康狀況。
Kube-state-metrics 指標與告警規則
透過 Kube-state-metrics，我們可以建立多個告警規則來監測佈署的成功與否、Pod 的重啟頻率等關鍵指標。以下是一些範例告警規則：
佈署版本不比對告警
- alert: DeploymentGenerationMismatch
expr: kube_deployment_status_observed_generation != kube_deployment_metadata_generation
for: 5m
labels:
severity: warning
annotations:
description: 觀察到的佈署版本與預期版本不一致，名稱空間：{{$labels.namespace}}/{{$labels.deployment}}
summary: 佈署已過時
此告警規則檢查佈署的執行版本是否與 metadata 中的版本一致。如果不一致，表明佈署可能未成功。
佈署副本未更新告警
- alert: DeploymentReplicasNotUpdated
expr: ((kube_deployment_status_replicas_updated != kube_deployment_spec_replicas) or (kube_deployment_status_replicas_available != kube_deployment_spec_replicas)) unless (kube_deployment_spec_paused == 1)
for: 5m
labels:
severity: warning
annotations:
description: 副本未更新且不可用於佈署 {{$labels.namespace}}/{{$labels.deployment}}
summary: 佈署副本已過時
此規則檢查佈署的副本是否已按照預期更新和可用。
Pod 重啟頻繁告警
- alert: PodFrequentlyRestarting
expr: increase(kube_pod_container_status_restarts_total[1h]) > 5
for: 10m
labels:
severity: warning
annotations:
description: Pod {{ $labels.namespace }}/{{ $labels.pod }} 在過去一小時內重啟了 {{ $value }} 次
summary: Pod 重啟頻繁
程式碼解析：
- alert: DeploymentGenerationMismatch
expr: kube_deployment_status_observed_generation != kube_deployment_metadata_generation
內容解密：
此段 Prometheus 告警規則定義了一個名為 DeploymentGenerationMismatch 的告警。當 kube_deployment_status_observed_generation（當前觀察到的佈署版本）與 kube_deployment_metadata_generation（預期的佈署版本）不一致時觸發告警。這種情況通常發生在佈署更新未能成功應用時。
kube_deployment_status_observed_generation：代表目前叢集觀察到的佈署版本。kube_deployment_metadata_generation：代表預期應該達到的佈署版本。expr: 這是 Prometheus 的查詢表示式，用於定義觸發告警的條件。當表示式的值為真時，告警被觸發。
Kubernetes API 伺服器監控
除了監控叢集內的資源狀態外，監控 Kubernetes API 伺服器的效能也至關重要。API 伺服器的延遲、錯誤率和可用性直接影響到整個叢集的穩定性和可靠性。
API 伺服器監控任務組態
我們需要組態 Prometheus 以抓取 Kubernetes API 伺服器的指標。以下是一個範例任務組態：
- job_name: 'kubernetes-apiservers'
scheme: https
tls_config:
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
insecure_skip_verify: true
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
kubernetes_sd_configs:
- role: endpoints
relabel_configs:
- source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
action: keep
regex: default;kubernetes;https
此組態指定了如何透過 HTTPS 連線到 Kubernetes API 伺服器，並使用服務帳戶 token 進行身份驗證。
API 伺服器延遲監控
為了計算 API 伺服器的延遲，我們可以使用 apiserver_request_latencies_bucket 指標，並透過 histogram_quantile 函式計算出不同的百分位數延遲。
- record: apiserver_latency_seconds:quantile
expr: histogram_quantile(0.99, rate(apiserver_request_latencies_bucket[5m])) / 1e+06
labels:
quantile: "0.99"
程式碼解析：
- record: apiserver_latency_seconds:quantile
expr: histogram_quantile(0.99, rate(apiserver_request_latencies_bucket[5m])) / 1e+06
內容解密：
此段 Prometheus 記錄規則用於計算 API 請求的延遲，並將結果記錄為 apiserver_latency_seconds:quantile。
histogram_quantile(0.99, rate(apiserver_request_latencies_bucket[5m]))：計算過去五分鐘內 API 請求延遲的第99百分位數。rate(apiserver_request_latencies_bucket[5m])：計算過去五分鐘內各個延遲桶（bucket）的變化率。/ 1e+06：將延遲單位從微秒轉換為秒。labels.quantile: "0.99"：標記該指標代表第99百分位數的延遲。
監控堆積疊 - Kubernetes 與 Tornado 應用程式
Kubernetes 的監控
在前一章中，我們探討瞭如何使用 Prometheus 監控 Kubernetes 叢集。首先，我們在 Kubernetes 上安裝了 Prometheus 以簡化監控工作。接著，我們利用 Node Exporter 監控了 Kubernetes 節點及其佈署的底層節點。
建立 Prometheus 任務
我們建立了多個 Prometheus 任務，包括利用 Kubernetes 服務發現功能自動發現節點、API 伺服器和構成環境的服務。這種服務發現機制使我們能夠組態任務，當特定的 Kubernetes 或應用程式服務出現時，自動開始抓取相關指標。
API 伺服器延遲警示
- alert: APIHighLatency
expr: apiserver_latency_seconds:quantile{quantile="0.99", subresource!="log", verb!~"^(?:WATCH|WATCHLIST|PROXY|CONNECT)$"} > 4
for: 10m
labels:
severity: critical
annotations:
description: "API 伺服器的第 99 百分位延遲為 {{ $value }} 秒，用於 {{ $labels.verb }} {{ $labels.resource }}"
API 錯誤率警示
- alert: APIServerErrorsHigh
expr: rate(apiserver_request_count{code=~"^(?:5..)$"}[5m]) / rate(apiserver_request_count[5m]) * 100 > 5
for: 10m
labels:
severity: critical
annotations:
description: "API 伺服器傳回錯誤佔請求的 {{ $value }}%"
CAdvisor 和節點監控
Kubernetes 預設提供了 CAdvisor 和節點特定的時間序列資料。我們可以建立一個任務來從 Kubernetes API 為每個節點抓取這些時間序列資料。
- job_name: 'kubernetes-cadvisor'
scheme: https
tls_config:
insecure_skip_verify: true
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
kubernetes_sd_configs:
- role: node
relabel_configs:
- action: labelmap
regex: __meta_kubernetes_node_label_(.+)
- target_label: __address__
replacement: kubernetes.default.svc:443
- source_labels: [__meta_kubernetes_node_name]
regex: (.+)
target_label: __metrics_path__
replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor
Tornado 應用程式的監控
在這一章中，我們將佈署一個名為 Tornado 的應用程式到 Kubernetes 叢集上，並對其進行監控。Tornado 是一個簡單的 REST-ful HTTP API，使用 Clojure 編寫，執行在 JVM 上，並使用 Redis 資料儲存和 MySQL 資料函式庫。
Sidecar 模式
我們將大量依賴一種名為 Sidecar 的架構模式來進行監控。Sidecar 模式得名於其類別似於綁在摩托車上的邊車：摩托車是我們的應用程式，而邊車則為應用程式提供支援功能，例如收集日誌或進行監控。Sidecar 與父應用程式分享相同的生命週期，在父應用程式被建立或刪除時同時被建立或刪除。
MySQL、Redis 和 Tornado API 的監控
我們將監控以下元件：
- MySQL 資料函式庫
- Redis 資料儲存
- Tornado API 應用程式
我們將從監控我們的兩個資料儲存開始，使用 Sidecar 模式來收集相關指標並識別關鍵警示。