Kubernetes的門戶-Ingress

目前Kubernetes（K8s）已經(jīng)真正地占領(lǐng)了容器編排市場，是默認(rèn)的云無關(guān)計算抽象，越來越多的企業(yè)開始將服務(wù)構(gòu)建在K8s集群上。在K8s中，組件通過Service對外暴露服務(wù)，常見的包括NodePort、LoadBalancer、Ingress等。其中Ingress主要提供HTTP層（7層）路由功能，相比TCP（4層）的負載均衡具備非常多的優(yōu)勢（路由規(guī)則更加靈活、支持金絲雀、藍綠、A/B Test發(fā)布模式、SSL支持、日志、監(jiān)控、支持自定義擴展等），是目前K8s中HTTP/HTTPS服務(wù)的主流暴露方式。

Ingress提供的7層負載均衡具有非常強大的能力，例如：

• 會話保持：讓相同的session ID路由到同一臺后端機器，保證每個用戶的會話只在一臺機器上處理。
• 基于內(nèi)容的轉(zhuǎn)發(fā)：能夠根據(jù)HTTP協(xié)議內(nèi)容進行轉(zhuǎn)發(fā)，例如Host、URL甚至是PostBody等。
• 重寫請求：能夠?qū)τ脩舻恼埱筮M行動態(tài)修改，非常適用于新老系統(tǒng)的兼容性改造。
• 加密：在負載均衡上配置SSL，提供統(tǒng)一的證書管理，每個服務(wù)器無需單獨維護證書。
• 健康檢查增強：可基于業(yè)務(wù)規(guī)則進行健康檢查，而不僅僅是判斷端口連通性，使健康檢查更加精確。
• 日志監(jiān)控：全量7層訪問日志，能夠獲取每個請求的結(jié)果、耗時、請求大小等信息，能夠基于訪問日志監(jiān)控到每個服務(wù)的質(zhì)量。

Ingress日志分析與監(jiān)控

原始的訪問日志記錄了網(wǎng)站的每個訪問請求，每個請求包括用戶地址、Host、URL、狀態(tài)碼、耗時、請求大小等多個維度的信息，基于訪問日志可以統(tǒng)計出不同維度下的訪問qps、成功率、延遲等黃金指標(biāo)，以此實現(xiàn)可以針對各種維度的網(wǎng)站質(zhì)量監(jiān)控。但構(gòu)建一套完整的訪問日志分析系統(tǒng)還是非常困難，這其中包括了很多過程和工作：采集、存儲、分析、可視化、告警等。在實施過程中最為復(fù)雜的點在于：

• 采集問題：如何保證日志采集的可靠性、性能消耗、延時問題；
• 分析：在保證分析靈活性的同時能夠保持快速的分析、查詢速度以及較低的實施成本；
• 自動化：尤其在業(yè)務(wù)規(guī)模比較大的情況下，如何智能的監(jiān)控和分析各個服務(wù)的狀態(tài)是一個迫切需要的功能。

為簡化廣大用戶對于Ingress日志分析與監(jiān)控的門檻，阿里云容器服務(wù)和日志服務(wù)將Ingress日志打通（官方文檔），只需要應(yīng)用一個yaml資源即可完成日志采集、分析、可視化等一整套Ingress日志方案的部署。
這套系統(tǒng)主要包括：

日志實時采集方式：通過Logtail實時采集Ingress產(chǎn)生的輸出日志，并進行格式轉(zhuǎn)換

存儲：SLS提供負載均衡的實時隊列用于日志的存儲，并提供按照TTL的存儲方式，可任意設(shè)置保存的日志天數(shù)。

查詢/分析：基于SLS提供的SQL92語法可實現(xiàn)對Ingress日志各個維度的交互式分析與計算，例如統(tǒng)計UV變化，訪問請求分布，TOP延遲等。

可視化大盤：將常見的監(jiān)控、分析場景需求以圖表的形式固化成大盤，用戶絕大部分時間只需要查看大盤即可了解整個系統(tǒng)的狀態(tài)。

?

再次升級-從1.0到2.0

?

Ingress日志分析與監(jiān)控的方案已經(jīng)發(fā)布2年左右，目前已經(jīng)有上萬的實例使用了該方案。在長期的使用中，我們也發(fā)現(xiàn)了這套方案的一些限制，為了適應(yīng)新時代的DevOps節(jié)奏，我們需要對方案進行整體的升級，提供更加簡單、更快速、更普惠、更智能的Ingress日志監(jiān)控方案。

更簡單：整個方案用戶的使用更加簡單，不需要去關(guān)注SLS的相關(guān)的資源，可以直接以單獨Ingress監(jiān)控APP的方式使用；

更快速：1.0的方案基于原始訪問日志實時計算，在時間跨度較大或日志量較大的情況下查詢速度較慢，使用體驗較差；

更普惠：由于計算依賴原始日志，所以必須將日志長期保存，原始日志的存儲量較高，會產(chǎn)生較高的費用；

更智能：隨著K8s集群中運行服務(wù)數(shù)量的增加，傳統(tǒng)的監(jiān)控方式越來越吃力，依賴靜態(tài)指標(biāo)的告警規(guī)則很難監(jiān)控所有的異常，因此急需更加智能的AIOps能力來解放生產(chǎn)力。

方案架構(gòu)

為了達到高性能、低成本、快速、智能等要求，SLS和阿里云容器服務(wù)團隊聯(lián)合對Ingress日志監(jiān)控方案進行了一次架構(gòu)升級，正式發(fā)布了2.0版本的Ingress日志中心，日志中心包括以下幾個部分：

原始訪問日志存儲：當(dāng)Ingress Controller產(chǎn)生訪問請求后，會實時將請求的訪問日志推送到用戶自身的Logstore中，整個過程的延遲一般在3-5秒即可完成，SLS的Logstore具備高可靠、實時索引、自動擴容等功能，保證日志的可靠性和可擴展性。

預(yù)聚和：由于原始訪問日志量巨大，基于原始日志計算指標(biāo)性能開銷較大，因此SLS專門推出了基于訪問日志的指標(biāo)預(yù)聚和能力，能夠?qū)⑸习偃f甚至上億的訪問日志實時聚合成指標(biāo)類型的時序數(shù)據(jù)，數(shù)據(jù)量會降低1-2個數(shù)量級，后續(xù)的分析與監(jiān)控可直接基于時序數(shù)據(jù)進行，大大提高效率。

智能巡檢：對于預(yù)聚和后的Metrics（指標(biāo)數(shù)據(jù)），SLS提供了機器學(xué)習(xí)的自動巡檢功能，幫助用戶自動去檢測各個Ingress的各個維度的指標(biāo)異常，將異常信息實時展現(xiàn)在時序的圖表中，結(jié)合實時告警能力進行自動的告警配置。此外后續(xù)還會支持異常打標(biāo)，基于用戶反饋的信息進行更加精確的檢測。

通過以上3層數(shù)據(jù)鏈路，實現(xiàn)了從原始訪問日志到預(yù)聚和的指標(biāo)最后再到機器學(xué)習(xí)的異常事件整個數(shù)據(jù)的流轉(zhuǎn)，對于用戶來說，告警和監(jiān)控只需要基于指標(biāo)和智能巡檢的結(jié)果進行，而涉及到具體服務(wù)的問題分析可以再回到原始的訪問日志并基于SLS提供的各種SQL統(tǒng)計方式進行自定義的排查和分析。

?

實時預(yù)聚和

Ingress的訪問日志數(shù)量和用戶訪問成正比，在原始訪問日志上實時計算指標(biāo)的開銷較大，一般不適合長時間的指標(biāo)分析，并且原始日志存儲的成本較高，一般不會將日志存儲較長時間，但我們還是希望指標(biāo)數(shù)據(jù)能夠盡可能長的存儲，這樣可以在分析的時候查看更長時間的數(shù)據(jù)。為此SLS專門為Ingress訪問日志定制了一套全托管指標(biāo)實時預(yù)聚合的功能，能夠?qū)崟r將Ingress的訪問日志聚合成指標(biāo)并存儲在SLS的時序庫中，這樣所有的監(jiān)控數(shù)據(jù)查詢工作都可以基于聚合后的時序數(shù)據(jù)進行，大大提升監(jiān)控數(shù)據(jù)的查詢效率。

?

豐富可視化

Ingress訪問日志分析的一個重要工作是可視化系統(tǒng)的搭建，我們需要針對不同場景創(chuàng)建不同的報表以便滿足各個方面的需求，例如：

整體大盤：包括網(wǎng)站當(dāng)前的訪問UV/PV、整體延遲、成功率等，這個是老板們和SRE需要看的數(shù)據(jù)，需要保證數(shù)據(jù)時效性和刷新的速度

監(jiān)控大盤：能夠把監(jiān)控需要關(guān)注的各種數(shù)據(jù)（延遲（平均、P99/P9999等）、流量、成功率、錯誤碼、TOP類統(tǒng)計）等顯示在一張報表上，并且能夠支持各種維度的過濾，方便定位到問題的實例。

訪問大盤：顯示和用戶相關(guān)的訪問信息，例如PV/UV、訪問的地域分布、設(shè)備分布等，一般情況技術(shù)Leader會關(guān)注，另外部分的運營同學(xué)可能也會需要這部分?jǐn)?shù)據(jù)。

異常大盤：顯示異常巡檢的指標(biāo)信息，能夠把異常的指標(biāo)顯示在報表上，方便查看。

后端流量分析：快速分析后端的流量、QPS、延遲、錯誤率等分布信息，能夠快速查找到“調(diào)皮”的機器。

?

智能巡檢

在時序監(jiān)控場景中，用戶往往先確定監(jiān)控對象，并通過其歷史數(shù)據(jù)，結(jié)合業(yè)務(wù)經(jīng)驗，得到不同組的閾值參數(shù)，通過各種手段（同比、環(huán)比、連續(xù)觸發(fā)幾次等）進行監(jiān)控，往往一個監(jiān)控對象要設(shè)計4～5條監(jiān)控規(guī)則，并配置不同的參數(shù)。還有更大的問題，各個參數(shù)閾值無法快速的復(fù)用到不同的類似觀測對象中，當(dāng)觀測對象的規(guī)模達到數(shù)千，甚至上萬后，傳統(tǒng)的配置效率底下，無法滿足在大規(guī)則時序指標(biāo)數(shù)據(jù)下的監(jiān)控需求。流式算法具有天然的優(yōu)勢可以解決上面的問題，用戶只需要發(fā)起一個機器學(xué)習(xí)服務(wù)，模型自動拉取數(shù)據(jù)，實時訓(xùn)練，實時反饋（通俗地說：“來一個點，學(xué)習(xí)一個點，檢測一個點”），在極大的降低成本的同時，實現(xiàn)對每一條線的單獨建模，單獨分析，單獨模型參數(shù)保存，實現(xiàn)時序異常檢測的“千線千面”。

智能HPA

?

基于業(yè)務(wù)訪問量的HPA

HPA（Horizontal Pod Autoscaler）是Kubernetes提供的一個標(biāo)準(zhǔn)組件，用于POD的橫向自動擴縮容，例如：當(dāng)Pod CPU、內(nèi)存等指標(biāo)上升到一定程度時會自動擴容，當(dāng)這些指標(biāo)下去后會自動縮容。這樣能夠保證在用戶體驗不變的情況下集群整體的資源使用都能處于一個較低的位置。


默認(rèn)的HPA只能針對集群的一些標(biāo)準(zhǔn)指標(biāo)（CPU、內(nèi)存、網(wǎng)絡(luò)等）進行擴容，這種擴容方式相對靜態(tài)，而且反應(yīng)不出業(yè)務(wù)的情況。因此我們對HPA進行了一些擴展，支持按照Ingress訪問QPS進行擴容。即可以設(shè)置某個Service下的Pod限定能夠處理的QPS，當(dāng)QPS上升到一定高度時會自動擴容一些Pod/節(jié)點，當(dāng)QPS下降時會自動縮容一些Pod/節(jié)點。

?

基于業(yè)務(wù)量預(yù)測的HPA

HPA的預(yù)測原理是判斷某些指標(biāo)的值進行擴縮容，而指標(biāo)的值相對來說都有10-30秒左右的延遲，并且還有幾次的double check時間，因此從壓力上升到擴容的時間基本上在2-3分鐘左右，如果Pod啟動還需要預(yù)熱的話可能要更久，這段期間用戶的訪問請求很可能會出現(xiàn)高延遲或錯誤的情況。


因此最好的方式是我們能夠提前知道未來幾分鐘的訪問請求量，當(dāng)我們發(fā)現(xiàn)未來訪問請求會很高的時候，提前把Pod擴容出來并進行預(yù)熱，這樣可以在請求真正提升時Pod的資源已經(jīng)提前分配好。為此我們結(jié)合SLS與阿里云達摩院聯(lián)合研發(fā)的多模型預(yù)測算法，實時預(yù)測Ingress上每個服務(wù)的訪問請求，并把這些預(yù)測的指標(biāo)提供給HPA做動態(tài)擴容，能夠在請求量即將超過閾值的時候提前擴出Pod/節(jié)點，保證用戶訪問一直流暢。

?

總結(jié)

Ingress訪問日志中心提供了訪問日志分析、秒級監(jiān)控指標(biāo)分析、實時告警等功能，并提供基于AIOps的自動異常巡檢功能。基于這些功能我們可以快速構(gòu)建出一套企業(yè)級的監(jiān)控系統(tǒng)，能夠以非常小的工作量實現(xiàn)公司所有訪問入口的統(tǒng)一監(jiān)控。

?

?

原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的2020-10-28的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。