如何專業(yè)化監(jiān)控一個(gè) Kubernetes 集群？

作者：佳旭 2021-06-15 09:33:44

云計(jì)算 Kubernetes 在生產(chǎn)環(huán)境應(yīng)用的普及度越來越廣、復(fù)雜度越來越高，隨之而來的穩(wěn)定性保障挑戰(zhàn)也越來越大

引言

Kubernetes 在生產(chǎn)環(huán)境應(yīng)用的普及度越來越廣、復(fù)雜度越來越高，隨之而來的穩(wěn)定性保障挑戰(zhàn)也越來越大。

如何構(gòu)建全面深入的可觀測(cè)性架構(gòu)和體系，是提升系統(tǒng)穩(wěn)定性的關(guān)鍵之因素一。ACK將可觀測(cè)性最佳實(shí)踐進(jìn)行沉淀，以阿里云產(chǎn)品功能的能力對(duì)用戶透出，可觀測(cè)性工具和服務(wù)成為基礎(chǔ)設(shè)施，賦能并幫助用戶使用產(chǎn)品功能，提升用戶 Kubernetes 集群的穩(wěn)定性保障和使用體驗(yàn)。

本文會(huì)介紹 Kubernetes 可觀測(cè)性系統(tǒng)的構(gòu)建，以及基于阿里云云產(chǎn)品實(shí)現(xiàn) Kubernetes 可觀測(cè)系統(tǒng)構(gòu)建的最佳實(shí)踐。

Kubernetes 系統(tǒng)的可觀測(cè)性架構(gòu)

Kubernetes 系統(tǒng)對(duì)于可觀測(cè)性方面的挑戰(zhàn)包括：

K8s 系統(tǒng)架構(gòu)的復(fù)雜性。系統(tǒng)包括控制面和數(shù)據(jù)面，各自包含多個(gè)相互通信的組件，控制面和數(shù)據(jù)間之間通過 kube-apiserver 進(jìn)行橋接聚合。
動(dòng)態(tài)性。Pod、Service 等資源動(dòng)態(tài)創(chuàng)建以及分配 IP，Pod 重建后也會(huì)分配新的資源和 IP，這就需要基于動(dòng)態(tài)服務(wù)發(fā)現(xiàn)來獲取監(jiān)測(cè)對(duì)象。
微服務(wù)架構(gòu)。應(yīng)用按照微服務(wù)架構(gòu)分解成多個(gè)組件，每個(gè)組件副本數(shù)可以根據(jù)彈性進(jìn)行自動(dòng)或者人工控制。
針對(duì) Kubernetes 系統(tǒng)可觀測(cè)性的挑戰(zhàn)，尤其在集群規(guī)模快速增長(zhǎng)的情況下，高效可靠的 Kubernetes 系統(tǒng)可觀測(cè)性能力，是系統(tǒng)穩(wěn)定性保障的基石。

那么，如何提升建設(shè)生產(chǎn)環(huán)境下的 Kubernetes 系統(tǒng)可觀測(cè)性能力呢？

Kubernetes 系統(tǒng)的可觀測(cè)性方案包括指標(biāo)、日志、鏈路追蹤、K8s Event 事件、NPD 框架等方式。每種方式可以從不同維度透視 Kubernetes 系統(tǒng)的狀態(tài)和數(shù)據(jù)。在生產(chǎn)環(huán)境，我們通常需要綜合使用各種方式，有時(shí)候還要運(yùn)用多種方式聯(lián)動(dòng)觀測(cè)，形成完善立體的可觀測(cè)性體系，提高對(duì)各種場(chǎng)景的覆蓋度，進(jìn)而提升 Kubernetes 系統(tǒng)的整體穩(wěn)定性。下面會(huì)概述生產(chǎn)環(huán)境下對(duì) K8s 系統(tǒng)的可觀測(cè)性解決方案。

指標(biāo)（Metrics）

Prometheus 是業(yè)界指標(biāo)類數(shù)據(jù)采集方案的事實(shí)標(biāo)準(zhǔn)，是開源的系統(tǒng)監(jiān)測(cè)和報(bào)警框架，靈感源自 Google 的 Borgmon 監(jiān)測(cè)系統(tǒng)。2012 年，SoundCloud 的 Google 前員工創(chuàng)造了 Prometheus，并作為社區(qū)開源項(xiàng)目進(jìn)行開發(fā)。2015 年，該項(xiàng)目正式發(fā)布。2016 年，Prometheus 加入 CNCF 云原生計(jì)算基金會(huì)。

Prometheus 具有以下特性：

多維的數(shù)據(jù)模型（基于時(shí)間序列的 Key、Value 鍵值對(duì)）
靈活的查詢和聚合語言 PromQL
提供本地存儲(chǔ)和分布式存儲(chǔ)
通過基于 HTTP 的 Pull 模型采集時(shí)間序列數(shù)據(jù)
可利用 Pushgateway（Prometheus 的可選中間件）實(shí)現(xiàn) Push 模式
可通過動(dòng)態(tài)服務(wù)發(fā)現(xiàn)或靜態(tài)配置發(fā)現(xiàn)目標(biāo)機(jī)器
支持多種圖表和數(shù)據(jù)大盤
Prometheus 可以周期性采集組件暴露在 HTTP(s) 端點(diǎn)的/metrics 下面的指標(biāo)數(shù)據(jù)，并存儲(chǔ)到 TSDB，實(shí)現(xiàn)基于 PromQL 的查詢和聚合功能。

對(duì)于 Kubernetes 場(chǎng)景下的指標(biāo)，可以從如下角度分類：

容器基礎(chǔ)資源指標(biāo)

采集源為 kubelet 內(nèi)置的 cAdvisor，提供容器內(nèi)存、CPU、網(wǎng)絡(luò)、文件系統(tǒng)等相關(guān)的指標(biāo)，指標(biāo)樣例包括：

容器當(dāng)前內(nèi)存使用字節(jié)數(shù) container_memory_usage_bytes；

容器網(wǎng)絡(luò)接收字節(jié)數(shù) container_network_receive_bytes_total；

容器網(wǎng)絡(luò)發(fā)送字節(jié)數(shù) container_network_transmit_bytes_total，等等。

Kubernetes 節(jié)點(diǎn)資源指標(biāo)

采集源為 node_exporter，提供節(jié)點(diǎn)系統(tǒng)和硬件相關(guān)的指標(biāo)，指標(biāo)樣例包括：節(jié)點(diǎn)總內(nèi)存 node_memory_MemTotal_bytes，節(jié)點(diǎn)文件系統(tǒng)空間 node_filesystem_size_bytes，節(jié)點(diǎn)網(wǎng)絡(luò)接口 ID node_network_iface_id，等等?；谠擃愔笜?biāo)，可以統(tǒng)計(jì)節(jié)點(diǎn)的 CPU/內(nèi)存/磁盤使用率等節(jié)點(diǎn)級(jí)別指標(biāo)。

Kubernetes 資源指標(biāo)

采集源為 kube-state-metrics，基于 Kubernetes API 對(duì)象生成指標(biāo)，提供 K8s 集群資源指標(biāo)，例如 Node、ConfigMap、Deployment、DaemonSet 等類型。以 Node 類型指標(biāo)為例，包括節(jié)點(diǎn) Ready 狀態(tài)指標(biāo) kube_node_status_condition、節(jié)點(diǎn)信息kube_node_info 等等。

Kubernetes 組件指標(biāo)

Kubernetes 系統(tǒng)組件指標(biāo)。例如 kube-controller-manager, kube-apiserver，kube-scheduler, kubelet，kube-proxy、coredns 等。

Kubernetes 運(yùn)維組件指標(biāo)?？捎^測(cè)類包括 blackbox_operator, 實(shí)現(xiàn)對(duì)用戶自定義的探活規(guī)則定義；gpu_exporter，實(shí)現(xiàn)對(duì) GPU 資源的透出能力。

Kubernetes 業(yè)務(wù)應(yīng)用指標(biāo)。包括具體的業(yè)務(wù) Pod在/metrics 路徑透出的指標(biāo)，以便外部進(jìn)行查詢和聚合。

除了上述指標(biāo)，K8s 提供了通過 API 方式對(duì)外透出指標(biāo)的監(jiān)測(cè)接口標(biāo)準(zhǔn)，具體包括 Resource Metrics，Custom Metrics 和 External Metrics 三類。

Resource Metrics類對(duì)應(yīng)接口 metrics.k8s.io，主要的實(shí)現(xiàn)就是 metrics-server，它提供資源的監(jiān)測(cè)，比較常見的是節(jié)點(diǎn)級(jí)別、pod 級(jí)別、namespace 級(jí)別。這些指標(biāo)可以通過 kubectl top 直接訪問獲取，或者通過 K8s controller 獲取，例如 HPA(Horizontal Pod Autoscaler)。系統(tǒng)架構(gòu)以及訪問鏈路如下：

Custom Metrics 對(duì)應(yīng)的 API 是 custom.metrics.k8s.io，主要的實(shí)現(xiàn)是 Prometheus。它提供的是資源監(jiān)測(cè)和自定義監(jiān)測(cè)，資源監(jiān)測(cè)和上面的資源監(jiān)測(cè)其實(shí)是有覆蓋關(guān)系的，而這個(gè)自定義監(jiān)測(cè)指的是：比如應(yīng)用上面想暴露一個(gè)類似像在線人數(shù)，或者說調(diào)用后面的這個(gè)數(shù)據(jù)庫的 MySQL 的慢查詢。這些其實(shí)都是可以在應(yīng)用層做自己的定義的，然后并通過標(biāo)準(zhǔn)的 Prometheus 的 client，暴露出相應(yīng)的 metrics，然后再被 Prometheus 進(jìn)行采集。

而這類的接口一旦采集上來也是可以通過類似像 custom.metrics.k8s.io 這樣一個(gè)接口的標(biāo)準(zhǔn)來進(jìn)行數(shù)據(jù)消費(fèi)的，也就是說現(xiàn)在如果以這種方式接入的 Prometheus，那你就可以通過 custom.metrics.k8s.io 這個(gè)接口來進(jìn)行 HPA，進(jìn)行數(shù)據(jù)消費(fèi)。系統(tǒng)架構(gòu)以及訪問鏈路如下：

External Metrics。因?yàn)槲覀冎?K8s 現(xiàn)在已經(jīng)成為了云原生接口的一個(gè)實(shí)現(xiàn)標(biāo)準(zhǔn)。很多時(shí)候在云上打交道的是云服務(wù)，比如說在一個(gè)應(yīng)用里面用到了前面的是消息隊(duì)列，后面的是 RBS 數(shù)據(jù)庫。那有時(shí)在進(jìn)行數(shù)據(jù)消費(fèi)的時(shí)候，同時(shí)需要去消費(fèi)一些云產(chǎn)品的監(jiān)測(cè)指標(biāo)，類似像消息隊(duì)列中消息的數(shù)目，或者是接入層 SLB 的 connection 數(shù)目，SLB 上層的 200 個(gè)請(qǐng)求數(shù)目等等，這些監(jiān)測(cè)指標(biāo)。

那怎么去消費(fèi)呢？也是在 K8s 里面實(shí)現(xiàn)了一個(gè)標(biāo)準(zhǔn)，就是 external.metrics.k8s.io。主要的實(shí)現(xiàn)廠商就是各個(gè)云廠商的 provider，通過這個(gè) provider 可以通過云資源的監(jiān)測(cè)指標(biāo)。在阿里云上面也實(shí)現(xiàn)了阿里巴巴 cloud metrics adapter 用來提供這個(gè)標(biāo)準(zhǔn)的 external.metrics.k8s.io 的一個(gè)實(shí)現(xiàn)。

日志（Logging）

概要來說包括：

主機(jī)內(nèi)核的日志。主機(jī)內(nèi)核日志可以協(xié)助開發(fā)者診斷例如：網(wǎng)絡(luò)棧異常，驅(qū)動(dòng)異常，文件系統(tǒng)異常，影響節(jié)點(diǎn)（內(nèi)核）穩(wěn)定的異常。
Runtime 日志。最常見的運(yùn)行時(shí)是 Docker，可以通過 Docker 的日志排查例如刪除 Pod Hang 等問題。
K8s 組件日志。APIServer 日志可以用來審計(jì)，Scheduler 日志可以診斷調(diào)度，etcd 日志可以查看存儲(chǔ)狀態(tài)，Ingress 日志可以分析接入層流量。
應(yīng)用日志。可以通過應(yīng)用日志分析查看業(yè)務(wù)層的狀態(tài)，診斷異常。
日志的采集方式分為被動(dòng)采集和主動(dòng)推送兩種，在 K8s 中，被動(dòng)采集一般分為 Sidecar 和 DaemonSet 兩種方式，主動(dòng)推送有 DockerEngine 推送和業(yè)務(wù)直寫兩種方式。

DockerEngine 本身具有 LogDriver 功能，可通過配置不同的 LogDriver 將容器的 stdout 通過 DockerEngine 寫入到遠(yuǎn)端存儲(chǔ)，以此達(dá)到日志采集的目的。這種方式的可定制化、靈活性、資源隔離性都很低，一般不建議在生產(chǎn)環(huán)境中使用；
業(yè)務(wù)直寫是在應(yīng)用中集成日志采集的 SDK，通過 SDK 直接將日志發(fā)送到服務(wù)端。這種方式省去了落盤采集的邏輯，也不需要額外部署 Agent，對(duì)于系統(tǒng)的資源消耗最低，但由于業(yè)務(wù)和日志 SDK 強(qiáng)綁定，整體靈活性很低，一般只有日志量極大的場(chǎng)景中使用；
DaemonSet 方式在每個(gè) node 節(jié)點(diǎn)上只運(yùn)行一個(gè)日志 agent，采集這個(gè)節(jié)點(diǎn)上所有的日志。DaemonSet 相對(duì)資源占用要小很多，但擴(kuò)展性、租戶隔離性受限，比較適用于功能單一或業(yè)務(wù)不是很多的集群；
Sidecar 方式為每個(gè) POD 單獨(dú)部署日志 agent，這個(gè) agent 只負(fù)責(zé)一個(gè)業(yè)務(wù)應(yīng)用的日志采集。Sidecar 相對(duì)資源占用較多，但靈活性以及多租戶隔離性較強(qiáng)，建議大型的 K8s 集群或作為 PaaS 平臺(tái)為多個(gè)業(yè)務(wù)方服務(wù)的集群使用該方式。
掛載宿主機(jī)采集、標(biāo)準(zhǔn)輸入輸出采集、Sidecar 采集。

總結(jié)下來：

DockerEngine 直寫一般不推薦；
業(yè)務(wù)直寫推薦在日志量極大的場(chǎng)景中使用；
DaemonSet 一般在中小型集群中使用；
Sidecar 推薦在超大型的集群中使用。

事件（Event）

事件監(jiān)測(cè)是適用于 Kubernetes 場(chǎng)景的一種監(jiān)測(cè)方式。事件包含了發(fā)生的時(shí)間、組件、等級(jí)（Normal、Warning）、類型、詳細(xì)信息，通過事件我們能夠知道應(yīng)用的部署、調(diào)度、運(yùn)行、停止等整個(gè)生命周期，也能通過事件去了解系統(tǒng)中正在發(fā)生的一些異常。

K8s 中的一個(gè)設(shè)計(jì)理念，就是基于狀態(tài)機(jī)的一個(gè)狀態(tài)轉(zhuǎn)換。從正常的狀態(tài)轉(zhuǎn)換成另一個(gè)正常的狀態(tài)的時(shí)候，會(huì)發(fā)生一個(gè) Normal 的事件，而從一個(gè)正常狀態(tài)轉(zhuǎn)換成一個(gè)異常狀態(tài)的時(shí)候，會(huì)發(fā)生一個(gè) Warning 的事件。通常情況下，Warning 的事件是我們比較關(guān)心的。事件監(jiān)測(cè)就是把 Normal 的事件或者是 Warning 事件匯聚到數(shù)據(jù)中心，然后通過數(shù)據(jù)中心的分析以及報(bào)警，把相應(yīng)的一些異常通過像釘釘、短信、郵件等方式進(jìn)行暴露，實(shí)現(xiàn)與其他監(jiān)測(cè)的補(bǔ)充與完善。

Kubernetes中的事件是存儲(chǔ)在 etcd 中，默認(rèn)情況下只保存 1 個(gè)小時(shí)，無法實(shí)現(xiàn)較長(zhǎng)周期范圍的分析。將事件進(jìn)行長(zhǎng)期存儲(chǔ)以及定制化開發(fā)后，可以實(shí)現(xiàn)更加豐富多樣的分析與告警：

對(duì)系統(tǒng)中的異常事件做實(shí)時(shí)告警，例如 Failed、Evicted、FailedMount、FailedScheduling 等。
通常問題排查可能要去查找歷史數(shù)據(jù)，因此需要去查詢更長(zhǎng)時(shí)間范圍的事件（幾天甚至幾個(gè)月）。
事件支持歸類統(tǒng)計(jì)，例如能夠計(jì)算事件發(fā)生的趨勢(shì)以及與上一時(shí)間段（昨天/上周/發(fā)布前）對(duì)比，以便基于統(tǒng)計(jì)指標(biāo)進(jìn)行判斷和決策。
支持不同的人員按照各種維度去做過濾、篩選。
支持自定義的訂閱這些事件去做自定義的監(jiān)測(cè)，以便和公司內(nèi)部的部署運(yùn)維平臺(tái)集成。

NPD（Node Problem Detector）框架

Kubernetes 集群及其運(yùn)行容器的穩(wěn)定性，強(qiáng)依賴于節(jié)點(diǎn)的穩(wěn)定性。Kubernetes 中的相關(guān)組件只關(guān)注容器管理相關(guān)的問題，對(duì)于硬件、操作系統(tǒng)、容器運(yùn)行時(shí)、依賴系統(tǒng)（網(wǎng)絡(luò)、存儲(chǔ)等）并不會(huì)提供更多的檢測(cè)能力。NPD（Node Problem Detector）針對(duì)節(jié)點(diǎn)的穩(wěn)定性提供了診斷檢查框架，在默認(rèn)檢查策略的基礎(chǔ)上，可以靈活擴(kuò)展檢查策略，可以將節(jié)點(diǎn)的異常轉(zhuǎn)換為 Node 的事件，推送到 APIServer 中，由同一的 APIServer 進(jìn)行事件管理。

NPD 支持多種異常檢查，例如：

基礎(chǔ)服務(wù)問題：NTP 服務(wù)未啟動(dòng)
硬件問題：CPU、內(nèi)存、磁盤、網(wǎng)卡損壞
Kernel 問題：Kernel hang，文件系統(tǒng)損壞
容器運(yùn)行時(shí)問題：Docker hang，Docker 無法啟動(dòng)
資源問題：OOM 等

綜上，本章節(jié)總結(jié)了常見的 Kubernetes 可觀測(cè)性方案。在生產(chǎn)環(huán)境，我們通常需要綜合使用各種方案，形成立體多維度、相互補(bǔ)充的可觀測(cè)性體系；可觀測(cè)性方案部署后，需要基于上述方案的輸出結(jié)果快速診斷異常和錯(cuò)誤，有效降低誤報(bào)率，并有能力保存、回查以及分析歷史數(shù)據(jù)；進(jìn)一步延伸，數(shù)據(jù)可以提供給機(jī)器學(xué)習(xí)以及 AI 框架，實(shí)現(xiàn)彈性預(yù)測(cè)、異常診斷分析、智能運(yùn)維 AIOps 等高級(jí)應(yīng)用場(chǎng)景。

這需要可觀測(cè)性最佳實(shí)踐作為基礎(chǔ)，包括如何設(shè)計(jì)、插件化部署、配置、升級(jí)上述各種可觀測(cè)性方案架構(gòu)，如何基于輸出結(jié)果快速準(zhǔn)確診斷分析跟因等等。阿里云容器服務(wù) ACK 以及相關(guān)云產(chǎn)品（監(jiān)測(cè)服務(wù) ARMS、日志服務(wù) SLS 等），將云廠商的最佳實(shí)踐通過產(chǎn)品化能力實(shí)現(xiàn)、賦能用戶，提供了完善全面的解決方案，可以讓用戶快速部署、配置、升級(jí)、掌握阿里云的可觀測(cè)性方案，顯著提升了企業(yè)上云和云原生化的效率和穩(wěn)定性、降低技術(shù)門檻和綜合成本。

下面將以 ACK 最新的產(chǎn)品形態(tài) ACK Pro 為例，結(jié)合相關(guān)云產(chǎn)品，介紹 ACK 的可觀測(cè)性解決方案和最佳實(shí)踐。

ACK可觀測(cè)性能力

指標(biāo)（Metrics）可觀測(cè)性方案

對(duì)于指標(biāo)類可觀測(cè)性，ACK 可以支持開源 Prometheus 監(jiān)測(cè)和阿里云 Prometheus 監(jiān)測(cè)（阿里云 Prometheus 監(jiān)測(cè)是 ARMS 產(chǎn)品子產(chǎn)品）兩種可觀測(cè)性方案。

開源 Prometheus 監(jiān)測(cè)，以 helm 包形式提供、適配阿里云環(huán)境、集成了釘釘告警、存儲(chǔ)等功能；部署入口在控制臺(tái)的應(yīng)用目錄中 ack-prometheus-operator，用戶配置后可以在 ACK 控制臺(tái)一鍵部署。用戶只需要在阿里云 ACK 控制臺(tái)配置 helm 包參數(shù)，就可以定制化部署。

阿里云 Prometheus監(jiān)測(cè)，是 ARMS 產(chǎn)品子產(chǎn)品。應(yīng)用實(shí)時(shí)監(jiān)測(cè)服務(wù) (Application Real-Time Monitoring Service, 簡(jiǎn)稱 ARMS) 是一款應(yīng)用性能管理產(chǎn)品，包含前端監(jiān)測(cè)，應(yīng)用監(jiān)測(cè)和 Prometheus 監(jiān)測(cè)三大子產(chǎn)品。

在 2021 年的 Gartner 的 APM 魔力象限評(píng)測(cè)中，阿里云應(yīng)用實(shí)時(shí)監(jiān)測(cè)服務(wù)（ARMS）作為阿里云 APM 的核心產(chǎn)品，聯(lián)合云監(jiān)測(cè)以及日志服務(wù)共同參與。Gartner 評(píng)價(jià)阿里云 APM：

中國(guó)影響力最強(qiáng)：阿里云是中國(guó)最大的云服務(wù)提供商，阿里云用戶可以使用云上監(jiān)測(cè)工具來滿足其可觀測(cè)性需求。
開源集成：阿里云非常重視將開源標(biāo)準(zhǔn)和產(chǎn)品（例如 Prometheus）集成到其平臺(tái)中。
成本優(yōu)勢(shì)：與在阿里云上使用第三方 APM 產(chǎn)品相比，阿里云 APM 產(chǎn)品具有更高的成本效益。
下圖概要對(duì)比了開源 Prometheus 和阿里云 Prometheus 的模塊劃分和數(shù)據(jù)鏈路。

ACK 支持 CoreDNS、集群節(jié)點(diǎn)、集群概況等 K8s 可觀測(cè)性能力；除此之外，ACK Pro 還支持托管的管控組件 Kube API Server、Kube Scheduler 和 Etcd 的可觀測(cè)性能力，并持續(xù)迭代。用戶可以通過在阿里云 Prometheus 中豐富的監(jiān)測(cè)大盤，結(jié)合告警能力，快速發(fā)現(xiàn) K8s 集群的系統(tǒng)問題以及潛在風(fēng)險(xiǎn)，及時(shí)采取相應(yīng)措施以保障集群穩(wěn)定性。監(jiān)測(cè)大盤集成了 ACK 最佳實(shí)踐的經(jīng)驗(yàn)，可以幫助用戶從多維度分析分析、定位問題。下面介紹如何基于最佳實(shí)踐設(shè)計(jì)可觀測(cè)性大盤，并列舉使用監(jiān)測(cè)大盤定位問題的具體案例，幫助理解如何使用可觀測(cè)性能力。

首先來看 ACK Pro 的可觀測(cè)性能力。監(jiān)測(cè)大盤入口如下：

APIServer 是 K8s 核心組件之一，是 K8s 組件進(jìn)行交互的樞紐，ACK Pro APIServer 的監(jiān)測(cè)大盤設(shè)計(jì)考慮到用戶可以選擇需要監(jiān)測(cè)的 APIServer Pod 來分析單一指標(biāo)、聚合指標(biāo)以及請(qǐng)求來源等，同時(shí)可以下鉆到某一種或者多種 API 資源聯(lián)動(dòng)觀測(cè) APIServer 的指標(biāo)，這樣的優(yōu)勢(shì)是既可以全局觀測(cè)全部 APIServer Pod 的全局視圖，又可以下鉆觀測(cè)到具體 APIServer Pod 以及具體 API 資源的監(jiān)測(cè)，監(jiān)測(cè)全部和局部觀測(cè)能力，對(duì)于定位問題非常有效。所以根據(jù) ACK 的最佳實(shí)踐，實(shí)現(xiàn)上包含了如下 5 個(gè)模塊：

提供 APIServer Pod、API 資源（Pods，Nodes，ConfigMaps 等）、分位數(shù)（0.99，0.9，0.5）、統(tǒng)計(jì)時(shí)間間隔的篩選框，用戶通過控制篩選框，可以聯(lián)動(dòng)控制監(jiān)測(cè)大盤實(shí)現(xiàn)聯(lián)動(dòng)
凸顯關(guān)鍵指標(biāo)以便識(shí)別系統(tǒng)關(guān)鍵狀態(tài)
展示 APIServer RT、QPS 等單項(xiàng)指標(biāo)的監(jiān)測(cè)大盤，實(shí)現(xiàn)單一維度指標(biāo)的觀測(cè)
展示 APIServer RT、QPS 等聚合指標(biāo)的監(jiān)測(cè)大盤，實(shí)現(xiàn)多維度指標(biāo)的觀測(cè)
展示對(duì) APIServer 訪問的客戶端來源分析，實(shí)現(xiàn)訪問源的分析
下面概要介紹模塊的實(shí)現(xiàn)。

關(guān)鍵指標(biāo)

顯示了核心的指標(biāo)，包括 APIServer 總 QPS、讀請(qǐng)求成功率、寫請(qǐng)求成功率、Read Inflight Request、Mutating Inflight Request 以及單位時(shí)間丟棄請(qǐng)求數(shù)量 Dropped Requests Rate。

這些指標(biāo)可以概要展示系統(tǒng)狀態(tài)是否正常，例如如果 Dropped Requests Rate 不為 NA，說明 APIServer 因?yàn)樘幚碚?qǐng)求的能力不能滿足請(qǐng)求出現(xiàn)丟棄請(qǐng)求，需要立即定位處理。

Cluster-Level Summary

包括讀非 LIST 讀請(qǐng)求 RT、LIST 讀請(qǐng)求 RT、寫請(qǐng)求 RT、讀請(qǐng)求 Inflight Request、修改請(qǐng)求 Inflight Request 以及單位時(shí)間丟棄請(qǐng)求數(shù)量，該部分大盤的實(shí)現(xiàn)結(jié)合了 ACK 最佳實(shí)踐經(jīng)驗(yàn)。

對(duì)于響應(yīng)時(shí)間的可觀測(cè)性，可以直觀的觀察到不同時(shí)間點(diǎn)以及區(qū)間內(nèi)，針對(duì)不同資源、不同操作、不同范圍的響應(yīng)時(shí)間?？梢赃x擇不同的分位數(shù)，來篩選。有兩個(gè)比較重要的考察點(diǎn)：

曲線是否連續(xù)
RT 時(shí)間
先來解釋曲線的連續(xù)性。通過曲線的連續(xù)性，可以很直觀的看出請(qǐng)求是持續(xù)的請(qǐng)求，還是單一的請(qǐng)求。

下圖表示在采樣周期內(nèi)，APIServer 收到 PUT leases 的請(qǐng)求，每個(gè)采樣期內(nèi) P90 RT 是 45ms。

因?yàn)閳D中曲線是連續(xù)，說明該請(qǐng)求在全部采樣周期都存在，所以是持續(xù)的請(qǐng)求。

下圖表示在采樣周期內(nèi)，APIServer 收到 LIST daemonsets 的請(qǐng)求，有樣值的采樣周期內(nèi) P90 RT 是 45ms。

因?yàn)閳D中只有一次，說明該請(qǐng)求只是在一次采樣周期存在。該場(chǎng)景來自于用戶執(zhí)行 kubectl get ds --all-namespaces 產(chǎn)生的請(qǐng)求記錄。

I0215 23:32:19.226433       1 trace.go:116] Trace[1528486772]: "Create" url:/api/v1/namespaces/default/configmaps,user-agent:kubectl/v1.18.8 (linux/amd64) kubernetes/d2f5a0f,client:39.x.x.10,request_id:a1724f0b-39f1-40da-b36c-e447933ef37e (started: 2021-02-15 23:32:09.485986411 +0800 CST m=+114176.845042584) (total time: 9.740403082s):Trace[1528486772]: [9.647465583s] [9.647465583s] About to convert to expected versionTrace[1528486772]: [9.660554709s] [13.089126ms] Conversion doneTrace[1528486772]: [9.660561026s] [6.317s] About to store object in databaseTrace[1528486772]: [9.687076754s] [26.515728ms] Object stored in databaseTrace[1528486772]: [9.740403082s] [53.326328ms] ENDI0215 23:32:19.226568       1 httplog.go:102] requestID=a1724f0b-39f1-40da-b36c-e447933ef37e verb=POST URI=/api/v1/namespaces/default/configmaps latency=9.740961791s resp=201 UserAgent=kubectl/v1.18.8 (linux/amd64) kubernetes/d2f5a0f srcIP="10.x.x.10:59256" ContentType=application/json:

下面解釋一下RT與請(qǐng)求的具體內(nèi)容以及集群規(guī)模有直接的關(guān)聯(lián)。

在上述創(chuàng)建 configmap 的例子中，同樣是創(chuàng)建 1MB 的 configmap，公網(wǎng)鏈路受網(wǎng)路帶寬和時(shí)延影響，達(dá)到了 9s；而在內(nèi)網(wǎng)鏈路的測(cè)試中，只需要 145ms，網(wǎng)絡(luò)因素的影響是顯著的。

所以 RT 與請(qǐng)求操作的資源對(duì)象、字節(jié)尺寸、網(wǎng)絡(luò)等有關(guān)聯(lián)關(guān)系，網(wǎng)絡(luò)越慢，字節(jié)尺寸越大，RT 越大。

對(duì)于大規(guī)模 K8s 集群，全量 LIST（例如 pods，nodes 等資源）的數(shù)據(jù)量有時(shí)候會(huì)很大，導(dǎo)致傳輸數(shù)據(jù)量增加，也會(huì)導(dǎo)致 RT 增加。所以對(duì)于 RT 指標(biāo)，沒有絕對(duì)的健康閾值，一定需要結(jié)合具體的請(qǐng)求操作、集群規(guī)模、網(wǎng)絡(luò)帶寬來綜合評(píng)定，如果不影響業(yè)務(wù)就可以接受。

對(duì)于小規(guī)模 K8s 集群，平均 RT 45ms 到 100ms 是可以接受的；對(duì)于節(jié)點(diǎn)規(guī)模上 100 的集群，平均 RT 100ms 到 200ms 是可以接受的。

但是如果 RT 持續(xù)達(dá)到秒級(jí)，甚至 RT 達(dá)到 60s 導(dǎo)致請(qǐng)求超時(shí)，多數(shù)情況下出現(xiàn)了異常，需要進(jìn)一步定位處理是否符合預(yù)期。

這兩個(gè)指標(biāo)通過 APIServer /metrics 對(duì)外透出，可以執(zhí)行如下命令查看 inflight requests，是衡量 APIServer 處理并發(fā)請(qǐng)求能力的指標(biāo)。如果請(qǐng)求并發(fā)請(qǐng)求過多達(dá)到 APIServer 參數(shù) max-requests-inflight和 max-mutating-requests-inflight 指定的閾值，就會(huì)觸發(fā) APIServer 限流。通常這是異常情況，需要快速定位并處理。

QPS & Latency

該部分可以直觀顯示請(qǐng)求 QPS 以及 RT 按照 Verb、API 資源進(jìn)行分類的情況，以便進(jìn)行聚合分析。還可以展示讀、寫請(qǐng)求的錯(cuò)誤碼分類，可以直觀發(fā)現(xiàn)不同時(shí)間點(diǎn)下請(qǐng)求返回的錯(cuò)誤碼類型。

Client Summary

該部分可以直觀顯示請(qǐng)求的客戶端以及操作和資源。

QPS By Client 可以按客戶端維度，統(tǒng)計(jì)不同客戶端的QPS值。

QPS By Verb + Resource + Client 可以按客戶端、Verb、Resource 維度，統(tǒng)計(jì)單位時(shí)間（1s）內(nèi)的請(qǐng)求分布情況。

基于 ARMS Prometheus，除了 APIServer 大盤，ACK Pro 還提供了 Etcd 和 Kube Scheduler 的監(jiān)測(cè)大盤；ACK 和 ACK Pro 還提供了 CoreDNS、K8s 集群、K8s 節(jié)點(diǎn)、Ingress 等大盤，這里不再一一介紹，用戶可以查看 ARMS 的大盤。這些大盤結(jié)合了 ACK 和 ARMS 的在生產(chǎn)環(huán)境的最佳實(shí)踐，可以幫助用戶以最短路徑觀測(cè)系統(tǒng)、發(fā)現(xiàn)問題根源、提高運(yùn)維效率。

日志（Logging）可觀測(cè)性方案

SLS 阿里云日志服務(wù)是阿里云標(biāo)準(zhǔn)的日志方案，對(duì)接各種類型的日志存儲(chǔ)。

對(duì)于托管側(cè)組件的日志，ACK 支持托管集群控制平面組件（kube-apiserver/kube-controller-manager/kube-scheduler）日志透出，將日志從 ACK 控制層采集到到用戶 SLS 日志服務(wù)的 Log Project 中。

對(duì)于用戶側(cè)日志，用戶可以使用阿里云的 logtail、log-pilot 技術(shù)方案將需要的容器、系統(tǒng)、節(jié)點(diǎn)日志收集到 SLS 的 logstore，隨后就可以在 SLS 中方便的查看日志。

事件（Event）可觀測(cè)性方案 + NPD 可觀測(cè)性方案

Kubernetes 的架構(gòu)設(shè)計(jì)基于狀態(tài)機(jī)，不同的狀態(tài)之間進(jìn)行轉(zhuǎn)換則會(huì)生成相應(yīng)的事件，正常的狀態(tài)之間轉(zhuǎn)換會(huì)生成 Normal 等級(jí)的事件，正常狀態(tài)與異常狀態(tài)之間的轉(zhuǎn)換會(huì)生成 Warning 等級(jí)的事件。

ACK 提供開箱即用的容器場(chǎng)景事件監(jiān)測(cè)方案，通過 ACK 維護(hù)的 NPD（node-problem-detector）以及包含在 NPD 中的 kube-eventer 提供容器事件監(jiān)測(cè)能力。

NPD（node-problem-detector）是 Kubernetes 節(jié)點(diǎn)診斷的工具，可以將節(jié)點(diǎn)的異常，例如 Docker Engine Hang、Linux Kernel Hang、網(wǎng)絡(luò)出網(wǎng)異常、文件描述符異常轉(zhuǎn)換為 Node 的事件，結(jié)合 kube-eventer 可以實(shí)現(xiàn)節(jié)點(diǎn)事件告警的閉環(huán)。
kube-eventer 是 ACK 維護(hù)的開源 Kubernetes 事件離線工具，可以將集群的事件離線到釘釘、SLS、EventBridge 等系統(tǒng)，并提供不同等級(jí)的過濾條件，實(shí)現(xiàn)事件的實(shí)時(shí)采集、定向告警、異步歸檔。
NPD 根據(jù)配置與第三方插件檢測(cè)節(jié)點(diǎn)的問題或故障，生成相應(yīng)的集群事件。而Kubernetes集群自身也會(huì)因?yàn)榧籂顟B(tài)的切換產(chǎn)生各種事件。例如 Pod 驅(qū)逐，鏡像拉取失敗等異常情況。日志服務(wù) SLS（Log Service）的 Kubernetes 事件中心實(shí)時(shí)匯聚 Kubernetes 中的所有事件并提供存儲(chǔ)、查詢、分析、可視化、告警等能力。

ACK可觀測(cè)性展望

ACK 以及相關(guān)云產(chǎn)品對(duì) Kubernetes 集群已經(jīng)實(shí)現(xiàn)了全面的觀測(cè)能力，包括指標(biāo)、日志、鏈路追蹤、事件等。后面發(fā)展的方向包括：

挖掘更多應(yīng)用場(chǎng)景，將應(yīng)用場(chǎng)景與可觀測(cè)性關(guān)聯(lián)，幫助用戶更好的使用K8s。例如監(jiān)測(cè)一段時(shí)間內(nèi) Pod 中容器的內(nèi)存/CPU 等資源水位，利用歷史數(shù)據(jù)分析用戶的Kubernets 容器資源 requests/limits 是否合理，如果不合理給出推薦的容器資源 requests/limits；監(jiān)測(cè)集群 APIServer RT 過大的請(qǐng)求，自動(dòng)分析異常請(qǐng)求的原因以及處理建議；
聯(lián)動(dòng)多種可觀測(cè)性技術(shù)方案，例如K8s事件和指標(biāo)監(jiān)測(cè)，提供更加豐富和更多維度的可觀測(cè)性能力。
我們相信 ACK 可觀測(cè)性未來的發(fā)展方向會(huì)越來越廣闊，給客戶帶來越來越出色的技術(shù)價(jià)值和社會(huì)價(jià)值！

本文名稱：如何專業(yè)化監(jiān)控一個(gè) Kubernetes 集群？
網(wǎng)站URL：http://m.fisionsoft.com.cn/article/dhepjpo.html