引言

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

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

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

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

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

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

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

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

指標(biāo)（Metrics）

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

Prometheus 具有以下特性：

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

對于 Kubernetes 場景下的指標(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é)點資源指標(biāo)

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

Kubernetes 資源指標(biāo)

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

Kubernetes 組件指標(biāo)

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

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

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

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

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

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

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

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

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

日志（Logging）

概要來說包括：

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

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

總結(jié)下來：

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

事件（Event）

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

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

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

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

NPD（Node Problem Detector）框架

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

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

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

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

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

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

ACK可觀測性能力

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

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

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

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

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

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

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

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

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

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

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

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

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

Cluster-Level Summary

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

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

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

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

因為圖中曲線是連續(xù)，說明該請求在全部采樣周期都存在，所以是持續(xù)的請求。

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

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

 

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與請求的具體內(nèi)容以及集群規(guī)模有直接的關(guān)聯(lián)。

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

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

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

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

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

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

QPS & Latency

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

Client Summary

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

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

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

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

日志（Logging）可觀測性方案

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

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

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

事件（Event）可觀測性方案 + NPD 可觀測性方案

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

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

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

ACK可觀測性展望

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

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