<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          多圖匯總梳理VPC與三種K8s網(wǎng)絡模型

          共 6163字,需瀏覽 13分鐘

           ·

          2022-02-13 11:06

          大家好,我是二哥。今天這期是一篇關(guān)于VPC和三種K8s網(wǎng)絡模型的匯總性文章。也是春節(jié)前最后一篇文章,發(fā)完二哥就準備進入過年模式了。提前祝大家虎年虎虎生威,萬事如意。
          本文所有的高清大圖,我都放到github上去了:https://github.com/LanceHBZhang/LanceAndCloudnative。以后也是如此,就不再發(fā)預熱預告了。圖片版權(quán)歸二哥所有,除個人學習外用于其它用途前請先通過公眾號聯(lián)系二哥授權(quán)。
          我們在學習K8s的時候,總是會碰到一個痛點:K8s作為一個完整的商用解決方案,包含了很多零散的基礎知識點。比如單網(wǎng)絡模型方面就涉及到網(wǎng)絡虛擬化、iptables、eBPF、SDN等等。單個知識點我們可能學過、見過甚至用過,但把K8s基本用法擼完一遍下來依舊覺得無法識得廬山真面目。我想一個可能的原因是我們過于關(guān)注在細節(jié)而忽略了它整體的樣子。所以我總是盡量在一張圖中畫出與這個主題相關(guān)的全景全局圖,比如K8s既然被尊稱為云原生時代的“數(shù)據(jù)中心操作系統(tǒng)(DCOS)”,那從網(wǎng)絡拓撲方面來說,它和數(shù)據(jù)中心是如何配合的呢?我將這三種K8s網(wǎng)絡模型和VPC相遇時的樣子分別畫了出來。希望能給你一種鳥瞰的視角,而不是迷失在技術(shù)的細節(jié)叢林里。
          Overlay模型下,網(wǎng)絡包如同害羞的兒童,每次和別人說話都躲在媽媽背后,要媽媽幫他傳話。host-gw模型下,網(wǎng)絡包就像未成年的小伙子,既想走出去直面兇險的江湖,但又離不開媽媽的大力支持。而Underlay模型,網(wǎng)絡包就是大人的模樣了,有什么需求和想法,自己直接和對方談。
          但無論是哪種模式,都離不開一些基礎概念。在二哥看來,理解好了這些基礎,再去看K8s三種網(wǎng)絡模式能起到事半功倍之效。所以本文二哥先花了一些篇幅把這個基礎知識再梳理一遍。重要的話再強調(diào)一下:圖1非?;A,也非常重要。圖2-圖5都與圖1有關(guān)系。
          來吧,進入正題。

          1. 基礎和基石

          1.1 TCP/IP協(xié)議棧和網(wǎng)絡棧

          K8s“扁平網(wǎng)絡”的三種典型實現(xiàn)方式是:Overlay、主機間路由(host-gw)以及Underlay。它們都會在容器內(nèi)虛擬一張網(wǎng)卡,取決于實現(xiàn)方式的不同,這張?zhí)摂M網(wǎng)卡既可能是veth類型的,也可能直接對物理網(wǎng)卡的虛擬。
          我們說Network namespace用來隔離包括網(wǎng)卡(Network Interface)、回環(huán)設備(Loopback Device)、網(wǎng)絡棧、IP地址、端口等等在內(nèi)的網(wǎng)絡資源。它的特點是由可配置的數(shù)據(jù)組成。對于一個進程來說,這些要素,其實就構(gòu)成了它發(fā)起和響應網(wǎng)絡請求的基本環(huán)境。這里所謂“網(wǎng)絡棧(Networking stack)”,包括了:路由表(Routing Table), network filter,iptables 規(guī)則等。
          無論是一個 Linux 容器還是宿主機的進程所能看見的“網(wǎng)絡?!保瑢嶋H上是被隔離在它們各自的 Network namespace 當中的,通信雙方的網(wǎng)卡(如典型的veth pair)也自然被隔離到相應的namespace中。
          另外還有一個棧也會被經(jīng)常提起:TCP/IP協(xié)議棧。我們可以將TCP/IP協(xié)議棧看成是程序的代碼部分,而網(wǎng)絡??闯墒浅绦虻臄?shù)據(jù)部分。很顯然TCP/IP棧應該是被這個OS上所有人共享的,無論是進程還是容器,甚至是基于qemu-kvm的虛擬機都共享著宿主機的協(xié)議棧,但網(wǎng)絡棧卻是各個network namespace獨享的。
          網(wǎng)絡包無論是從容器內(nèi)的網(wǎng)卡流出,還是離開容器后再與其它網(wǎng)絡設備打交道,必然都會經(jīng)過宿主機內(nèi)核TCP/IP協(xié)議棧。容器內(nèi)的網(wǎng)卡屬于容器所在的network namespace,而網(wǎng)絡包離開容器后的下一跳(個)網(wǎng)絡設備同樣也屬于它自己的network namespace。

          1.2 ?虛擬網(wǎng)卡數(shù)據(jù)接收流程

          二哥在文章《看圖寫話:聊聊veth數(shù)據(jù)流》和《高清大圖描繪辛苦的ksoftirqd》中結(jié)合圖1,描述了網(wǎng)路包從veth一端流出到流入另一端過程中所涉及到的數(shù)據(jù)流以及在這個過程中內(nèi)核線程ksoftirqd起到的至關(guān)重要的作用。這張圖也適用普通虛擬網(wǎng)卡。
          圖1有一些關(guān)鍵的地方,我把它們列在這里,希望你看完后可以不自覺地拍下大腿,輕呼一聲:哦,原來如此。
          • 為了便于對比,它包含了兩種類型的網(wǎng)絡設備:一個物理網(wǎng)卡和veth虛擬網(wǎng)卡。數(shù)據(jù)流分為兩條線路:線路1和線路2。
            線路1從物理網(wǎng)卡的數(shù)據(jù)接收開始,涉及到中斷處理流程和DMA。這一步的處理結(jié)果是網(wǎng)絡包被放進了與每個網(wǎng)卡相關(guān)的queue(RingBuffer)里面。
            線路2從容器內(nèi)的進程在veth一端發(fā)送數(shù)據(jù)開始,它相對簡單很多,主要是單純的軟件調(diào)用,沒有硬件的介入。這一步的處理結(jié)果是skb被放入到了input_pkt_queue里。
          • 無論是線路1還是線路2,它們都需要喚起ksoftirqd以便來處理skb,并提前將相應的網(wǎng)卡掛到per CPU的poll_list上。我們可以將poll_list想象成晾曬香腸的架子,而每個網(wǎng)絡設備則如同香腸一樣掛到架子上面等待ksoftirqd處理。
          • ksoftirqd扛起了網(wǎng)絡包處理的重擔。它從pull_list里找到要處理的網(wǎng)卡并從該網(wǎng)卡的queue里面拿到skb,然后沿著網(wǎng)絡設備子系統(tǒng) -> IP協(xié)議層 -> TCP層一路調(diào)用內(nèi)核里面的函數(shù)來分析和處理這個skb,最終將其放置到位于TCP層的socket接收隊列里。
            這個處理過程包括iptables的處理、路由查詢、TCP協(xié)議處理等各種費時費力的工作。如圖1所示,這里的iptables、路由查詢等數(shù)據(jù)部分與每個network namespace相關(guān),宿主機OS上會有若干個network ns,但TCP/IP協(xié)議棧作為代碼部分卻是大家共享的。

          圖 1:物理網(wǎng)卡和虛擬網(wǎng)卡數(shù)據(jù)接收完整數(shù)據(jù)處理流程

          圖2所示的K8s Overlay網(wǎng)絡模型的實現(xiàn)有一個重要的技術(shù)點:veth pair。我們暫時將位于容器內(nèi)的veth叫veth1,而插在bridge端口的那個對端veth稱為veth-peer。當網(wǎng)絡包從veth1流出時,其實是在圖1的2.a處把skb所屬的設備修改為veth-peer,先暫時放到了input_pkt_queue里,但這個時候skb還沒有到設備veth-peer處。
          步驟2.c所觸發(fā)的軟中斷使得ksoftirqd/4開始消費input_pkt_queue里的skb。
          當skb沿著圖1右上部分的TCP/IP協(xié)議棧流到位于鏈路層的網(wǎng)絡設備子系統(tǒng)的時候,也就來到了veth-peer的懷抱。對于veth-peer而言,這就開始了它接收網(wǎng)絡包的協(xié)議棧相關(guān)的處理流程,這個流程包含了二層和三層的數(shù)據(jù)包過濾、數(shù)據(jù)包轉(zhuǎn)換、路由查詢等細節(jié)。對數(shù)據(jù)包的處理和路由查詢所涉及到的規(guī)則和路由表都屬于網(wǎng)絡棧,而這個網(wǎng)絡棧與veth-peer所在的network namespace有關(guān)。

          圖2-圖6(除圖4)都有一個公共的部分:VPC(Virtual Private Cloud)。它可以讓我們在XX云上創(chuàng)建一個虛擬的私有網(wǎng)絡。各個VPC之間的網(wǎng)絡默認是完全的隔離的。VPC可以基于包括GRE、VXLAN在內(nèi)的各種技術(shù)實現(xiàn)。二哥在文章《當vpc遇到K8s overlay》中介紹了基于VXLAN的實現(xiàn)方法。
          通常VM被用來做K8s Work Node。這些圖中的VM通過VPC被分成了兩個隔離的網(wǎng)絡,淡橙色部分的VM網(wǎng)段為172.20.6.35/16,VXLAN ID為1234;藍色部分的網(wǎng)段為172.10.5.25/16,VXLAN ID為5678。
          當然,一臺物理服務器上會混合地運行屬于不同VPC的VM,這幾張圖也強調(diào)了這點。

          2. VPC與Overlay

          這部分細節(jié)參考二哥的文章《當vpc遇到K8s overlay》。
          圖2的重點是在每臺VM上,K8s CNI都會創(chuàng)建一個bridge和vtep。veth pair的一端安裝在了Pod內(nèi)部,而另一端則插到了網(wǎng)橋上。
          bridge即為網(wǎng)橋,它的行為類似二層交換機。如果網(wǎng)絡包的目的 MAC 地址為網(wǎng)橋本身,并且網(wǎng)橋設置了 IP 地址的話,那么bridge就認為該網(wǎng)絡包應該是發(fā)往創(chuàng)建該網(wǎng)橋的那臺主機,于是這個數(shù)據(jù)包將不會轉(zhuǎn)發(fā)到任何設備,而是直接交給上層(三層)協(xié)議棧去處理。處理的過程會涉及到基于本機路由表的路由查詢。
          VTEP(VXLAN Tunnel Endpoints)是VXLAN網(wǎng)絡中絕對的主角,它既可以是物理設備,也可以是虛擬化設備,主要負責 VXLAN 協(xié)議報文的封包和解包。
          在本機路由規(guī)則的精心配合下,從Pod發(fā)出來的網(wǎng)絡包先到達運行于這臺VM上的VTEP設備,在那里進行 VXLAN 封包。類似地在對端VM上VTEP設備也會參與其中并進行解封包操作。兩端VTEP的配合,給通信雙方的Pod營造了一個假象:它們?nèi)缤谕粋€扁平的二層互通的局域網(wǎng)一樣。
          但這沒有完,如果通信雙方的Pod位于不同的VM里,還需要VPC的配合。這是另外一個VXLAN的封包和解包的故事,也就出現(xiàn)了另外一個隧道。所以你會在圖2中看到兩層VXLAN隧道:深青色VXLAN隧道和粉色VXLAN隧道。

          圖 2:vpc和K8s overlay網(wǎng)絡模型

          前文說到圖1是基礎,是基石。那么它的基礎性在圖2中是如何體現(xiàn)的呢?圖2是veth pair+bridge+vtep的組合。那么當網(wǎng)絡包從位于Pod內(nèi)部的veth(發(fā)送端)流出的時候,就對應于圖1中的線路2入口處。發(fā)送端veth將網(wǎng)絡包遞交給接收端veth的過程涉及到圖1中的2.a、2.b、2.c。因為接收端veth插在網(wǎng)橋里面,這個過程涉及到網(wǎng)橋的處理,它體現(xiàn)在圖1中TCP/IP協(xié)議棧里面,bridge部分的處理流程部分。

          3. VPC與Underlay

          這部分細節(jié)參考二哥的文章《廣角-聊聊Underlay》和《一等公民,聊聊Underlay(微距篇)》。
          和圖2不同,圖3里網(wǎng)絡包從Pod流出后,像VM的eth0一樣,直接進入了Open vSwith上。簡單、粗暴、直接。但可惜,這種好事不是你想要就能有,得看K8s云產(chǎn)商是否提供這個功能。

          圖 3:vpc和K8s underlay網(wǎng)絡模型

          隔離特性使得流經(jīng)這些network namespace里的,各自網(wǎng)絡設備上面的流量是相互獨立、平行的,尤其重要的是Pod里的流量進出這臺虛擬機的時候,root network namespace無法感知到,所以在VM上對iptables、路由等設置對進出Pod的流量不起任何作用。traffic離開Pod和VM里的進程產(chǎn)生的traffic離開VM一樣,都是離開各自的network namespace。
          為了強調(diào)這樣的平行關(guān)系,我在圖3里畫了兩個藍色的箭頭和一個紅色的箭頭,它們的出發(fā)點分別是Pod和VM,終點是穿過Open vSwitch的遠方。traffic從各自的network namespace離開,互不見面,互不問候,互不干擾。
          不同的network ns有不同的實例。如前文所述,不同的實例包含了不同的網(wǎng)卡設備、IP地址等數(shù)據(jù)。TCP/IP協(xié)議棧只關(guān)心對于一個skb,要執(zhí)行何種net filter規(guī)則、該做何種路由又該從哪個網(wǎng)卡將這個skb送走。至于這個網(wǎng)卡是在Pod內(nèi)還是在宿主機VM上,重要嗎?不重要。
          什么?還是覺得抽象?沒關(guān)系,換個姿勢。二哥把內(nèi)核中負責描述進程的數(shù)據(jù)結(jié)構(gòu)task_struct和network namespace之間的結(jié)構(gòu)關(guān)系畫出來了。進程1和進程2共享宿主機root network namespace,它包含網(wǎng)卡eth0。Pod內(nèi)的容器自然位于Pod自己的network ns中。但容器本質(zhì)上也是進程而已,雖然在圖中看起來Pod隔離了一個完全屬于自己的eth1,但在內(nèi)核看來,一樣也是用相同的數(shù)據(jù)結(jié)構(gòu)來描述它和network ns之間的關(guān)系。
          好了,看完這個數(shù)據(jù)結(jié)構(gòu),我們再來想想,對于TCP/IP協(xié)議棧而言,是不是它面對的只是位于不同ns中的網(wǎng)卡而已呢?

          圖 4:network namespace與task_struct結(jié)構(gòu)關(guān)系圖

          4. VPC與host-gw

          可惜,這部分二哥之前沒有專門撰文介紹。
          Host-gw簡單來講就是將每個Node當成Pod的網(wǎng)關(guān)。所謂網(wǎng)關(guān)就像城門,是網(wǎng)絡包離開當前局部區(qū)域的卡口。從當前位置動身出發(fā)至目的地,一路上會有若干個城池,若干個城門。沿途中每一個這樣的卡口稱為“下一跳”,也即下一次暫時落腳的地方。大家見過青蛙在荷葉上連續(xù)跳動的樣子吧?青蛙每次都會選擇下一個可以歇腳的荷葉,并把它作為下一次跳躍的起點。你可以把網(wǎng)絡包想象成青蛙。
          “下一跳”這個概念,我想唐僧一定感悟頗深:貧僧來自東土大唐(就是源 IP 地址),欲往西天拜佛求經(jīng)(指的是目標 IP 地址)。路過寶地,借宿一晚,明日啟程,請問接下來該怎么走啊?
          Host-gw的實現(xiàn)方式有兩種典型的代表:Flannel和Calico。它們的共同點都是以Node為網(wǎng)關(guān),也都會查詢宿主機上的路由表。但在宿主機的網(wǎng)絡層看來,需要處理的網(wǎng)絡包來自不同的設備。

          4.1 VPC與host-gw(Flannel)

          Flannel的實現(xiàn)方案里,由bridge來將離開Pod的網(wǎng)絡包丟進宿主機TCP/IP協(xié)議棧進行路由的查詢。最終網(wǎng)絡包經(jīng)由宿主機的eth0離開并進入對方宿主機的eth。當然這個過程中離不開OVS基于VXLAN所架設的隧道。
          圖中flanneld是一個daemonset,它負責維護每個Node(網(wǎng)關(guān))的IP信息并更新宿主機的路由表。

          圖 5:vpc和K8s host-gw網(wǎng)絡模型(Flannel實現(xiàn)方案)

          圖5和圖1的關(guān)系在哪里呢?其實無論是網(wǎng)絡包通過veth pair流動到網(wǎng)橋這一部分還是網(wǎng)絡包從網(wǎng)橋出來后查詢宿主機路由表部分都與圖2“VPC與Overlay”非常相似。只不過差別在于經(jīng)過路由查詢后,二者的對網(wǎng)絡包的處理不一樣。圖2部分,網(wǎng)絡包被交給了vtep進行第一層的封包,而在這里,網(wǎng)絡包則被直接從本機eth0發(fā)送出去了??梢钥吹竭@里少了一次VXLAN的封包和解封包操作,故而效率提高了一些。

          4.2 VPC與host-gw(Calico)

          Calico方案與Flannel方案最大的區(qū)別就是網(wǎng)橋不見了。圖6中cali-xxx和Pod中的veth為veth pair。圖6少了網(wǎng)橋,相應地也就不需要圖1中bridge相關(guān)的處理過程,當cali-xxx收到了網(wǎng)絡包后沿著圖1所示的接收處理流程,直接將其丟進宿主機TCP/IP協(xié)議棧進行路由的查詢。
          圖6中BGP Client用于在集群里分發(fā)路由規(guī)則信息,而Felix則負責更新宿主機的路由表。
          其它類似,二哥就不再贅述了。

          圖 6:vpc和K8s host-gw網(wǎng)絡模型(Calico實現(xiàn)方案)

          瀏覽 182
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          評論
          圖片
          表情
          推薦
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  六月色播 | 国产黄色网色视频 | 特级茜茜人体444WWw高清大胆 | 男人的天堂青青草视频 | 成人无码做爰www欧美粉嫩 |