容器視角下的網(wǎng)絡(luò)性能監(jiān)控

1. 企業(yè)上云與應(yīng)用部署方式的變遷

關(guān)于企業(yè)上云，在幾年前大家談?wù)摳嗟氖?OpenStack、資源編排和分配，但近幾年上云的應(yīng)用部署方式發(fā)生了很多變化。首先從谷歌搜索的趨勢(shì)可以發(fā)現(xiàn) Kubernetes 的關(guān)注（熱度）已經(jīng)遠(yuǎn)遠(yuǎn)超過了 OpenStack，同樣在百度搜索趨勢(shì)中 K8s 和 Kubernetes 加起來(lái)是 OpenStack 的兩倍。

2. 容器網(wǎng)絡(luò)的特點(diǎn)

容器環(huán)境下以東西向的通信為主

容器的特點(diǎn)是彈性伸縮，支撐彈性伸縮最主要的兩個(gè)特征分別是分布式和負(fù)載均衡。在這兩個(gè)特征支撐下，容器可以在業(yè)務(wù)壓力過大時(shí)做到彈性伸縮，業(yè)務(wù)以 POD 單位進(jìn)行彈性擴(kuò)充。

從可達(dá)性來(lái)看，任何兩個(gè) POD 間都是可達(dá)的，而且外部也可以通過 Ingress、LB 的方式來(lái)訪問容器集群里面任意的 POD，這帶來(lái)一個(gè)問題：服務(wù)之間的溝通變多了，東西向流量成為容器環(huán)境下的主體流量，而這個(gè)流量，傳統(tǒng)的流量采集方式無(wú)法全部覆蓋。

第一：因?yàn)閭鹘y(tǒng)的流量采集方式是通過物理交換機(jī)的鏡像、分光等方式，在容器網(wǎng)絡(luò)環(huán)境下，容器間的通信可能在 K8s 的 Node 之內(nèi)或者一個(gè) VM 的 Hypervisor 就終結(jié)了，很難去到達(dá)物理的交換機(jī)層面。

第二：即使容器、POD 之間的流量能到達(dá)物理交換機(jī)，隨著容器規(guī)模的擴(kuò)張，要想做到全覆蓋，投入用于流量采集的成本會(huì)急劇增長(zhǎng)。

端到端路徑的復(fù)雜

容器的環(huán)境下有大量的 LB，在提供負(fù)載均衡等復(fù)雜的場(chǎng)景下，SNAT 和 DNAT 會(huì)多次發(fā)生，每一次發(fā)生地址轉(zhuǎn)換就意味著可能會(huì)產(chǎn)生網(wǎng)絡(luò)性能問題。

即使兩個(gè) POD 之間是三層可達(dá)，但是這兩個(gè) POD 的 End to End 的通信路徑上可能會(huì)跨越物理服務(wù)器的機(jī)架，導(dǎo)致可能會(huì)跨越接入交換機(jī)、物理網(wǎng)元；也可能會(huì)跨越兩個(gè)公有云的 AZ、區(qū)域，或者不同的云，甚至是在私有云和公有云之間通信。所以任何兩個(gè) POD 之間通過 service 的訪問都可能會(huì)有解析、DNS 性能以及負(fù)載均衡的問題。

業(yè)務(wù)的拓?fù)涞膭?dòng)態(tài)性強(qiáng)

在傳統(tǒng)網(wǎng)絡(luò)環(huán)境，服務(wù)器和虛擬機(jī)的 IP 地址是很少發(fā)生變化的，對(duì)業(yè)務(wù)的梳理其實(shí)等同于對(duì) IP 地址身份信息的梳理。由于容器用 DNS 解析 IP，可能存在 IP 重疊、IP 對(duì)應(yīng)的資源身份在不斷地變化等，所以在容器環(huán)境，對(duì) IP 身份的識(shí)別非常困難。

容器網(wǎng)絡(luò)規(guī)模超級(jí)大

一般情況下，一個(gè)物理機(jī)上可以運(yùn)行 10 個(gè)虛擬機(jī)，一個(gè)虛擬機(jī)上可以運(yùn)行 10 個(gè) POD，因此容器網(wǎng)絡(luò)環(huán)境的 IP 數(shù)量就有 100 倍的增長(zhǎng)。IP 數(shù)量的巨增，意味著網(wǎng)絡(luò)監(jiān)控的數(shù)據(jù)至少有 100 倍的增長(zhǎng)。在監(jiān)控計(jì)算、存儲(chǔ)資源時(shí)，基本上有多少臺(tái)機(jī)器得到的監(jiān)控?cái)?shù)據(jù)就是多少個(gè)。

但是對(duì)于網(wǎng)絡(luò)監(jiān)控而言，極限情況下數(shù)據(jù)是 N 方的量級(jí)，因?yàn)榫W(wǎng)絡(luò)監(jiān)控的本質(zhì)是一個(gè)端到端的信息。極端情況下，容器里所有的 POD 都會(huì)產(chǎn)生通信，就相當(dāng)于有 N 方的通信需要被監(jiān)控，因此網(wǎng)絡(luò)規(guī)模非常巨大。

以上這些特點(diǎn)都會(huì)導(dǎo)致容器網(wǎng)絡(luò)監(jiān)控的難度上升。

3. 分布式系統(tǒng)的可觀測(cè)性

分布式系統(tǒng)可觀測(cè)性需要去集中解決 3 個(gè)類型的監(jiān)控?cái)?shù)據(jù)，即 Metrics、Tracing 和 Logging。分別代表 Prometheus 監(jiān)控的指標(biāo)數(shù)據(jù)，比如說(shuō) CPU 內(nèi)存、流量大小等等；第二類 Tracing 數(shù)據(jù)，也可以說(shuō)服務(wù)調(diào)用棧的數(shù)據(jù)；第三類是日志數(shù)據(jù)，比如 ELK 里的日志分析。二、三類數(shù)據(jù)關(guān)聯(lián)度會(huì)大一些，是每一個(gè)請(qǐng)求或每一條日志的數(shù)據(jù)。

Metrics 通常是實(shí)現(xiàn)分布式系統(tǒng)可觀測(cè)性的第一步。它是一個(gè)可聚合、可設(shè)置報(bào)警，面向大規(guī)模監(jiān)控?cái)?shù)據(jù)做分析和告警判斷，針對(duì) Metrics 通常會(huì)關(guān)注四個(gè)方面的指標(biāo)量：

時(shí)延

它刻畫的是當(dāng)前的業(yè)務(wù)系統(tǒng)的訪問是否順暢、耗費(fèi)的時(shí)間是否在增加。例如從四層網(wǎng)絡(luò)的角度看，有三次握手、協(xié)議棧響應(yīng)的時(shí)延；從應(yīng)用的角度看，有 HTTP 響應(yīng)、DNS 響應(yīng)的時(shí)延。

流量

系統(tǒng)的吞吐。例如一個(gè)應(yīng)用系統(tǒng)的 BPS、PPS 是多少？新建連接數(shù)、新建連接速率是多少？HTTP 的請(qǐng)求數(shù)是多少等等。

錯(cuò)誤

錯(cuò)誤可能發(fā)生在網(wǎng)絡(luò)層，比如 TCP 建連失敗、重置、重傳等，還可能會(huì)發(fā)生在應(yīng)用層，比如 HTTP 的 400、500 等錯(cuò)誤，或者是 DNS 解析失敗。

負(fù)載

一般來(lái)講是對(duì)計(jì)算和存儲(chǔ)資源的描繪，在虛擬網(wǎng)絡(luò)情況下也可以描述虛擬交換機(jī)的負(fù)載。網(wǎng)絡(luò)層面的負(fù)載主要體現(xiàn)在并發(fā)連接數(shù)、當(dāng)前正在活躍的用戶數(shù)等指標(biāo)。

對(duì)網(wǎng)絡(luò)的指標(biāo)監(jiān)控通常要考慮以上 4 個(gè)方面，這 4 個(gè)方面能夠覆蓋一個(gè)分布式系統(tǒng)所有的角落，最終實(shí)現(xiàn)分布式系統(tǒng)的可觀測(cè)。

4. 解決容器監(jiān)控診斷的難題

以上可見一個(gè)企業(yè)需要實(shí)現(xiàn)全網(wǎng)流量采集的重要性。往簡(jiǎn)單了說(shuō)，在微服務(wù)場(chǎng)景下需要考慮服務(wù)和服務(wù)之間的調(diào)用關(guān)系，相當(dāng)于調(diào)用棧的追蹤。其實(shí)服務(wù)和服務(wù)之間訪問，實(shí)際上就是 POD 和 POD 之間的訪問，意味著在網(wǎng)絡(luò)層面直接能看到它們互訪的流量，因此，通過網(wǎng)絡(luò)流量采集可以直接獲取到服務(wù)的調(diào)用棧。這更加可以說(shuō)明：流量采集可以解決容器網(wǎng)絡(luò)可觀測(cè)性的難題。

那么為什么需要通過流量采集來(lái)解決這個(gè)問題呢？有兩個(gè)方面的原因。

第一個(gè)方面：從應(yīng)用的層面無(wú)法解決問題。從日志或代碼插件很難去感知到網(wǎng)絡(luò)層面的問題。比如某個(gè)訪問消耗了 500 毫秒，在網(wǎng)絡(luò)層面是由于建連導(dǎo)致的時(shí)延問題？還是協(xié)議棧時(shí)延？其實(shí)在應(yīng)用層并不清楚，只知道最終這個(gè)請(qǐng)求消耗了 500 毫秒。

第二個(gè)方面：網(wǎng)絡(luò)層的信息能提供更精確的數(shù)據(jù)。以 Nginx 日志為例，當(dāng)一個(gè)請(qǐng)求所發(fā)送的數(shù)據(jù)已在內(nèi)核緩沖區(qū)里，Nginx 認(rèn)為已經(jīng)實(shí)現(xiàn)了請(qǐng)求的完整回復(fù)，而記錄了一個(gè)時(shí)延。但是如果能從網(wǎng)絡(luò)流量的角度去監(jiān)測(cè)，會(huì)發(fā)現(xiàn)在實(shí)際的環(huán)境中對(duì)于這樣的場(chǎng)景會(huì)有 3~10 倍時(shí)延的誤差。這說(shuō)明，從網(wǎng)絡(luò)層面去分析應(yīng)用的質(zhì)量、性能是必要的。

為了實(shí)現(xiàn)整個(gè)業(yè)務(wù)的監(jiān)控，需要在容器網(wǎng)絡(luò)環(huán)境獲取到的數(shù)據(jù)，包括 Service 之間訪問的追蹤關(guān)系；負(fù)載均衡、Service 前后 IP 的變化關(guān)系；真實(shí)源 IP 與 SNAT 和 DNAT 后的變化關(guān)系。

通過這些數(shù)據(jù)來(lái)刻畫監(jiān)控?cái)?shù)據(jù)的分布，以及監(jiān)控?cái)?shù)據(jù)和網(wǎng)絡(luò)邏輯拓?fù)涞年P(guān)聯(lián)，構(gòu)建網(wǎng)絡(luò)知識(shí)圖譜，實(shí)現(xiàn)各個(gè)緯度的可視化；同時(shí)對(duì)歷史的交互數(shù)據(jù)進(jìn)行回溯分析，在不同的維度（資源組維度、POD 維度、服務(wù)維度）做層層的鉆取來(lái)最終定位業(yè)務(wù)的性能問題，并進(jìn)行證據(jù)的留存。

你可能還喜歡

點(diǎn)擊下方圖片即可閱讀

云原生是一種信仰??

掃碼關(guān)注公眾號(hào)

后臺(tái)回復(fù)?k8s?獲取史上最方便快捷的 Kubernetes 高可用部署工具，只需一條命令，連 ssh 都不需要！