本文簡單整理 Kubernetes 的監控技術，內容包括圍繞 Prometheus 的監控架構、監控指標分類、Custom Metrics APIServer + Aggregator 來擴展 API Server 。【Kevin亓】
一、Kubernetes 核心監控體系
1.1 Prometheus 監控架構
Prometheus 核心機制：使用 Pull （抓取）的方式去搜集被監控對象的 Metrics 數據（監控指標數據），然後，再把這些數據保存在一個 TSDB （時間序列數據庫，比如 OpenTSDB、InfluxDB 等）當中，以便後續可以按照時間進行檢索。
有了這套核心監控機制， Prometheus 剩下的組件就是用來配合這套機制的運行。比如 Pushgateway，可以允許被監控對象以 Push 的方式向 Prometheus 推送 Metrics 數據。而 Alertmanager，則可以根據 Metrics 信息靈活地設置報警。當然， Prometheus 最受用戶歡迎的功能，還是通過 Grafana 對外暴露出的、可以靈活配置的監控數據可視化界面。
1.2 核心監控指標分類
1、宿主機指標
這部分數據的提供，需要藉助一個由 Prometheus 維護的Node Exporter 工具。一般來說，Node Exporter 會以 DaemonSet 的方式運行在宿主機上，代替被監控對象來對 Prometheus 暴露出可以被“抓取”的 Metrics 信息的一個輔助進程。
2、Kubernetes 各組件指標
來自於 Kubernetes 的 API Server、kubelet 等組件的 /metrics API，是用來檢查 Kubernetes 本身工作情況的主要依據。
3、Kubernetes 核心概念指標
其中包括了 Pod、Node、容器、Service 等主要 Kubernetes 核心概念的 Metrics。其中，容器相關的 Metrics 主要來自於 kubelet 內置的 cAdvisor 服務。
- Metrics 規劃原則
在具體的監控指標規劃上有業界通用的 USE 原則和 RED 原則：USE 原則主要關注的是“資源”，比如節點和容器的資源使用情況，而 RED 原則主要關注的是“服務”，比如 kube-apiserver 或者某個應用的工作情況。
- USE 原則指的是，按照如下三個維度來規劃資源監控指標：
（1）利用率（Utilization），資源被有效利用起來提供服務的平均時間佔比；
（2）飽和度（Saturation），資源擁擠的程度，比如工作隊列的長度；
（3）錯誤率（Errors），錯誤的數量。 - RED 原則指的是，按照如下三個維度來規劃服務監控指標：
（1）每秒請求數量（Rate）；
（2）每秒錯誤數量（Errors）；
（3）服務響應時間（Duration）。
二、Kubernetes 自定義監控體系
Custom Metrics + Aggregator 來擴展 API Server：
說明：
- kube-aggregator 是一個根據 URL 選擇具體的 API 後端的代理服務器；
- metric-server 是一個 Prometheus 時序數據庫查詢的 Adaptor。
- 首先，實現 Custom Metrics APIServer
Custom Metrics APIServer 本質就是一個 Prometheus 項目的 Adaptor。
工作原理是：當訪問這個 URL 的時候，Custom Metrics APIServer 就會去 Prometheus 裏查詢相應指標的值，然後按照固定的格式返回給訪問者。Prometheus 中指標的值自然是從 exportor 上採集存儲的數據。
- 然後，擴展 Kubernetes 的 API Server
API Server 的擴展其實就是添加一個根據 URL 選擇具體的 API 後端的代理服務器。
把 Custom Metrics APIServer 啓動之後，Kubernetes 裏就會出現一個叫作custom.metrics.k8s.io的 API。而當你訪問這個 URL 時，藉助 Aggregator APIServer 擴展機制，Aggregator 就會把請求轉發給 Custom Metrics APIServer 。
《深入剖析Kubernetes | 極客時間》張磊，Kubernetes容器監控2講
