作者：佳旭 阿裡雲容器服務技術專家
引言
Kubernetes 在生産環境應用的普及度越來越廣、複雜度越來越高，随之而來的穩定性保障挑戰也越來越大。
如何建構全面深入的可觀測性架構和體系，是提升系統穩定性的關鍵之因素一。ACK将可觀測性最佳實踐進行沉澱，以阿裡雲産品功能的能力對使用者透出，可觀測性工具和服務成為基礎設施，賦能并幫助使用者使用産品功能，提升使用者 Kubernetes 叢集的穩定性保障和使用體驗。
本文會介紹 Kubernetes 可觀測性系統的建構，以及基于阿裡雲雲産品實作 Kubernetes 可觀測系統建構的最佳實踐。
Kubernetes 系統的可觀測性架構
Kubernetes 系統對于可觀測性方面的挑戰包括：
- K8s 系統架構的複雜性。系統包括控制面和資料面，各自包含多個互相通信的元件，控制面和資料間之間通過 kube-apiserver 進行橋接聚合。
- 動态性。Pod、Service 等資源動态建立以及配置設定 IP，Pod 重建後也會配置設定新的資源和 IP，這就需要基于動态服務發現來擷取監測對象。
- 微服務架構。應用按照微服務架構分解成多個元件，每個元件副本數可以根據彈性進行自動或者人工控制。
針對 Kubernetes 系統可觀測性的挑戰，尤其在叢集規模快速增長的情況下，高效可靠的 Kubernetes 系統可觀測性能力，是系統穩定性保障的基石。
那麼，如何提升建設生産環境下的 Kubernetes 系統可觀測性能力呢？
Kubernetes 系統的可觀測性方案包括名額、日志、鍊路追蹤、K8s Event 事件、NPD 架構等方式。每種方式可以從不同次元透視 Kubernetes 系統的狀态和資料。在生産環境，我們通常需要綜合使用各種方式，有時候還要運用多種方式關聯觀測，形成完善立體的可觀測性體系，提高對各種場景的覆寫度，進而提升 Kubernetes 系統的整體穩定性。下面會概述生産環境下對 K8s 系統的可觀測性解決方案。
名額（Metrics）
Prometheus 是業界名額類資料采集方案的事實标準，是開源的系統監測和報警架構，靈感源自 Google 的 Borgmon 監測系統。2012 年，SoundCloud 的 Google 前員工創造了 Prometheus，并作為社群開源項目進行開發。2015 年，該項目正式釋出。2016 年，Prometheus 加入 CNCF 雲原生計算基金會。
Prometheus 具有以下特性：
- 多元的資料模型（基于時間序列的 Key、Value 鍵值對）
- 靈活的查詢和聚合語言 PromQL
- 提供本地存儲和分布式存儲
- 通過基于 HTTP 的 Pull 模型采集時間序列資料
- 可利用 Pushgateway（Prometheus 的可選中間件）實作 Push 模式
- 可通過動态服務發現或靜态配置發現目标機器
- 支援多種圖表和資料大盤
Prometheus 可以周期性采集元件暴露在 HTTP(s) 端點的/metrics 下面的名額資料，并存儲到 TSDB，實作基于 PromQL 的查詢和聚合功能。
對于 Kubernetes 場景下的名額，可以從如下角度分類：
- 容器基礎資源名額
采集源為 kubelet 内置的 cAdvisor，提供容器記憶體、CPU、網絡、檔案系統等相關的名額，名額樣例包括：
容器目前記憶體使用位元組數 container_memory_usage_bytes；
容器網絡接收位元組數 container_network_receive_bytes_total；
容器網絡發送位元組數 container_network_transmit_bytes_total，等等。
- Kubernetes 節點資源名額
采集源為 node_exporter，提供節點系統和硬體相關的名額，名額樣例包括：節點總記憶體 node_memory_MemTotal_bytes，節點檔案系統空間 node_filesystem_size_bytes，節點網絡接口 ID node_network_iface_id，等等。基于該類名額，可以統計節點的 CPU/記憶體/磁盤使用率等節點級别名額。
- Kubernetes 資源名額
采集源為 kube-state-metrics，基于 Kubernetes API 對象生成名額，提供 K8s 叢集資源名額，例如 Node、ConfigMap、Deployment、DaemonSet 等類型。以 Node 類型名額為例，包括節點 Ready 狀态名額 kube_node_status_condition、節點資訊kube_node_info 等等。
- Kubernetes 元件名額
Kubernetes 系統元件名額。例如 kube-controller-manager, kube-apiserver，kube-scheduler, kubelet，kube-proxy、coredns 等。
Kubernetes 運維元件名額。可觀測類包括 blackbox_operator, 實作對使用者自定義的探活規則定義；gpu_exporter，實作對 GPU 資源的透出能力。
Kubernetes 業務應用名額。包括具體的業務 Pod在/metrics 路徑透出的名額，以便外部進行查詢和聚合。
除了上述名額，K8s 提供了通過 API 方式對外透出名額的監測接口标準，具體包括 Resource Metrics，Custom Metrics 和 External Metrics 三類。
| 監測接口标準 | APIService 位址 | 接口使用場景描述 |
| Resource Metrics | metrics.k8s.io http://metrics.k8s.io/ | 主要用于 Kubernetes 内置的消費鍊路，通常由 Metrcis-Server 提供。 |
| Custom Metrics | custom.metrics.k8s.io http://custom.metrics.k8s.io/ | 主要的實作為 Prometheus，提供資源監測和自定義監測。 |
| External Metrics | external.metrics.k8s.io http://external.metrics.k8s.io/ | 主要的實作為雲廠商的 Provider，提供雲資源的監測名額。 |
Resource Metrics 類對應接口 metrics.k8s.io，主要的實作就是 metrics-server，它提供資源的監測，比較常見的是節點級别、pod 級别、namespace 級别。這些名額可以通過 kubectl top 直接通路擷取，或者通過 K8s controller 擷取，例如 HPA(Horizontal Pod Autoscaler)。系統架構以及通路鍊路如下：
Custom Metrics 對應的 API 是 custom.metrics.k8s.io，主要的實作是 Prometheus。它提供的是資源監測和自定義監測，資源監測和上面的資源監測其實是有覆寫關系的，而這個自定義監測指的是：比如應用上面想暴露一個類似像線上人數，或者說調用後面的這個資料庫的 MySQL 的慢查詢。這些其實都是可以在應用層做自己的定義的，然後并通過标準的 Prometheus 的 client，暴露出相應的 metrics，然後再被 Prometheus 進行采集。
而這類的接口一旦采集上來也是可以通過類似像 custom.metrics.k8s.io 這樣一個接口的标準來進行資料消費的，也就是說現在如果以這種方式接入的 Prometheus，那你就可以通過 custom.metrics.k8s.io 這個接口來進行 HPA，進行資料消費。系統架構以及通路鍊路如下：
External Metrics 。因為我們知道 K8s 現在已經成為了雲原生接口的一個實作标準。很多時候在雲上打交道的是雲服務，比如說在一個應用裡面用到了前面的是消息隊列，後面的是 RBS 資料庫。那有時在進行資料消費的時候，同時需要去消費一些雲産品的監測名額，類似像消息隊列中消息的數目，或者是接入層 SLB 的 connection 數目，SLB 上層的 200 個請求數目等等，這些監測名額。
那怎麼去消費呢？也是在 K8s 裡面實作了一個标準，就是 external.metrics.k8s.io。主要的實作廠商就是各個雲廠商的 provider，通過這個 provider 可以通過雲資源的監測名額。在阿裡雲上面也實作了阿裡巴巴 cloud metrics adapter 用來提供這個标準的 external.metrics.k8s.io 的一個實作。
日志（Logging）
概要來說包括：
- 主機核心的日志。主機核心日志可以協助開發者診斷例如：網絡棧異常，驅動異常，檔案系統異常，影響節點（核心）穩定的異常。
- Runtime 日志。最常見的運作時是 Docker，可以通過 Docker 的日志排查例如删除 Pod Hang 等問題。
- K8s 元件日志。APIServer 日志可以用來審計，Scheduler 日志可以診斷排程，etcd 日志可以檢視存儲狀态，Ingress 日志可以分析接入層流量。
- 應用日志。可以通過應用日志分析檢視業務層的狀态，診斷異常。
日志的采集方式分為被動采集和主動推送兩種，在 K8s 中，被動采集一般分為 Sidecar 和 DaemonSet 兩種方式，主動推送有 DockerEngine 推送和業務直寫兩種方式。
- DockerEngine 本身具有 LogDriver 功能，可通過配置不同的 LogDriver 将容器的 stdout 通過 DockerEngine 寫入到遠端存儲，以此達到日志采集的目的。這種方式的可定制化、靈活性、資源隔離性都很低，一般不建議在生産環境中使用；
- 業務直寫是在應用中內建日志采集的 SDK，通過 SDK 直接将日志發送到服務端。這種方式省去了落盤采集的邏輯，也不需要額外部署 Agent，對于系統的資源消耗最低，但由于業務和日志 SDK 強綁定，整體靈活性很低，一般隻有日志量極大的場景中使用；
- DaemonSet 方式在每個 node 節點上隻運作一個日志 agent，采集這個節點上所有的日志。DaemonSet 相對資源占用要小很多，但擴充性、租戶隔離性受限，比較适用于功能單一或業務不是很多的叢集；
- Sidecar 方式為每個 POD 單獨部署日志 agent，這個 agent 隻負責一個業務應用的日志采集。Sidecar 相對資源占用較多，但靈活性以及多租戶隔離性較強，建議大型的 K8s 叢集或作為 PaaS 平台為多個業務方服務的叢集使用該方式。
挂載主控端采集、标準輸入輸出采集、Sidecar 采集。
總結下來：
- DockerEngine 直寫一般不推薦；
- 業務直寫推薦在日志量極大的場景中使用；
- DaemonSet 一般在中小型叢集中使用；
- Sidecar 推薦在超大型的叢集中使用。
事件（Event）
事件監測是适用于 Kubernetes 場景的一種監測方式。事件包含了發生的時間、元件、等級（Normal、Warning）、類型、詳細資訊，通過事件我們能夠知道應用的部署、排程、運作、停止等整個生命周期，也能通過事件去了解系統中正在發生的一些異常。
K8s 中的一個設計理念，就是基于狀态機的一個狀态轉換。從正常的狀态轉換成另一個正常的狀态的時候，會發生一個 Normal 的事件，而從一個正常狀态轉換成一個異常狀态的時候，會發生一個 Warning 的事件。通常情況下，Warning 的事件是我們比較關心的。事件監測就是把 Normal 的事件或者是 Warning 事件彙聚到資料中心，然後通過資料中心的分析以及報警，把相應的一些異常通過像釘釘、短信、郵件等方式進行暴露，實作與其他監測的補充與完善。
Kubernetes中的事件是存儲在 etcd 中，預設情況下隻儲存 1 個小時，無法實作較長周期範圍的分析。将事件進行長期存儲以及定制化開發後，可以實作更加豐富多樣的分析與告警：
- 對系統中的異常事件做實時告警，例如 Failed、Evicted、FailedMount、FailedScheduling 等。
- 通常問題排查可能要去查找曆史資料，是以需要去查詢更長時間範圍的事件（幾天甚至幾個月）。
- 事件支援歸類統計，例如能夠計算事件發生的趨勢以及與上一時間段（昨天/上周/釋出前）對比，以便基于統計名額進行判斷和決策。
- 支援不同的人員按照各種次元去做過濾、篩選。
- 支援自定義的訂閱這些事件去做自定義的監測，以便和公司内部的部署運維平台內建。
NPD（Node Problem Detector）架構
Kubernetes 叢集及其運作容器的穩定性，強依賴于節點的穩定性。Kubernetes 中的相關元件隻關注容器管理相關的問題，對于硬體、作業系統、容器運作時、依賴系統（網絡、存儲等）并不會提供更多的檢測能力。NPD（Node Problem Detector）針對節點的穩定性提供了診斷檢查架構，在預設檢查政策的基礎上，可以靈活擴充檢查政策，可以将節點的異常轉換為 Node 的事件，推送到 APIServer 中，由同一的 APIServer 進行事件管理。
NPD 支援多種異常檢查，例如：
- 基礎服務問題：NTP 服務未啟動
- 硬體問題：CPU、記憶體、磁盤、網卡損壞
- Kernel 問題：Kernel hang，檔案系統損壞
- 容器運作時問題：Docker hang，Docker 無法啟動
- 資源問題：OOM 等
綜上，本章節總結了常見的 Kubernetes 可觀測性方案。在生産環境，我們通常需要綜合使用各種方案，形成立體多元度、互相補充的可觀測性體系；可觀測性方案部署後，需要基于上述方案的輸出結果快速診斷異常和錯誤，有效降低誤報率，并有能力儲存、回查以及分析曆史資料；進一步延伸，資料可以提供給機器學習以及 AI 架構，實作彈性預測、異常診斷分析、智能運維 AIOps 等進階應用場景。
這需要可觀測性最佳實踐作為基礎，包括如何設計、插件化部署、配置、更新上述各種可觀測性方案架構，如何基于輸出結果快速準确診斷分析跟因等等。阿裡雲容器服務 ACK 以及相關雲産品（監測服務 ARMS、日志服務 SLS 等），将雲廠商的最佳實踐通過産品化能力實作、賦能使用者，提供了完善全面的解決方案，可以讓使用者快速部署、配置、更新、掌握阿裡雲的可觀測性方案，顯著提升了企業上雲和雲原生化的效率和穩定性、降低技術門檻和綜合成本。
下面将以 ACK 最新的産品形态 ACK Pro 為例，結合相關雲産品，介紹 ACK 的可觀測性解決方案和最佳實踐。
ACK可觀測性能力
名額（Metrics）可觀測性方案
對于名額類可觀測性，ACK 可以支援開源 Prometheus 監測和阿裡雲 Prometheus 監測（阿裡雲 Prometheus 監測是 ARMS 産品子産品）兩種可觀測性方案。
開源 Prometheus 監測，以 helm 包形式提供、适配阿裡雲環境、內建了釘釘告警、存儲等功能；部署入口在控制台的應用目錄中 ack-prometheus-operator，使用者配置後可以在 ACK 控制台一鍵部署。使用者隻需要在阿裡雲 ACK 控制台配置 helm 包參數，就可以定制化部署。
阿裡雲 Prometheus監測，是 ARMS 産品子産品。應用實時監測服務 (Application Real-Time Monitoring Service, 簡稱 ARMS) 是一款應用性能管理産品，包含前端監測，應用監測和 Prometheus 監測三大子産品。
在 2021 年的 Gartner 的 APM 魔力象限評測中，阿裡雲應用實時監測服務（ARMS）作為阿裡雲 APM 的核心産品，聯合雲監測以及日志服務共同參與。Gartner 評價阿裡雲 APM：
- 中國影響力最強：阿裡雲是中國最大的雲服務提供商，阿裡雲使用者可以使用雲上監測工具來滿足其可觀測性需求。
- 開源內建：阿裡雲非常重視将開源标準和産品（例如 Prometheus）內建到其平台中。
- 成本優勢：與在阿裡雲上使用第三方 APM 産品相比，阿裡雲 APM 産品具有更高的成本效益。
下圖概要對比了開源 Prometheus 和阿裡雲 Prometheus 的子產品劃分和資料鍊路。
ACK 支援 CoreDNS、叢集節點、叢集概況等 K8s 可觀測性能力；除此之外，ACK Pro 還支援托管的管控元件 Kube API Server、Kube Scheduler 和 Etcd 的可觀測性能力，并持續疊代。使用者可以通過在阿裡雲 Prometheus 中豐富的監測大盤，結合告警能力，快速發現 K8s 叢集的系統問題以及潛在風險，及時采取相應措施以保障叢集穩定性。監測大盤內建了 ACK 最佳實踐的經驗，可以幫助使用者從多元度分析分析、定位問題。下面介紹如何基于最佳實踐設計可觀測性大盤，并列舉使用監測大盤定位問題的具體案例，幫助了解如何使用可觀測性能力。
首先來看 ACK Pro 的可觀測性能力。監測大盤入口如下：
APIServer 是 K8s 核心元件之一，是 K8s 元件進行互動的樞紐，ACK Pro APIServer 的監測大盤設計考慮到使用者可以選擇需要監測的 APIServer Pod 來分析單一名額、聚合名額以及請求來源等，同時可以下鑽到某一種或者多種 API 資源關聯觀測 APIServer 的名額，這樣的優勢是既可以全局觀測全部 APIServer Pod 的全局視圖，又可以下鑽觀測到具體 APIServer Pod 以及具體 API 資源的監測，監測全部和局部觀測能力，對于定位問題非常有效。是以根據 ACK 的最佳實踐，實作上包含了如下 5 個子產品：
- 提供 APIServer Pod、API 資源（Pods，Nodes，ConfigMaps 等）、分位數（0.99，0.9，0.5）、統計時間間隔的篩選框，使用者通過控制篩選框，可以關聯控制監測大盤實作關聯
- 凸顯關鍵名額以便識别系統關鍵狀态
- 展示 APIServer RT、QPS 等單項名額的監測大盤，實作單一次元名額的觀測
- 展示 APIServer RT、QPS 等聚合名額的監測大盤，實作多元度名額的觀測
- 展示對 APIServer 通路的用戶端來源分析，實作通路源的分析
下面概要介紹子產品的實作。
關鍵名額
顯示了核心的名額，包括 APIServer 總 QPS、讀請求成功率、寫請求成功率、Read Inflight Request、Mutating Inflight Request 以及機關時間丢棄請求數量 Dropped Requests Rate。
這些名額可以概要展示系統狀态是否正常，例如如果 Dropped Requests Rate 不為 NA，說明 APIServer 因為處理請求的能力不能滿足請求出現丢棄請求，需要立即定位處理。
Cluster-Level Summary
包括讀非 LIST 讀請求 RT、LIST 讀請求 RT、寫請求 RT、讀請求 Inflight Request、修改請求 Inflight Request 以及機關時間丢棄請求數量，該部分大盤的實作結合了 ACK 最佳實踐經驗。
對于響應時間的可觀測性，可以直覺的觀察到不同時間點以及區間内，針對不同資源、不同操作、不同範圍的響應時間。可以選擇不同的分位數，來篩選。有兩個比較重要的考察點：
- 曲線是否連續
- RT 時間
先來解釋曲線的連續性。通過曲線的連續性，可以很直覺的看出請求是持續的請求，還是單一的請求。
下圖表示在采樣周期内，APIServer 收到 PUT leases 的請求，每個采樣期内 P90 RT 是 45ms。
因為圖中曲線是連續，說明該請求在全部采樣周期都存在，是以是持續的請求。
下圖表示在采樣周期内，APIServer 收到 LIST daemonsets 的請求，有樣值的采樣周期内 P90 RT 是 45ms。
因為圖中隻有一次，說明該請求隻是在一次采樣周期存在。該場景來自于使用者執行 kubectl get ds --all-namespaces 産生的請求記錄。
再來解釋曲線展現的 RT。
使用者執行指令建立 1MB 的 configmap，請求連接配接到公網 SLBkubectl create configmap cm1MB --from-file=cm1MB=./configmap.file
APIServer 記錄的日志中，該次請求 POST configmaps RT 為 9.740961791s，該值可以落入 apiserver_request_duration_seconds_bucket 的(8, 9]區間，是以會在 apiserver_request_duration_seconds_bucket 的 le=9 對應的 bucket 中增加一個樣點，可觀測性展示中按照 90 分位數，計算得到 9.9s 并圖形化展示。這就是日志中記錄的請求真實RT與可觀測性展示中的展示 RT 的關聯關系。
是以監測大盤既可以與日志可觀測功能聯合使用，又可以直覺概要的以全局視圖展示日志中的資訊，最佳實踐建議結合監測大盤和日志可觀測性做綜合分析。
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 version
Trace[1528486772]: [9.660554709s] [13.089126ms] Conversion done
Trace[1528486772]: [9.660561026s] [6.317µs] About to store object in database
Trace[1528486772]: [9.687076754s] [26.515728ms] Object stored in database
Trace[1528486772]: [9.740403082s] [53.326328ms] END
I0215 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與請求的具體内容以及叢集規模有直接的關聯。
在上述建立 configmap 的例子中，同樣是建立 1MB 的 configmap，公網鍊路受網路帶寬和時延影響，達到了 9s；而在内網鍊路的測試中，隻需要 145ms，網絡因素的影響是顯著的。
是以 RT 與請求操作的資源對象、位元組尺寸、網絡等有關聯關系，網絡越慢，位元組尺寸越大，RT 越大。
對于大規模 K8s 叢集，全量 LIST（例如 pods，nodes 等資源）的資料量有時候會很大，導緻傳輸資料量增加，也會導緻 RT 增加。是以對于 RT 名額，沒有絕對的健康門檻值，一定需要結合具體的請求操作、叢集規模、網絡帶寬來綜合評定，如果不影響業務就可以接受。
對于小規模 K8s 叢集，平均 RT 45ms 到 100ms 是可以接受的；對于節點規模上 100 的叢集，平均 RT 100ms 到 200ms 是可以接受的。
但是如果 RT 持續達到秒級，甚至 RT 達到 60s 導緻請求逾時，多數情況下出現了異常，需要進一步定位處理是否符合預期。
這兩個名額通過 APIServer /metrics 對外透出，可以執行如下指令檢視 inflight requests，是衡量 APIServer 處理并發請求能力的名額。如果請求并發請求過多達到 APIServer 參數 max-requests-inflight和 max-mutating-requests-inflight 指定的門檻值，就會觸發 APIServer 限流。通常這是異常情況，需要快速定位并處理。
QPS & Latency
該部分可以直覺顯示請求 QPS 以及 RT 按照 Verb、API 資源進行分類的情況，以便進行聚合分析。還可以展示讀、寫請求的錯誤碼分類，可以直覺發現不同時間點下請求傳回的錯誤碼類型。
Client Summary
該部分可以直覺顯示請求的用戶端以及操作和資源。
QPS By Client 可以按用戶端次元，統計不同用戶端的QPS值。
QPS By Verb + Resource + Client 可以按用戶端、Verb、Resource 次元，統計機關時間（1s）内的請求分布情況。
基于 ARMS Prometheus，除了 APIServer 大盤，ACK Pro 還提供了 Etcd 和 Kube Scheduler 的監測大盤；ACK 和 ACK Pro 還提供了 CoreDNS、K8s 叢集、K8s 節點、Ingress 等大盤，這裡不再一一介紹，使用者可以檢視 ARMS 的大盤。這些大盤結合了 ACK 和 ARMS 的在生産環境的最佳實踐，可以幫助使用者以最短路徑觀測系統、發現問題根源、提高運維效率。
日志（Logging）可觀測性方案
SLS 阿裡雲日志服務是阿裡雲标準的日志方案，對接各種類型的日志存儲。
對于托管側元件的日志，ACK 支援托管叢集控制平面元件（kube-apiserver/kube-controller-manager/kube-scheduler）日志透出，将日志從 ACK 控制層采集到到使用者 SLS 日志服務的 Log Project 中。
對于使用者側日志，使用者可以使用阿裡雲的 logtail、log-pilot 技術方案将需要的容器、系統、節點日志收集到 SLS 的 logstore，随後就可以在 SLS 中友善的檢視日志。
事件（Event）可觀測性方案 + NPD 可觀測性方案
Kubernetes 的架構設計基于狀态機，不同的狀态之間進行轉換則會生成相應的事件，正常的狀态之間轉換會生成 Normal 等級的事件，正常狀态與異常狀态之間的轉換會生成 Warning 等級的事件。
ACK 提供開箱即用的容器場景事件監測方案，通過 ACK 維護的 NPD（node-problem-detector）以及包含在 NPD 中的 kube-eventer 提供容器事件監測能力。
- NPD（node-problem-detector）是 Kubernetes 節點診斷的工具，可以将節點的異常，例如 Docker Engine Hang、Linux Kernel Hang、網絡出網異常、檔案描述符異常轉換為 Node 的事件，結合 kube-eventer 可以實作節點事件告警的閉環。
- kube-eventer 是 ACK 維護的開源 Kubernetes 事件離線工具，可以将叢集的事件離線到釘釘、SLS、EventBridge 等系統，并提供不同等級的過濾條件，實作事件的實時采集、定向告警、異步歸檔。
NPD 根據配置與第三方插件檢測節點的問題或故障，生成相應的叢集事件。而Kubernetes叢集自身也會因為叢集狀态的切換産生各種事件。例如 Pod 驅逐，鏡像拉取失敗等異常情況。日志服務 SLS（Log Service）的 Kubernetes 事件中心實時彙聚 Kubernetes 中的所有事件并提供存儲、查詢、分析、可視化、告警等能力。
ACK可觀測性展望
ACK 以及相關雲産品對 Kubernetes 叢集已經實作了全面的觀測能力，包括名額、日志、鍊路追蹤、事件等。後面發展的方向包括：
- 挖掘更多應用場景，将應用場景與可觀測性關聯，幫助使用者更好的使用K8s。例如監測一段時間内 Pod 中容器的記憶體/CPU 等資源水位，利用曆史資料分析使用者的Kubernets 容器資源 requests/limits 是否合理，如果不合理給出推薦的容器資源 requests/limits；監測叢集 APIServer RT 過大的請求，自動分析異常請求的原因以及處理建議；
- 關聯多種可觀測性技術方案，例如K8s事件和名額監測，提供更加豐富和更多元度的可觀測性能力。
我們相信 ACK 可觀測性未來的發展方向會越來越廣闊，給客戶帶來越來越出色的技術價值和社會價值！
掃碼檢視更多中間件技術幹貨和案例：