電子發(fā)燒友App
隨著越來越多的公司擁抱云原生，從原先的單體應(yīng)用演變?yōu)槲⒎?wù)，應(yīng)用的部署方式也從虛機(jī)變?yōu)槿萜骰萜骶幣沤M件k8s也成為大多數(shù)公司的標(biāo)配。然而在容器化以后，我們發(fā)現(xiàn)應(yīng)用的性能比原先在虛擬機(jī)上表現(xiàn)更差，這是為什么呢？
壓測(cè)結(jié)果
容器化之前的表現(xiàn)
應(yīng)用部署在虛擬機(jī)下，我們使用wrk工具進(jìn)行壓測(cè)，壓測(cè)結(jié)果如下：
壓測(cè)結(jié)果
從壓測(cè)結(jié)果看，平均RT為1.68ms，qps為716/s，我們?cè)賮砜聪聶C(jī)器的資源使用情況，cpu 基本已經(jīng)被打滿。
cpu 基本已經(jīng)被打滿
容器化后的表現(xiàn)
使用wrk工具進(jìn)行壓測(cè)，結(jié)果如下：
壓測(cè)結(jié)果
從壓測(cè)結(jié)果看，平均RT為2.11ms，qps為554/s，我們?cè)賮砜聪聶C(jī)器的資源使用情況，cpu基本已經(jīng)被打滿。
cpu基本已經(jīng)被打滿
性能對(duì)比結(jié)果
| 性能對(duì)比 | 虛擬機(jī) | 容器 |
|---|---|---|
| RT | 1.68ms | 2.11ms |
| QPS | 716/s | 554/s |
「總體性能下降：RT（25%）、QPS（29%）」
原因分析
架構(gòu)差異
由于應(yīng)用在容器化后整體架構(gòu)的不同、訪問路徑的不同，將可能導(dǎo)致應(yīng)用容器化后性能的下降，于是我們先來分析下兩者架構(gòu)的區(qū)別。我們使用k8s作為容器編排基礎(chǔ)設(shè)施，網(wǎng)絡(luò)插件使用calico的ipip模式，整體架構(gòu)如下所示。
架構(gòu)差異
這里需要說明，雖然使用calico的ipip模式，由于pod的訪問為service的nodePort模式，所以不會(huì)走tunl0網(wǎng)卡，而是從eth0經(jīng)過iptables后，通過路由到calico的calixxx接口，最后到pod。
性能分析
在上面壓測(cè)結(jié)果的圖中，我們?nèi)萜骰?，cpu的軟中斷si使用率明顯高于原先虛擬機(jī)的si使用率，所以我們使用perf繼續(xù)分析下熱點(diǎn)函數(shù)。
性能分析
為了進(jìn)一步驗(yàn)證是否是軟中斷的影響，我們使用perf進(jìn)一步統(tǒng)計(jì)軟中斷的次數(shù)。
軟中斷的次數(shù)
?
「我們發(fā)現(xiàn)容器化后比原先軟中斷多了14%，到這里，我們能基本得出結(jié)論，應(yīng)用容器化以后，需要更多的軟中斷的網(wǎng)絡(luò)通信導(dǎo)致了性能的下降?！?/strong>
?
軟中斷原因
由于容器化后，容器和宿主機(jī)在不同的網(wǎng)絡(luò)namespace,數(shù)據(jù)需要在容器的namespace和host namespace之間相互通信,使得不同namespace的兩個(gè)虛擬設(shè)備相互通信的一對(duì)設(shè)備為veth pair,可以使用ip link命令創(chuàng)建，對(duì)應(yīng)上面架構(gòu)圖中紅色框內(nèi)的兩個(gè)設(shè)備，也就是calico創(chuàng)建的calixxx和容器內(nèi)的eth0。我們?cè)賮砜聪聉eth設(shè)備發(fā)送數(shù)據(jù)的過程
static?netdev_tx_t?veth_xmit(struct?sk_buff?*skb,?struct?net_device?*dev) { ... ????if?(likely(veth_forward_skb(rcv,?skb,?rq,?rcv_xdp) ... } static?int?veth_forward_skb(struct?net_device?*dev,?struct?sk_buff?*skb, ???????struct?veth_rq?*rq,?bool?xdp) { ?return?__dev_forward_skb(dev,?skb)??:?xdp?? ??veth_xdp_rx(rq,?skb)?: ??netif_rx(skb);//中斷處理 } /*?Called?with?irq?disabled?*/ static?inline?void?____napi_schedule(struct?softnet_data?*sd, ?????????struct?napi_struct?*napi) { ?list_add_tail(&napi->poll_list,?&sd->poll_list); ??//發(fā)起軟中斷 ?__raise_softirq_irqoff(NET_RX_SOFTIRQ); }
通過虛擬的 veth 發(fā)送數(shù)據(jù)和真實(shí)的物理接口沒有區(qū)別，都需要完整的走一遍內(nèi)核協(xié)議棧，從代碼分析調(diào)用鏈路為 veth_xmit -> veth_forward_skb -> netif_rx -> __raise_softirq_irqoff，「veth的數(shù)據(jù)發(fā)送接收最后會(huì)使用軟中斷的方式，這也剛好解釋了容器化以后為什么會(huì)有更多的軟中斷，也找到了性能下降的原因?！?/strong>
優(yōu)化策略
原來我們使用calico的ipip模式，它是一種overlay的網(wǎng)絡(luò)方案，容器和宿主機(jī)之間通過veth pair進(jìn)行通信存在性能損耗，雖然calico可以通過BGP，在三層通過路由的方式實(shí)現(xiàn)underlay的網(wǎng)絡(luò)通信，但還是不能避免veth pari帶來的性能損耗，針對(duì)性能敏感的應(yīng)用，那么有沒有其他underly的網(wǎng)絡(luò)方案來保障網(wǎng)絡(luò)性能呢？那就是macvlan/ipvlan模式，我們以ipvlan為例稍微展開講講。
ipvlan L2 模式
IPvlan和傳統(tǒng)Linux網(wǎng)橋隔離的技術(shù)方案有些區(qū)別，它直接使用linux以太網(wǎng)的接口或子接口相關(guān)聯(lián)，這樣使得整個(gè)發(fā)送路徑變短，并且沒有軟中斷的影響，從而性能更優(yōu)。如下圖所示：
ipvlan L2 模式
上圖是ipvlan L2模式的通信模型，可以看出container直接使用host eth0發(fā)送數(shù)據(jù)，可以有效減小發(fā)送路徑，提升發(fā)送性能。
ipvlan L3 模式
ipvlan L3模式，宿主機(jī)充當(dāng)路由器的角色，實(shí)現(xiàn)容器跨網(wǎng)段的訪問，如下圖所示：
ipvlan L3 模式
Cilium
除了使用macvlan/ipvlan提升網(wǎng)絡(luò)性能外，我們還可以使用Cilium來提升性能，Cilium為云原生提供了網(wǎng)絡(luò)、可觀測(cè)性、網(wǎng)絡(luò)安全等解決方案，同時(shí)它是一個(gè)高性能的網(wǎng)絡(luò)CNI插件，高性能的原因是優(yōu)化了數(shù)據(jù)發(fā)送的路徑，減少了iptables開銷，如下圖所示：
Cilium
雖然calico也支持ebpf，但是通過benchmark的對(duì)比，Cilium性能更好，高性能名副其實(shí)，接下來我們來看看官網(wǎng)公布的一些benchmark的數(shù)據(jù)，我們只取其中一部分來分析，如下圖:
benchmark數(shù)據(jù)
benchmark
無論從 QPS 和 CPU 使用率上 Cilium 都擁有更強(qiáng)的性能。
總結(jié)
容器化帶來了敏捷、效率、資源利用率的提升、環(huán)境的一致性等等優(yōu)點(diǎn)的同時(shí)，也使得整體的系統(tǒng)復(fù)雜度提升一個(gè)等級(jí)，特別是網(wǎng)絡(luò)問題，容器化使得整個(gè)數(shù)據(jù)發(fā)送路徑變長，排查難度增大。不過現(xiàn)在很多網(wǎng)絡(luò)插件也提供了很多可觀測(cè)性的能力，幫助我們定位問題。
我們還是需要從實(shí)際業(yè)務(wù)場(chǎng)景出發(fā)，針對(duì)容器化后性能、安全、問題排查難度增大等問題，通過優(yōu)化架構(gòu)，增強(qiáng)基礎(chǔ)設(shè)施建設(shè)才能讓我們?cè)谠圃穆飞显阶咴竭h(yuǎn)。
最后，感謝大家觀看，也希望和我討論云原生過程中遇到的問題。
編輯：黃飛
工商網(wǎng)監(jiān)
評(píng)論