監控
1、資源指標和資源監控
一個集群系統管理離不開監控，同樣的Kubernetes也需要根據數據指標來采集相關數據，從而完成對集群系統的監控狀況進行監測。這些指標總體上分為兩個組成：監控集群本身和監控Pod對象，通常一個集群的衡量性指標包括以下幾個部分：
節點資源狀態：主要包括網絡帶寬、磁盤空間、CPU和內存使用率
節點的數量：即時性了解集群的可用節點數量可以為用戶計算服務器使用的費用支出提供參考。
運行的Pod對象：正在運行的Pod對象數量可以評估可用節點數量是否足夠，以及節點故障時是否能平衡負載。
另一個方面，對Pod資源對象的監控需求大概有以下三類：
Kubernetes指標：監測特定應用程序相關的Pod對象的部署過程、副本數量、狀態信息、健康狀態、網絡等等。
容器指標：容器的資源需求、資源限制、CPU、內存、磁盤空間、網絡帶寬的實際占用情況。
應用程序指標：應用程序自身的內建指標，和業務規則相關
2、Weave Scope監控集群
Weave Scope 是 Docker 和 Kubernetes 可視化監控工具。Scope 提供了至上而下的集群基礎設施和應用的完整視圖，用戶可以輕松對分布式的容器化應用進行實時監控和問題診斷。 對於復雜的應用編排和依賴關系，scope可以使用清晰的圖標一覽應用狀態和拓撲關系。
2、核心指標監控之metrics-server
在最初的系統資源監控，是通過cAdvisor去收集單個節點以及相關Pod資源的指標數據，但是這一功能僅能夠滿足單個節點，在集群日益龐大的過程中，該功能就顯得low爆了。於是將各個節點的指標數據進行匯聚並通過一個借口進行向外暴露傳送是必要的。
Heapster就是這樣的一種方式，通過為集群提供指標API和實現並進行監控，它是集群級別的監控和事件數據的聚合工具，但是一個完備的Heapster監控體系是需要進行數據存儲的，為此其解決方案就是引入了Influxdb作為后端數據的持久存儲，Grafana作為可視化的接口。原理就是Heapster從各個節點上的cAdvisor采集數據並存儲到Influxdb中，再由Grafana展示。原理圖如下：
時代在變遷，陳舊的東西將會被淘汰，由於功能和系統發展的需求，Heapster無法滿足k8s系統監控的需求，為此在Kubernetes 1.7版本以后引入了自定義指標(custom metrics API)，在1.8版本引入了資源指標（resource metrics API）。逐漸地Heapster用於提供核心指標API的功能也被聚合方式的指標API服務器metrics-server所替代。
在新一代的Kubernetes指標監控體系當中主要由核心指標流水線和監控指標流水線組成：
核心指標流水線：是指由kubelet、、metrics-server以及由API server提供的api組成，它們可以為K8S系統提供核心指標，從而了解並操作集群內部組件和程序。其中相關的指標包括CPU的累積使用率、內存實時使用率，Pod資源占用率以及容器磁盤占用率等等。其中核心指標的獲取原先是由heapster進行收集，但是在1.11版本之后已經被廢棄，從而由新一代的metrics-server所代替對核心指標的匯聚。核心指標的收集是必要的。如下圖：
監控指標流水線：用於從系統收集各種指標數據並提供給終端用戶、存儲系統以及HPA。它們包含核心指標以及許多非核心指標，其中由於非核心指標本身不能被Kubernetes所解析，此時就需要依賴於用戶選擇第三方解決方案。如下圖：
一個可以同時使用資源指標API和自定義指標API的組件是HPAv2，其實現了通過觀察指標實現自動擴容和縮容。而目前資源指標API的實現主流是metrics-server。
自1.8版本后，容器的cpu和內存資源占用利用率都可以通過客戶端指標API直接調用，從而獲取資源使用情況，要知道的是API本身並不存儲任何指標數據，僅僅提供資源占用率的實時監測數據。
資源指標和其他的API指標並沒有啥區別，它是通過API Server的URL路徑/apis/metrics.k8s.io/進行存取，只有在k8s集群內部署了metrics-server應用才能只用API，其簡單的結構圖如下：
Heapster。 Metrics Server 通過 Kubernetes 聚合 器（ kube- aggregator） 注冊 到 主 API Server 之上， 而后 基於 kubelet 的 Summary API 收集 每個 節 點上 的 指標 數據， 並將 它們 存儲 於 內存 中 然后 以 指標 API 格式 提供，如下圖：
Metrics Server基於 內存 存儲， 重 啟 后 數據 將 全部 丟失， 而且 它 僅能 留存 最近 收集 到 的 指標 數據， 因此， 如果 用戶 期望 訪問 歷史 數據， 就不 得不 借助於 第三方 的 監控 系統（ 如 Prometheus 等）。
一般說來， Metrics Server 在 每個 集群 中 僅 會 運行 一個 實例， 啟動 時， 它將 自動 初始化 與 各 節點 的 連接， 因此 出於 安全 方面 的 考慮， 它 需要 運行 於 普通 節點 而非 Master 主機 之上。 直接 使用 項目 本身 提供 的 資源 配置 清單 即 能 輕松 完成 metrics- server 的 部署。
k8s的prometheus監控
1、Prometheus概述
除了前面的資源指標（如CPU、內存）以外，用戶或管理員需要了解更多的指標數據，比如Kubernetes指標、容器指標、節點資源指標以及應用程序指標等等。自定義指標API允許請求任意的指標，其指標API的實現要指定相應的后端監視系統。而Prometheus是第一個開發了相應適配器的監控系統。這個適用於Prometheus的Kubernetes Customm Metrics Adapter是屬於Github上的k8s-prometheus-adapter項目提供的。其原理圖如下：
要知道的是prometheus本身就是一監控系統，也分為server端和agent端，server端從被監控主機獲取數據，而agent端需要部署一個node_exporter，主要用於數據采集和暴露節點的數據，那么 在獲取Pod級別或者是mysql等多種應用的數據，也是需要部署相關的exporter。我們可以通過PromQL的方式對數據進行查詢，但是由於本身prometheus屬於第三方的 解決方案，原生的k8s系統並不能對Prometheus的自定義指標進行解析，就需要借助於k8s-prometheus-adapter將這些指標數據查詢接口轉換為標准的Kubernetes自定義指標。
Prometheus是一個開源的服務監控系統和時序數據庫，其提供了通用的數據模型和快捷數據采集、存儲和查詢接口。它的核心組件Prometheus服務器定期從靜態配置的監控目標或者基於服務發現自動配置的目標中進行拉取數據，新拉取到啊的 數據大於配置的內存緩存區時，數據就會持久化到存儲設備當中。
每個被監控的主機都可以通過專用的exporter程序提供輸出監控數據的接口，並等待Prometheus服務器周期性的進行數據抓取。如果存在告警規則，則抓取到數據之后會根據規則進行計算，滿足告警條件則會生成告警，並發送到Alertmanager完成告警的匯總和分發。當被監控的目標有主動推送數據的需求時，可以以Pushgateway組件進行接收並臨時存儲數據，然后等待Prometheus服務器完成數據的采集。
任何被監控的目標都需要事先納入到監控系統中才能進行時序數據采集、存儲、告警和展示，監控目標可以通過配置信息以靜態形式指定，也可以讓Prometheus通過服務發現的機制進行動態管理。
監控代理程序：如node_exporter：收集主機的指標數據，如平均負載、CPU、內存、磁盤、網絡等等多個維度的指標數據。
kubelet（cAdvisor）：收集容器指標數據，也是K8S的核心指標收集，每個容器的相關指標數據包括：CPU使用率、限額、文件系統讀寫限額、內存使用率和限額、網絡報文發送、接收、丟棄速率等等。
API Server：收集API Server的性能指標數據，包括控制隊列的性能、請求速率和延遲時長等等
etcd：收集etcd存儲集群的相關指標數據
kube-state-metrics：該組件可以派生出k8s相關的多個指標數據，主要是資源類型相關的計數器和元數據信息，包括制定類型的對象總數、資源限額、容器狀態以及Pod資源標簽系列等。
Prometheus 能夠 直接 把 Kubernetes API Server 作為 服務 發現 系統 使用 進而 動態 發現 和 監控 集群 中的 所有 可被 監控 的 對象。 這里 需要 特別 說明 的 是， Pod 資源 需要 添加 下列 注解 信息 才 能被 Prometheus 系統 自動 發現 並 抓取 其 內建 的 指標 數據。
1） prometheus. io/ scrape： 用於 標識 是否 需要 被 采集 指標 數據， 布爾 型 值， true 或 false。
2） prometheus. io/ path： 抓取 指標 數據 時 使用 的 URL 路徑， 一般 為/ metrics。
3） prometheus. io/ port： 抓取 指標 數據 時 使 用的 套 接 字 端口， 如 8080。
另外， 僅 期望 Prometheus 為 后端 生成 自定義 指標 時 僅 部署 Prometheus 服務器 即可， 它 甚至 也不 需要 數據 持久 功能。 但 若要 配置 完整 功能 的 監控 系統， 管理員 還需 要在 每個 主機 上 部署 node_ exporter、 按 需 部署 其他 特有 類型 的 exporter 以及 Alertmanager。