應(yīng)用容器化后為什么性能下降這么多?

軟中斷原因

由于容器化后，容器和宿主機(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è)賮?lái)看下veth設(shè)備發(fā)送數(shù)據(jù)的過(guò)程

      
      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);
}

    

通過(guò)虛擬的 veth 發(fā)送數(shù)據(jù)和真實(shí)的物理接口沒(méi)有區(qū)別，都需要完整的走一遍內(nèi)核協(xié)議棧，從代碼分析調(diào)用鏈路為 veth_xmit -> veth_forward_skb -> netif_rx -> __raise_softirq_irqoff，「veth的數(shù)據(jù)發(fā)送接收最后會(huì)使用軟中斷的方式，這也剛好解釋了容器化以后為什么會(huì)有更多的軟中斷，也找到了性能下降的原因。」

優(yōu)化策略

原來(lái)我們使用calico的ipip模式，它是一種overlay的網(wǎng)絡(luò)方案，容器和宿主機(jī)之間通過(guò)veth pair進(jìn)行通信存在性能損耗，雖然calico可以通過(guò)BGP，在三層通過(guò)路由的方式實(shí)現(xiàn)underlay的網(wǎng)絡(luò)通信，但還是不能避免veth pari帶來(lái)的性能損耗，針對(duì)性能敏感的應(yīng)用，那么有沒(méi)有其他underly的網(wǎng)絡(luò)方案來(lái)保障網(wǎng)絡(luò)性能呢？那就是macvlan/ipvlan模式，我們以ipvlan為例稍微展開(kāi)講講。

ipvlan L2 模式

IPvlan和傳統(tǒng)Linux網(wǎng)橋隔離的技術(shù)方案有些區(qū)別，它直接使用linux以太網(wǎng)的接口或子接口相關(guān)聯(lián)，這樣使得整個(gè)發(fā)送路徑變短，并且沒(méi)有軟中斷的影響，從而性能更優(yōu)。如下圖所示：

上圖是ipvlan L2模式的通信模型，可以看出container直接使用host eth0發(fā)送數(shù)據(jù)，可以有效減小發(fā)送路徑，提升發(fā)送性能。

ipvlan L3 模式

ipvlan L3模式，宿主機(jī)充當(dāng)路由器的角色，實(shí)現(xiàn)容器跨網(wǎng)段的訪問(wèn)，如下圖所示：

Cilium

除了使用macvlan/ipvlan提升網(wǎng)絡(luò)性能外，我們還可以使用Cilium來(lái)提升性能，Cilium為云原生提供了網(wǎng)絡(luò)、可觀測(cè)性、網(wǎng)絡(luò)安全等解決方案，同時(shí)它是一個(gè)高性能的網(wǎng)絡(luò)CNI插件，高性能的原因是優(yōu)化了數(shù)據(jù)發(fā)送的路徑，減少了iptables開(kāi)銷(xiāo)，如下圖所示：

雖然calico也支持ebpf，但是通過(guò)benchmark的對(duì)比，Cilium性能更好，高性能名副其實(shí)，接下來(lái)我們來(lái)看看官網(wǎng)公布的一些benchmark的數(shù)據(jù)，我們只取其中一部分來(lái)分析，如下圖:

無(wú)論從 QPS 和 CPU 使用率上 Cilium 都擁有更強(qiáng)的性能。

總結(jié)

容器化帶來(lái)了敏捷、效率、資源利用率的提升、環(huán)境的一致性等等優(yōu)點(diǎn)的同時(shí)，也使得整體的系統(tǒng)復(fù)雜度提升一個(gè)等級(jí)，特別是網(wǎng)絡(luò)問(wèn)題，容器化使得整個(gè)數(shù)據(jù)發(fā)送路徑變長(zhǎng)，排查難度增大。不過(guò)現(xiàn)在很多網(wǎng)絡(luò)插件也提供了很多可觀測(cè)性的能力，幫助我們定位問(wèn)題。

我們還是需要從實(shí)際業(yè)務(wù)場(chǎng)景出發(fā)，針對(duì)容器化后性能、安全、問(wèn)題排查難度增大等問(wèn)題，通過(guò)優(yōu)化架構(gòu)，增強(qiáng)基礎(chǔ)設(shè)施建設(shè)才能讓我們?cè)谠圃穆飞显阶咴竭h(yuǎn)。

最后，感謝大家觀看，也希望和我討論云原生過(guò)程中遇到的問(wèn)題。