如何專業化監控一個Kubernetes集羣?

做者:佳旭 阿里雲容器服務技術專家前端

引言

Kubernetes 在生產環境應用的普及度愈來愈廣、複雜度愈來愈高,隨之而來的穩定性保障挑戰也愈來愈大。node

如何構建全面深刻的可觀測性架構和體系,是提高系統穩定性的關鍵之因素一。ACK將可觀測性最佳實踐進行沉澱,以阿里雲產品功能的能力對用戶透出,可觀測性工具和服務成爲基礎設施,賦能並幫助用戶使用產品功能,提高用戶 Kubernetes 集羣的穩定性保障和使用體驗。linux

本文會介紹 Kubernetes 可觀測性系統的構建,以及基於阿里云云產品實現 Kubernetes 可觀測系統構建的最佳實踐。數據庫

Kubernetes 系統的可觀測性架構

Kubernetes 系統對於可觀測性方面的挑戰包括:json

• K8s 系統架構的複雜性。系統包括控制面和數據面,各自包含多個相互通訊的組件,控制面和數據間之間經過 kube-apiserver 進行橋接聚合。api

• 動態性。Pod、Service 等資源動態建立以及分配 IP,Pod 重建後也會分配新的資源和 IP,這就須要基於動態服務發現來獲取監測對象。網絡

• 微服務架構。應用按照微服務架構分解成多個組件,每一個組件副本數能夠根據彈性進行自動或者人工控制。架構

針對 Kubernetes 系統可觀測性的挑戰,尤爲在集羣規模快速增加的狀況下,高效可靠的 Kubernetes 系統可觀測性能力,是系統穩定性保障的基石。併發

那麼,如何提高建設生產環境下的 Kubernetes 系統可觀測性能力呢?app

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 場景下的指標,能夠從以下角度分類:

1. 容器基礎資源指標

採集源爲 kubelet 內置的 cAdvisor,提供容器內存、CPU、網絡、文件系統等相關的指標,指標樣例包括:

容器當前內存使用字節數 container_memory_usage_bytes;

容器網絡接收字節數 container_network_receive_bytes_total;

容器網絡發送字節數 container_network_transmit_bytes_total,等等。

2. Kubernetes 節點資源指標

採集源爲 node_exporter,提供節點系統和硬件相關的指標,指標樣例包括:節點總內存 node_memory_MemTotal_bytes,節點文件系統空間 node_filesystem_size_bytes,節點網絡接口 ID node_network_iface_id,等等。基於該類指標,能夠統計節點的 CPU/內存/磁盤使用率等節點級別指標。

3. Kubernetes 資源指標

採集源爲 kube-state-metrics,基於 Kubernetes API 對象生成指標,提供 K8s 集羣資源指標,例如 Node、ConfigMap、Deployment、DaemonSet 等類型。以 Node 類型指標爲例,包括節點 Ready 狀態指標 kube_node_status_condition、節點信息kube_node_info 等等。

4. 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 三類。

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 最佳實踐經驗。

對於響應時間的可觀測性,能夠直觀的觀察到不一樣時間點以及區間內,針對不一樣資源、不一樣操做、不一樣範圍的響應時間。能夠選擇不一樣的分位數,來篩選。有兩個比較重要的考察點:

  1. 曲線是否連續
  2. 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 可觀測性將來的發展方向會愈來愈廣闊,給客戶帶來愈來愈出色的技術價值和社會價值!

相關文章
相關標籤/搜索