【容器網絡】Calico容器網絡方案

Calico容器網絡方案

Calico共有兩個容器網絡方案：Calico BGP和Calico IPIP。

Calico BGP方案

Calico BGP數據面如下：

同節點容器通信

容器A訪問容器B，數據面流程如下：

1. 容器A內的calic0設備的掩碼長度爲32，即與容器B屬於不同網絡，需要通過網關進行通信
2. 容器A查找路由表，存在default路由，下一跳爲169.254.1.1，且169.254.1.1可通過cali0直達
3. 容器A發送ARP請求給169.254.1.1，ARP請求報文到達veth設備的另一端califXXX接收
4. 由於califXXX設備使能了ARP proxy，Linux內核會以califXXX的MAC地址來響應ARP請求，並從califXXX發出；
5. 容器A收到ARP響應後，得到169.254.1.1的MAC地址，封裝二層報文，發送報文給169.254.1.1，報文從cali0設備發出
6. 報文通過veth設備進入Host內核協議棧；
7. 由於目的IP不在本節點，Host內核會進行報文轉發（ip_forward已開啓）
8. Host內核超找路由表，發現路由條目，通過califYYYYYY設備可以直達
9. Host內核發送ARP請求給容器B，通過califYYYYYY設備發出
10. ARP請求報文通過veth設備到達容器B，容器B響應ARP請求，ARP響應通過veth設備到達Host內核
11. Host內核更新報文的二層頭，從califYYYYYY設備發出
12. 報文通過veth設備到達容器B

Host的本地路由在創建容器的時候就能夠建立，不依賴BGP

跨節點容器通信

容器A訪問容器D，數據面流程如下：

1. 容器A內的calic0設備的掩碼長度爲32，即與容器B屬於不同網絡，需要通過網關進行通信
2. 容器A查找路由表，存在default路由，下一跳爲169.254.1.1，且169.254.1.1可通過cali0直達
3. 容器A發送ARP請求給169.254.1.1，ARP請求報文到達veth設備的另一端califXXX接收
4. 由於califXXX設備使能了ARP proxy，Linux內核會以califXXX的MAC地址來響應ARP請求，並從califXXX發出；
5. 容器A收到ARP響應後，得到169.254.1.1的MAC地址，封裝二層報文，發送報文給169.254.1.1，報文從cali0設備發出
6. 報文通過veth設備進入Host1內核協議棧；
7. 由於目的IP不在本節點，Host1內核會進行報文轉發（ip_forward已開啓）
8. Host1內核查找路由表，發現路由條目，通過下一跳192.168.0.102（Host2）可以到達，而192.168.0.102可以直達
9. Host1內核發送ARP請求給Host2，通過eth0設備發出
10. ARP請求報文通過底層網絡到達Host2，Host2響應ARP請求，通過底層網絡到達Host1
11. Host1內核修改報文二層頭，發送報文給Host2
12. Host2收包報文，由於目的IP不在本節點，Host2內核會進行報文轉發（ip_forward已開啓）
13. Host2查找路由表，發現路由條目，通過califYYYYY設備可以直達
14. Host2內核發送ARP請求給容器D，通過califYYYYY設備發出
15. ARP請求報文通過veth設備到達容器D，容器B響應ARP請求，ARP響應通過veth設備到達Host2內核
16. Host2內核更新報文的二層頭，從califYYYYY設備發出
17. 報文通過veth設備到達容器D

Host1中關於容器D的路由信息是如何獲取的？ 這就是Calico BGP方案的核心，答案是通過BIRD在節點間同步得到

Calico BGP數據面總結

• 方案基本原理
  • 容器IP的掩碼是32位，強制走三層轉發
  • 同步各節點的路由信息，使所有節點掌握全局的網絡轉發規則
• 方案優勢
  • 方案不依賴底層網絡，只要求底層三層能通即可
  • 支持按節點分配IP網段，同時還可以自定義容器IP（路由通過網絡長度優先匹配）
• 方案劣勢
  • 本節點也需要通過路由轉發，性能較差
  • 路由通過BIRD同步，屬於異步同步方式，容器創建後立即通信可能存在路由未同步的風險
  • 在底層網絡中暴露了容器網絡地址
  • 當節點之間二層不可達時，需要在路由器上發佈路由，否則容器之間無法通信
• 改進想法
  • 避免169.254.1.1的ARP請求
    • 可以固定califXX設備的MAC地址
    • 容器內固化ARP表項
  • 使用etcd同步路由信息，去除對BGP的依賴

Calico IPIP方案

由於Calico BGP方案把容器網絡暴露到了底層網絡中， 而Calico IPIP方案把容器網絡信息通過IP隧道屏蔽了，而且通過IPIP方案可以提供加密傳輸的功能，防止報文被竊聽

Calicao IPIP數據面如下：

同節點容器通信

容器A訪問容器B，數據面流程如下（同Calico BGP）：

1. 容器A內的calic0設備的掩碼長度爲32，即與容器B屬於不同網絡，需要通過網關進行通信
2. 容器A查找路由表，存在default路由，下一跳爲169.254.1.1，且169.254.1.1可通過cali0直達
3. 容器A發送ARP請求給169.254.1.1，ARP請求報文到達veth設備的另一端califXXX接收
4. 由於califXXX設備使能了ARP proxy，Linux內核會以califXXX的MAC地址來響應ARP請求，並從califXXX發出；
5. 容器A收到ARP響應後，得到169.254.1.1的MAC地址，封裝二層報文，發送報文給169.254.1.1，報文從cali0設備發出
6. 報文通過veth設備進入Host內核協議棧；
7. 由於目的IP不在本節點，Host內核會進行報文轉發（ip_forward已開啓）
8. Host內核超找路由表，發現路由條目，通過califYYYYYY設備可以直達
9. Host內核發送ARP請求給容器B，通過califYYYYYY設備發出
10. ARP請求報文通過veth設備到達容器B，容器B響應ARP請求，ARP響應通過veth設備到達Host內核
11. Host內核更新報文的二層頭，從califYYYYYY設備發出
12. 報文通過veth設備到達容器B

Host的本地路由在創建容器的時候就能夠建立，不依賴BGP

跨節點容器通信

容器A訪問容器D，數據面流程如下：

1. 容器A內的calic0設備的掩碼長度爲32，即與容器B屬於不同網絡，需要通過網關進行通信
2. 容器A查找路由表，存在default路由，下一跳爲169.254.1.1，且169.254.1.1可通過cali0直達
3. 容器A發送ARP請求給169.254.1.1，ARP請求報文到達veth設備的另一端califXXX接收
4. 由於califXXX設備使能了ARP proxy，Linux內核會以califXXX的MAC地址來響應ARP請求，並從califXXX發出；
5. 容器A收到ARP響應後，得到169.254.1.1的MAC地址，封裝二層報文，發送報文給169.254.1.1，報文從cali0設備發出
6. 報文通過veth設備進入Host1內核協議棧；
7. 由於目的IP不在本節點，Host1內核會進行報文轉發（ip_forward已開啓）
8. Host1內核查找路由表，發現路由條目，通過下一跳192.168.0.102（Host2）可以到達，而192.168.0.102可以直達
9. Host內核發送ARP請求給Host2，通過eth0設備發出
10. ARP請求報文通過底層網絡到達Host2，Host2響應ARP請求，通過底層網絡到達Host1
11. Host1內核發送報文給TUN10設備（因爲IPIP是三層設備，不需要二層頭，所以不會向192.168.0.102發送ARP請求）
12. IPIP設備封裝外層IP頭（IPIP設備是端到端設備，創建時指定了對端）
13. IPIP設備封裝外層MAC頭，並從eth0發出報文
14. Host2接收到IPIP報文，交給ipip協議進行收包處理
15. ipip協議處理完成後，最終進行ip_forward處理
16. Host2查找路由表，發現路由條目，通過califYYYYY設備可以直達
17. Host2內核發送ARP請求給容器D，通過califYYYYY設備發出
18. ARP請求報文通過veth設備到達容器D，容器B響應ARP請求，ARP響應通過veth設備到達Host2內核
19. Host2內核更新報文的二層頭，從califYYYYY設備發出
20. 報文通過veth設備到達容器D

Calico IPIP數據面總結

• 由於IPIP爲管道設備，當節點數量增加時，IPIP設備也同步增加
  • 可以使用VXLAN設備來代替IPIP設備，但是性能有損失
• 對節點外的設備，屏蔽了容器網絡信息，對底層網絡無依賴