[翻譯] 一個kubernetes網絡簡明教程[Part 1]

一個kubernetes網絡簡明教程[Part 1]

翻譯: icebug

全部我學到的關於kubernetes網絡的事情

你可能已經在kubernetes集羣當中跑了一堆服務而且正在享受其帶來的好處. 或者至少, 你已經計劃這麼幹了. 雖然已經有一大堆工具能夠用來安裝或者管理集羣, 你任然想知道這一切究竟是怎麼回事. 另外, 當出現故障時到哪裏去尋找解決方案? 我知道, 由於我遇到過.

固然, Kubernetes剛開始使用時很是簡單. 但仍是讓我直面它吧--它就是一隻引擎蓋下面的怪獸. 這裏有不少可剝離的組件, 若是你想在失敗面前處亂不驚, 知道如何將它們完美地組在一塊兒工做則是一項必備技能. 其中最複雜, 也是最有挑戰的一部分就是網絡了.

因此我開始着手去理解網絡在kubernetes當中到底是如何工做的. 我讀文檔, 看演講, 甚至翻閱了源代碼, 以下是個人一些發現.

Kubernetes網絡模型

在kubernetes的核心當中, Kubernetes網絡有一個重要的基礎設計哲學.

每個Pod都有一個獨一無二的IP.

這個Pod IP被這個Pod當中的全部容器所共享, 而且它能夠從其餘全部的Pod當中路由過來. 你注意到了一些「pause」字樣的容器運行在你的Kubernetes節點當中嗎? 它們被稱爲「沙盒容器」, 它們的惟一做用就是保留和佔據一個被Pod當中全部容器所共享的網絡命名空間(netns). 就這樣, 一個Pod IP並不會隨着Pod當中的一個容器的起停而改變. 這種一個Pod一個IP的模型的一個巨大的好處就是跟宿主機永遠也不會有IP或者端口衝突, 咱們甚至都不用管應用用的是什麼端口.

有了上面的基礎, Kubernetes目前惟一的需求就是這些Pod IP是可路由或者說能夠被全部其餘Pod訪問的, 無論這些Pod運行在什麼節點上.

節點內網絡通訊

第一步先要確保同一個節點上的Pod能夠相互通訊, 而後再把這個想法擴展到跨節點通訊以及互聯網通訊等.

在每個Kubernetes節點上, 在這裏假設是一臺Linux機器, 會有一個root網絡命名空間(root表示基命名空間, 區別於系統當中的超級用戶root) -- root netns.

主要的網絡接口eth0在root netns當中.

一樣的, 每個Pod也都有它本身的netns, 有一個虛擬的以太網絡接口對鏈接到root netns當中. 這只是一個基礎的管道對, 一端鏈接到root netns當中, 另外一端鏈接到Pod netns當中.

Kubernetes節點 (root命名空間)

咱們把Pod這端的接口命名爲eth0, 因此Pod並不知道底下的宿主機並認爲本身已經設置了root netns, 另外一端鏈接root netns的接口的命名爲vnetxxx的樣式.

Kubernetes節點 (Pod網絡命名空間)

你能夠經過ifconfig命令或者ip a命令在你的節點上看到全部的接口.

這一切對於節點上的全部Pod都同樣. 對於想要想要互相通訊Pod, 還須要用到Linux以太網網橋cbr0, Docker用了一個類似的網橋命名爲docker0. 你能夠經過brctl show看到全部的網橋.

Kubernetes Node (Linux network bridge)

假設一個網絡包要從Pod 1到Pod 2.

1. 網絡包從eth0離開Pod 1的netns並經過vnetxxx進入到root netns.
2. 網絡包被傳到網橋cbr0, 網橋經過發送「who has this IP?」的ARP請求來發現網絡包須要轉發到的目的地.
3. vethyyy回答到它有這個IP, 因此網橋知道應該把網絡包轉發到哪裏.
4. 網絡包到達vethyyy接口, 並經過管道對進入到Pod 2的netns.

Kubernetes Node (same node pod-to-pod communication)

以上就是一個節點當中的容器是如何進行網絡通訊的內容. 很顯然, 還有別的方式, 但這多是最簡單的方式, 而且Docker也是採用的這種方式.

節點間的網絡通訊

正如我前面提到的, Pod也須要在各個節點之間可以相互訪問. Kubernetes並無論它是如何實現的. 咱們能用L2(跨節點ARP), L3(跨節點進行IP路由 -- 像雲服務提供商的路由表), overlay 網絡, 甚至用信鴿. 只要能網絡流量能到達另外一個節點上指定的Pod, 這一切都沒有關係. 每個節點都會被分配一個獨一無二的CIDR塊(一個IP地址範圍)用於Pod IP, 因此每個Pod都有一個獨一無二的不會和別的節點上的Pod相沖突的IP.

在大多數的狀況下, 尤爲是在雲環境當中, 雲計算提供廠商的路由表保證了網絡包抵達正確的目的地. 一樣的事情也可以經過在每一個節點上設置正確的路由來完成. 這裏還有一堆其餘的網絡插件用於完成這件事情.

下面咱們有兩個節點, 跟咱們前面看到的同樣, 每個節點都含有不一樣的網絡命名空間, 網絡接口和一個網橋.

Kubernetes Nodes with route table (cross node pod-to-pod communication)

假設一個網絡包從pod1到pod4(在一個不一樣的節點上)

1. 網絡包從eth0離開Pod 1的netns, 並從vethxxx進入root netns.
2. 網絡包被傳到cbr0網橋, 經過ARP請求來尋找網絡包目的地.
3. 網絡包從cbr0傳到主網絡接口eth0, 由於在這個節點上沒有人有Pod 4的IP地址.
4. 網絡包開始離開node 1, 走上了一條出發端是Pod 1, 目的端是Pod 4的線上.
5. 路由表上已經設置好了各個節點上CIDR的路由, 而且將網絡包路由到CIDR塊含有Pod 4 IP的節點.

6. 因此網絡包到達了node 2的主網絡接口eth0, 雖然Pod 4不是eth0的IP, 網絡包仍然被轉發到cbr0, 由於節點被配置爲能夠進行IP轉發, 節點的路由表會尋找任何匹配Pod 4 IP的路由. 而後找到cbr0做爲這個節點CIDR塊的目的地. 你能夠經過route -n命令查看節點的路由表, 而後會發現一條關於cbr0的路由以下:

7. cbr0網橋獲取到網絡包, 發出一個ARP請求, 而後發現IP屬於vethyyy.

8. 網絡包經過管道對抵達Pod4.

這是一篇關於Kubernetes網絡基礎的文章, 因此假以下次Kubernetes網絡出現問題了, 別忘了檢查那些網橋和路由表. 😉

這就是這篇文章的所有了, 在下一篇文章, 咱們來看看「overlay網絡是如何工做的[Part 2]」, 當pod不斷地建立和刪除時網絡發生了什麼變化, 以及流入和流出的網絡流量是如何流動的.

Reference

原文: https://medium.com/@ApsOps/an-illustrated-guide-to-kubernetes-networking-part-1-d1ede3322727

譯者感悟

一直想翻譯一些好的英文文檔和文章, 奈何惰性太強, 一直仍是停留在想法階段. 下午好友問我要不要加入Kubernetes翻譯組, 這不就是本身一直想作的事情嘛, 說幹就幹, 而後才知道報名篩選規則至少要提交一篇本身翻譯過的文章, 而後下班後找來一篇以前學習Kubernetes網絡時看過的一篇文章, 零零散散花了差很少三個小時翻譯了這篇文章. 第一次翻譯, 可能有翻譯的不太準確或者恰當的地方, 歡迎拍磚指正. 且無論能不能加入到Kubernetes翻譯組, 今天算是開了個好頭了.