上海阿里云代理商：阿里云 ACK 容器服務生產(chǎn)級可觀測體系建設實踐

　　【聚搜云】（gzjcsc123.com）是上海聚搜信息技術有限公司旗下品牌，坐落于魔都上海，服務于全球、2019年成為阿里云代理商生態(tài)合作伙伴。與阿里云代理商、騰訊云、華為云、西部數(shù)碼、美橙互聯(lián)、AWS亞馬遜云國際站代理商、聚搜云,長期戰(zhàn)略合作的計劃！阿里云國際站代理商專業(yè)的云服務商！

　　作者：馮詩淳（行疾）

　　ACK 可觀測體系介紹

　　全景概要介紹

　　上圖為 ACK 可觀測體系全景圖金字塔，從上至下可分為四層：

　　最上層是最接近用戶業(yè)務的 Business Monitoring，包括用戶業(yè)務的前端的流量、PV、前端性能、JS 響應速度等監(jiān)控。通過容器服務的 IngressDashboard 來監(jiān)測 Ingress 的請求量以及請求的狀態(tài)，用戶可以定制業(yè)務日志，通過容器服務的日志監(jiān)控來實現(xiàn)業(yè)務的自定義監(jiān)控。

　　第二層是 Application Performance Monitoring，包括用戶的應用監(jiān)控，由 ARMS APM 產(chǎn)品提供用戶Java Profiling 和 Tracing等能力，也支持 OpenTracing和 OpenTelemetric 協(xié)議的多語言監(jiān)控方案。

　　第三層是 Container Monitoring，包括容器的集群資源、容器 runtime 層、容器引擎以及容器集群的穩(wěn)定性。使用阿里云 Prometheus 在一張 Global view 的大盤中展示不同集群層面的資源應用，包括性能、水位、云資源，也包括事件體系和日志體系，由事件中心和日志中心覆蓋。

　　最下層是 Infrastructure Monitoring，包括不同的云資源、虛擬化層、操作系統(tǒng)內核層等。容器層和基礎架構層都可以使用基于 eBPF 的無侵入式架構和 K8s 監(jiān)控能力做網(wǎng)絡和調用的 tracing。

　　可觀測體系的每一層都和可觀測的三大支柱 Logging、Tracing、Metrics 有不同程度的映射。

　　場景一：異常診斷場景的可觀測能力實踐

　　用戶的異常診斷案例

　　早上 9 點多業(yè)務流量激增時出現(xiàn)了異常診斷，收到容器報警提示某 Pod Down 影響業(yè)務流量。用戶收到報警后快速反應，對核心業(yè)務的 Pod 進行重啟或擴容，查找問題根因。首先通過 IngressDashboard 從入口流量自上而下分析，發(fā)現(xiàn)對外業(yè)務的訪問成功率下降以及出現(xiàn) 4XX 返回碼的請求，說明這次異常影響了用戶業(yè)務。再從資源以及負載層面分析，可以發(fā)現(xiàn)是由于朝九晚五的流量導致水位負載，在當天早上 9 點時存在與故障對齊的明顯水位飆升，這也是故障所在。

　　系統(tǒng)第一時間報警核心業(yè)務的 Pod 定位，結合業(yè)務日志進行分析，加上 ARMS Java 的 APM 應用監(jiān)控，定位到產(chǎn)生緩存 bug 是由于早上 9 點鐘業(yè)務流量飆升引發(fā)了 bug 最后造成頻繁的數(shù)據(jù)庫讀寫，調用鏈也反映可能出現(xiàn)了數(shù)據(jù)庫的慢查詢,最后通過修復 bug 徹底閉環(huán)整個異常。

　　上述流程是非常典型的貫穿了整個 ACK 可觀測不同能力異常診斷的排查過程，能夠幫助我們更好地理解 ACK 可觀測體系如何相互協(xié)調完成工作。

　　事件體系介紹

　　社區(qū)的 K8s 中包含了非常成熟的事件體系，提供了應用層的事件以及 runtime 層的事件。ACK 可觀測體系在社區(qū)的事件體系之上，從表層到底層都進行了覆蓋和增強，做到了可觀測事件體系的全覆蓋。

　　? 應用異常：對于 K8s 的應用事件提供了用戶灰度發(fā)布以及 HPA 等異常行為的事件監(jiān)控。

　　? 管控操作事件：增加了集群的管控事件、用戶對集群的異常操作以及重要變更，甚至包括成本和預算超標等。

　　? 集群核心組件異常：集群的穩(wěn)定性很大一部分由集群核心組件的健康來保證。對于集群核心組件包括 API server、ETCD、Scheduler、CCM 等都做了異常事件的增強，出現(xiàn)異常事件能夠第一時間進行觸達。此外，還包括用戶側核心組件 addon 事件，比如 Terway、存儲等。

　　? 集群容器引擎層異常：對集群容器引擎層做了增強，包括了 Container Runtime、Kubelet、Cgroup 等異常。

　　? 節(jié)點異常：包括 OS/內核層異常，比如操作系統(tǒng)內核宕機、操作系統(tǒng)配置的異常等，也包括資源層異常比如網(wǎng)絡資源異常、存儲資源異常、其他云資源異常等，為容器服務的運維保障及功能更強的覆蓋提供了支持。

　　ACK 提供了開箱即用的事件中心能力，一鍵開啟事件中心，即可享受復雜的事件體系帶來的強大功能。它提供了預置的試驗中心大盤，能夠對重要的事件進行突出以及統(tǒng)計，也提供了強大、靈活易用的數(shù)據(jù)分析能力，為后面基于事件驅動的 OPS 體系提供了基礎。ACK K8s 集群更多的是對資源的生命周期進行管控，事件中心也提供了以事件為錨點的資源生命周期的管控能力。可以對生命周期中最重要的幾個時間點進行性能的調試優(yōu)化以及對異常 Pod 狀態(tài)快速反應。

　　日志體系介紹

　　Logging 在 K8s 中的第一個使用場景是重要流量，如 Ingress 等。ACK 的日志中心默認提供了 Ingress 等重要場景的大盤，一鍵接入 Ingress 大盤后即可快速查看集群 Ingress 流量，此外還包括 PV、UV、應用的異常狀態(tài)以及統(tǒng)計，快速清晰，易于應用。

　　第二個日志使用場景是審計。集群中的資源經(jīng)常被不同的賬號訪問使用，集群的安全也迫切需要重點關注。我們提供了審計日志大盤，可以快速分析集群資源的訪問和使用軌跡，針對未被授權的訪問可進行報警和預警，為集群提供更安全的環(huán)境。

　　我們提供了云原生無侵入式的日志獲取方式，用戶只需通過簡單的 CRD 或在 Pod 上打 annotation ，即可將日志采集到日志中心，并享受日志中心多維、強大的分析能力。

　　Metric 體系介紹

　　Metrics 體系是做穩(wěn)定性保障和性能調優(yōu)時最常用的體系，水位等關鍵指標都能通過大盤進行直觀展示。產(chǎn)品側預置了 ARMS Prometheus 大盤產(chǎn)品，購買了 ACK K8s 集群后，可以一鍵開啟 Prometheus 大盤。此外，體系內預置了重要場景的 Prometheus 大盤，都是經(jīng)過 K8s 上業(yè)務運維成熟經(jīng)驗的沉淀。Prometheus 方案涉及到不同的服務，不僅包括容器服務側最核心的 K8s 應用、網(wǎng)絡、核心控制面指標，還包括比如 AI 場景、 GPU 指標以及存儲 CSI 等外部存儲場景，以及資源的優(yōu)化或成本的優(yōu)化指標。

　　使用統(tǒng)一的 Prometheus 數(shù)據(jù)鏈路方案，不進能夠支持容器場景的指標，也支持不同云產(chǎn)品的指標以及云產(chǎn)品上不同中間件的指標，可以將所有層級指標都在 Prometheus 數(shù)據(jù)鏈路中進行統(tǒng)一展示。

　　ACK 集群控制面的核心組件 API Server、ETCD 、scheduler 、CCM 等也做了指標加強。Pro 集群不只負責托管這部分核心組件、維護其 SLA，同時也會將透明指標性能暴露給用戶，讓用戶使用安心。

　　? 場景二：穩(wěn)定性保障 - 2022 冬奧會 ACK 助力圓滿平穩(wěn)舉行

　　指標場景是穩(wěn)定性保障的重要支持能力。ACK 非常榮幸地為 2022 年的冬奧會服務，助力冬奧系統(tǒng)圓滿平穩(wěn)運行。

　　ACK 集群中部署了冬奧會多個核心業(yè)務系統(tǒng)，包括冬奧的國際官網(wǎng)、比賽場館、票務系統(tǒng)等，為多個核心系統(tǒng)保駕護航。核心系統(tǒng)多為 Java 系微服務架構，實際使用時有近千個 Deployment 實例。我們通過引入壓測的方式進行容量評估，同時配合為冬奧定制的首屏運維大盤，實時進行應用和集群穩(wěn)定性的保障，保證了冬奧訪系統(tǒng)訪問的順滑。

　　? 場景三：生產(chǎn)級規(guī)模集群穩(wěn)定性保障實踐

　　很多用戶的生產(chǎn)系統(tǒng)規(guī)模很大，到達千級別節(jié)點的集群規(guī)模后，用戶在集群上會進行密集、大規(guī)模的集群資源訪問，極易出現(xiàn)集群穩(wěn)定性問題。

　　比如，用戶在大規(guī)模集群中頻繁密集地訪問集群資源，首先會使 API Server 的請求數(shù)較高，API ServerMutating 請求數(shù)也會處于高位。API Server 負載過高會導致出現(xiàn)丟棄請求的情況，這也是 API Server 的降級特性，會影響用戶業(yè)務的發(fā)布或用戶的變更。

　　再比如，密集的集群資源訪問也可能打滿 API Server 帶寬，API Server 的請求延時 RT 會升至高位，一次 API 的訪問可能需要幾十秒，會嚴重影響用戶的業(yè)務，API Server 的只讀請求數(shù)也會飆升。

　　我們提供了 control plane 核心組件的監(jiān)控大盤，可以快速發(fā)現(xiàn) API Server 的水位和請求響應時間的延時問題，然后根據(jù) API Server 的訪問日志快速定位是哪個應用的什么動作導致 API Server 的水位和資源請求高，最終找到具體應用進行止血，解決問題。

　　Prometheus For ACK Pro

　　阿里云近期推出了 Prometheus for ACK Pro ，它是 Prometheus 的升級服務，能夠在同一張大盤上看到多個數(shù)據(jù)源，包括集群事件日志、基于 eBPF 的無侵入式的應用指標、網(wǎng)絡指標等，提供一致性的體驗。用戶可以通過一張大盤的關聯(lián)分析邏輯，從總覽到細節(jié)，通過多數(shù)據(jù)源、多角度的可觀測能力進行不同角度的排查。

　　Tracing 體系介紹

　　? 應用層 Trace

　　在 ACK 可觀測體系里， Tracing 體系提供了最終定位根因的能力，它分為兩部分:

　　第一部分是應用層的 Tracing，提供 ARMS APM 能力，支持 OpenTracing、OpenTelemetric 協(xié)議，可以支持多種語言的應用。針對 Java 也提供了無侵入式的 APM 能力，只需要在 Pod 上打上 annotation， Java 應用的 Pod 即可享受實時的監(jiān)控數(shù)據(jù)服務，可以查看實時的應用水位、 JVM 的性能指標、應用上下游分布式和微服務的全局調用 top 圖等，也支持 Profiling 以及代碼堆棧級的調用監(jiān)控能力。不同語言可以匯聚成同一張分布式調用追蹤大圖，自上而下地查看一次分布式調用，從而定位、診斷問題。

　　? 集群網(wǎng)絡、調用 Trace

　　第二部分是集群網(wǎng)絡和調用 Trace。

　　近期我們推出了基于 eBPF 網(wǎng)絡層面的 Tracing 能力。通過 eBPF 插樁技術，在內核層面實現(xiàn)了零代碼改動且非常低性能消耗的網(wǎng)絡 Tracing 能力。提供了全局拓撲、快速定位問題調用鏈的網(wǎng)絡拓撲展示以及資源層面展示，也支持在統(tǒng)一的全局架構視圖中集合 Metrics、Tracing 和 Logging 多個角度進行可觀測能力觀察。

　　基于 ACK 可觀測能力建設 AIOps體系

　　事件驅動的 AIOps 體系，用戶可以將事件作為統(tǒng)一的驅動數(shù)據(jù)源進行問題的發(fā)現(xiàn)、觸達以及 AI 智能化運維操作的橋梁。以 ACK 事件中心為核心，構造了統(tǒng)一的事件格式規(guī)范，K8s 的事件會以統(tǒng)一的事件配置格式提供給用戶，最后以事件中心為核心，通過統(tǒng)一的事件處理流提供給用戶。用戶可以通過訂閱事件做事件的智能化運維以及構建其體系。用戶可以通過某個應用的業(yè)務進行業(yè)務事件推送，并對業(yè)務事件進行智能化運維處理，比如智能的擴容或縮容等。

　　此外，我們也提供了 ACK 報警中心，通過統(tǒng)一的報警配置為用戶構建 AIOps 的體系，幫助用戶快速建立運維的訂閱、收發(fā)和問題排障、處理體系。

　　報警中心會為用戶提供統(tǒng)一的配置，幫助用戶快速建立 ACK 場景上異常診斷的異常規(guī)則集。ACK 報警中心提供了開箱即用的報警能力，沉淀了常用的容器場景異常規(guī)則集，開箱即用。其次，可以通過報警消息的細粒度訂閱關系構建 ITOps 體系，不同的異常可以通過報警中心的訂閱配置關系投遞到真正能夠解決異常的人手里。ACK 也沉淀了標準的異常以及對應標準異常處理的 SOP 手冊，發(fā)現(xiàn)報警時，會提示異常類型，以及為用戶提供處理異常的標準 SOP 修復流程。

　　基于 ACK 可觀測能力建設 FinOps 體系

　　越來越多的用戶面臨了上云階段或上云后治理階段的降本增效問題，主要存在以下幾個方面的痛點：

　　? 上云之前——如何上云，難規(guī)劃；

　　? 上云之后——云產(chǎn)品種類豐富，集群資源類型也豐富，計費難；

　　? 高度 SaaS 化的應用部署在同一個集群中進行共享，成本分賬難；

　　? 每年都會有新的業(yè)務生成和下線，集群和資源的使用關系是動態(tài)的，難以進行持續(xù)的優(yōu)化和治理；

　　? 此前一般使用 Excel 表對能力進行管理，在云原生的場景下有豐富的用戶應用和有豐富的賬單資源類型，難以管理。

　　ACK 提供了云原生企業(yè) IT 成本治理方案，通過多維度的成本分攤和估算模型，為集群的資源進行成本估算和分攤。可以通過根因的下鉆和趨勢的預測進行成本洞察，集群上多個應用業(yè)務的成本可以細粒度下鉆，進行成本拆分。對多集群場景上的成本提供了成熟的解決方案覆蓋，以及提供企業(yè)云原生 IT 成本治理的專家服務。

　　此外，我們還推出了內置的應用資源畫像以及應用資源的智能推薦，可以為資源推薦合適的成本以及進行預算控制，最后會根據(jù)不同的場景進行成本優(yōu)化，如大數(shù)據(jù)、AI、游戲等。

　　最后，支持多樣化場景，包括多云和混合云等都能在統(tǒng)一的平面進行展示和管理。

　　客戶案例

　　中華財險作為互聯(lián)網(wǎng)金融的頭部公司，有千核級別的集群規(guī)模，同時管理運維多個 SaaS 化線上業(yè)務，具有高度多租化、對業(yè)務穩(wěn)定性要求高、對業(yè)務資源/成本趨勢敏感度高等行業(yè)特點。

　　中華財險從傳統(tǒng) IT 架構到云原生化的過程中，面臨著容量規(guī)劃難、算清成本難、閑置資源難發(fā)現(xiàn)以及成本優(yōu)化和業(yè)務穩(wěn)定性難以平衡的挑戰(zhàn)。

　　我們通過 ACK 的成本治理解決方案為它進行了壓測、容量規(guī)劃，通過 ACK 成本分析進行業(yè)務分賬的賬單管理和分析，解決了閑置資源的優(yōu)化，為其提供了分配資源的優(yōu)化策略，最后通過容器服務提供了細粒度的容器部署以及彈性策略等優(yōu)化手段。

　　上云前，客戶集群的資源分配閑置率高達 30%+，而通過我們提供的成本治理方案，閑置率降至 10% 以下，為行業(yè)領先水平。