K8S搭建完畢之后，碰到個問題，如何進行遠程debug（別在生產(chǎn)環(huán)境遠程debug哦）？那就需要打通局域網(wǎng)和K8S內(nèi)部網(wǎng)絡了。本文主要介紹Pod通信、K8S網(wǎng)絡插件、局域網(wǎng)和K8S網(wǎng)絡如何打通。

1、問題描述

我們在實際使用K8S過程中，出現(xiàn)了以下需求：

• 出現(xiàn)問題時，想進行遠程debug調(diào)試。
• 開發(fā)在電腦完成某個微服務模塊開發(fā)后，希望本地啟動后，能注冊到開發(fā)環(huán)境的注冊中心進行調(diào)試，而不是本地起一堆依賴的服務。

以上問題，如果在辦公室網(wǎng)絡 和 K8S Pod 網(wǎng)絡不通的情況下就很難受。

由于Kubernetes集群會使用CNI插件創(chuàng)建Pod/Service內(nèi)部子網(wǎng)，外面一般無法訪問內(nèi)部IP和域名，給開發(fā)、測試、 聯(lián)調(diào)帶來了很大的麻煩，因此打通開發(fā)測試環(huán)境Kubernetes集群內(nèi)部子網(wǎng)和辦公室的局域網(wǎng)，實現(xiàn)互聯(lián)互通是經(jīng)常遇到的問題。

在打通之前，我們先了解下K8S網(wǎng)絡的基本知識。K8S的網(wǎng)絡架構比較復雜，Kubernetes本身并不負責網(wǎng)絡通信，但提供了容器網(wǎng)絡接口CNI（Container Network Interface），具體的網(wǎng)絡通信交由CNI插件來實現(xiàn)。

這是一種標準設計，為了讓用戶在創(chuàng)建或銷毀容器時都能夠更容易地配置容器網(wǎng)絡。用戶只需要使用CNI插件就可以輕松的管理K8S網(wǎng)絡。目前主流的開源CNI插件非常多，像Flannel、Calico等。

2、常見術語

在探索CNI插件之前先了解下幾個術語：

• eth0：是系統(tǒng)的光纖以太網(wǎng)接口卡名稱，也會有別的名稱，比如ens192。
• veth 虛擬網(wǎng)絡設備：veth設備是成對出現(xiàn)的，一端連著Pod，另一端連著CNI。
• netns：netns 是Linux Network Namespace 的縮寫，是 Linux 提供的原生網(wǎng)絡隔離功能組件，能在 Linux 系統(tǒng)中虛擬出來多個網(wǎng)絡空間，實現(xiàn)網(wǎng)絡資源的隔離。
• 第2層網(wǎng)絡：OSI（Open Systems Interconnections，開放系統(tǒng)互連）網(wǎng)絡模型的“數(shù)據(jù)鏈路”層。第2層網(wǎng)絡會處理網(wǎng)絡上兩個相鄰節(jié)點之間的幀傳遞。第2層網(wǎng)絡的一個值得注意的示例是以太網(wǎng)，其中MAC表示為子層。
• 第3層網(wǎng)絡：OSI網(wǎng)絡模型的“網(wǎng)絡”層。第3層網(wǎng)絡的主要關注點，是在第2層連接之上的主機之間路由數(shù)據(jù)包。IPv4、IPv6和ICMP是第3層網(wǎng)絡協(xié)議的示例。
• VXLAN：代表“虛擬可擴展LAN”。首先，VXLAN用于通過在UDP數(shù)據(jù)報中封裝第2層以太網(wǎng)幀來幫助實現(xiàn)大型云部署。VXLAN虛擬化與VLAN類似，但提供更大的靈活性和功能（VLAN僅限于4096個網(wǎng)絡ID）。VXLAN是一種封裝和覆蓋協(xié)議，可在現(xiàn)有網(wǎng)絡上運行。
• Overlay網(wǎng)絡：Overlay網(wǎng)絡是建立在現(xiàn)有網(wǎng)絡之上的虛擬邏輯網(wǎng)絡。Overlay網(wǎng)絡通常用于在現(xiàn)有網(wǎng)絡之上提供有用的抽象，并分離和保護不同的邏輯網(wǎng)絡。
• 封裝：封裝是指在附加層中封裝網(wǎng)絡數(shù)據(jù)包以提供其他上下文和信息的過程。在overlay網(wǎng)絡中，封裝被用于從虛擬網(wǎng)絡轉(zhuǎn)換到底層地址空間，從而能路由到不同的位置（數(shù)據(jù)包可以被解封裝，并繼續(xù)到其目的地）。
• 網(wǎng)狀網(wǎng)絡：網(wǎng)狀網(wǎng)絡（Mesh network）是指每個節(jié)點連接到許多其他節(jié)點以協(xié)作路由、并實現(xiàn)更大連接的網(wǎng)絡。網(wǎng)狀網(wǎng)絡允許通過多個路徑進行路由，從而提供更可靠的網(wǎng)絡。網(wǎng)狀網(wǎng)格的缺點是每個附加節(jié)點都會增加大量開銷。
• BGP：代表“邊界網(wǎng)關協(xié)議”，用于管理邊緣路由器之間數(shù)據(jù)包的路由方式。BGP通過考慮可用路徑，路由規(guī)則和特定網(wǎng)絡策略，幫助弄清楚如何將數(shù)據(jù)包從一個網(wǎng)絡發(fā)送到另一個網(wǎng)絡。BGP有時被用作CNI插件中的路由機制，而不是封裝的覆蓋網(wǎng)絡。
• IP隧道技術：是路由器把一種網(wǎng)絡層協(xié)議封裝到另一個協(xié)議中以跨過網(wǎng)絡傳送到另一個路由器的處理過程。 IP 隧道（IP tunneling）是將一個IP報文封裝在另一個IP報文的技術，這可以使得目標為一個IP地址的數(shù)據(jù)報文能被封裝和轉(zhuǎn)發(fā)到另一個IP地址。IP隧道技術亦稱為IP封裝技術。

3、Pod通信

在打通局域網(wǎng)與Kubernetes內(nèi)部網(wǎng)絡之前，先簡單描述下，K8S的Pod之間是如何通信的。

3.1、同一個節(jié)點中的Pod通信

Pod通過虛擬Ethernet接口對（Veth Pair）與外部通信，Veth Pair像一根網(wǎng)線，一端在Pod內(nèi)部，一端在Pod外部。同一個節(jié)點上的Pod通過網(wǎng)橋（Linux Bridge）通信，如下圖所示。

在同一節(jié)點上的Pod會通過Veth設備將一端連接到網(wǎng)橋，且它們的IP地址是通過網(wǎng)橋動態(tài)獲取的，和網(wǎng)橋IP屬于同一網(wǎng)段。此外，同一節(jié)點上的所有Pod默認路由都指向網(wǎng)橋，網(wǎng)橋會負責將所有非本地地址的流量進行轉(zhuǎn)發(fā)。因此，同一節(jié)點上的Pod可以直接通信。

3.2、不同節(jié)點的Pod通信

Kubernetes要求集群Pod的地址唯一，因此集群中的每個節(jié)點都會分配一個子網(wǎng)，以保證Pod的IP地址在整個集群內(nèi)部不會重復。在不同節(jié)點上運行的Pod通過IP地址互相訪問，該過程需要通過集群網(wǎng)絡插件實現(xiàn)，按照底層依賴大致可分為Overlay模式、路由模式、Underlay模式三類。

• Overlay模式是在節(jié)點網(wǎng)絡基礎上通過隧道封裝構建的獨立網(wǎng)絡，擁有自己獨立的IP地址空間、交換或者路由的實現(xiàn)。VXLAN協(xié)議是目前最流行的Overlay網(wǎng)絡隧道協(xié)議之一。
• 路由模式采用VPC路由表的方式與底層網(wǎng)絡相結合，能夠更加便捷地連接容器和主機，在性能上會優(yōu)于Overlay的隧道封裝。
• Underlay模式是借助驅(qū)動程序?qū)⒐?jié)點的底層網(wǎng)絡接口直接暴露給容器使用的一種網(wǎng)絡構建技術，享有較高的性能，較為常見的解決方案有IP VLAN等。

4、網(wǎng)絡插件

本文只介紹Calico，因為Flannel我也沒用過，云上的K8S網(wǎng)絡插件基本都是云廠商結合自己的VPC網(wǎng)絡實現(xiàn)的，更不在介紹范圍內(nèi)了。

k8s網(wǎng)絡插件主要分為：underlay和overlay，calico 主要分為3種模式：BGP、IPIP、VXLAN，BGP屬于underlay、IPIP和VXLAN屬于overlay。

Calico 是一種開源網(wǎng)絡和網(wǎng)絡安全解決方案，適用于容器，虛擬機和基于主機的本機工作負載。Calico 支持廣泛的平臺，包括 Kubernetes，docker，OpenStack 和裸機服務。Calico 后端支持多種網(wǎng)絡模式。

本文主要分析calico的ipip模式，旨在理解IPIP網(wǎng)絡模式下產(chǎn)生的calixxxx，tunl0等設備以及跨節(jié)點網(wǎng)絡通信方式。ipip模式主要原理就是在pod ip的基礎上再封裝一層node ip，這樣在通過對應的路由規(guī)則，就可以轉(zhuǎn)發(fā)到對應的目的地。

4.1、網(wǎng)絡初窺

我采用的CNI插件Calico，例如，通過ip addr命令可以看到K8S Node節(jié)點下有許多cali打頭的虛擬網(wǎng)卡，同時，還有tunl0這種IP隧道，可以看到采用的是Calico的IPIP模式。

通過route -n命令也能看到每個pod會對應一個虛擬網(wǎng)卡，訪問別的網(wǎng)段會通過tunl0這個隧道發(fā)出去。

4.2、Calico的IPIP模式：

IPIP 模式：Calico默認使用這種方式。在原有 IP 報文中封裝一個新的 IP 報文，新的 IP 報文中將源地址 IP 和目的地址 IP 都修改為對端宿主機 IP。開啟時將Node路由之間做一個tunnel，再把兩個網(wǎng)絡連接起來的模式，會在各Node節(jié)點上創(chuàng)建一個名為tunl0的虛擬網(wǎng)絡接口。

IP模式下的通信流程，見如下2個圖：

在K8S-Node上執(zhí)行ip addr可以看到以下信息，其中包含了tunl0和calixxxxxx：

# 回環(huán)地址
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
# 物理網(wǎng)卡
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:50:56:95:32:45 brd ff:ff:ff:ff:ff:ff
    inet 10.20.1.22/24 brd 10.20.1.255 scope global noprefixroute ens192
       valid_lft forever preferred_lft forever
# Docker0
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:4f:0d:6a:48 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
# cali打頭的Calico網(wǎng)卡
4: cali7533706c752@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 0
7: cali6bf54ec99f4@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 3
8: calif0a8819d7b4@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 4
9: cali2299828844c@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 5
10: cali7c84f4d310b@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 6
# Calico IP隧道使用的Tunl0網(wǎng)卡
15: tunl0@NONE: <NOARP,UP,LOWER_UP> mtu 1440 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
    inet 10.21.230.0/32 brd 10.21.230.0 scope global tunl0
       valid_lft forever preferred_lft forever

我們也可以看到veth是成對出現(xiàn)的，比如進入到Pod，查看網(wǎng)絡情況，在K8S-Master執(zhí)行命令kubectl exec -it ingress-nginx-controller-nginx-d864d97df-22ljk -n ingress-nginx -- ip addr，可以看到虛擬網(wǎng)卡的編號if19，如下情況：

# 回環(huán)網(wǎng)卡
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
# 虛擬網(wǎng)卡
3: eth0@if19: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1440 qdisc noqueue state UP
    link/ether 66:e5:5b:b6:77:9a brd ff:ff:ff:ff:ff:ff
    inet 10.21.69.212/32 scope global eth0
       valid_lft forever preferred_lft forever
# 隧道網(wǎng)卡
4: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0

在到這個Pod所在K8S-Node執(zhí)行命令ip addr，可以看到有一個編號是19的cailixxxxx，如下情況：

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:50:56:95:c0:f4 brd ff:ff:ff:ff:ff:ff
    inet 10.20.1.24/24 brd 10.20.1.255 scope global noprefixroute ens192
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:2c:ea:87:52 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
5: cali7359ae97a07@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 1
6: cali763ea01ddd0@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 2
8: cali0140629a81f@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 4
10: calid3a5006f559@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 6
11: calic2abb800440@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 7
12: cali06eecb511af@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 8
13: cali26321116fa3@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 9
17: calia5d32a88758@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 13
# Pod內(nèi)的eht0標記的是19號和這里的19號是配對的
19: calib51fc1cd61e@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 15
20: cali5910af186a4@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 16
21: calie8b8d191185@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 17

4.3、Calico的BGP模式：

BGP 模式：將節(jié)點做為虛擬路由器通過 BGP 路由協(xié)議來實現(xiàn)集群內(nèi)容器之間的網(wǎng)絡訪問。不再創(chuàng)建額外的tunnel。它會以daemonset方式安裝在所有node主機，每臺主機啟動一個bird(BGP client)，它會將calico網(wǎng)絡內(nèi)的所有node分配的ip段告知集群內(nèi)的主機，并通過本機的默認網(wǎng)關的網(wǎng)卡（如：eth0）轉(zhuǎn)發(fā)數(shù)據(jù) BGP網(wǎng)絡相比較IPIP網(wǎng)絡，最大的不同之處就是沒有了隧道設備 tunl0。 前面介紹過IPIP網(wǎng)絡pod之間的流量發(fā)送到 tunl0，然后tunl0發(fā)送對端設備。BGP網(wǎng)絡中，pod之間的流量直接從網(wǎng)卡發(fā)送目的地，減少了tunl0這個環(huán)節(jié)。

BGP模式下的通信流程，見下圖：

BGP模式的優(yōu)點：少了封包和解包的過程，性能高一些。

BGP模式的缺點：需要維護更多的路由規(guī)則。

IPIP隧道模式的優(yōu)點：簡單，原因是大部分工作都是由 Linux 內(nèi)核的模塊實現(xiàn)了，應用層面工作量較少。

IPIP隧道模式的缺點：主要的問題因為要封包接包，性能低。

5、局域網(wǎng)與Kubernetes內(nèi)部網(wǎng)絡互通

如果K8S集群就部署在局域網(wǎng)內(nèi)或者部署在自己的數(shù)據(jù)中心，整個鏈路上的網(wǎng)關可配的話，用靜態(tài)路由表是最簡單的辦法，其原理是作用在網(wǎng)絡模型的第三層 網(wǎng)絡層，直接告訴網(wǎng)關某些IP要發(fā)給誰。

通過上面的K8S網(wǎng)絡小知識和執(zhí)行命令看到的路由轉(zhuǎn)發(fā)的截圖，我們知道K8S-Node其實也是一個虛擬路由，只要請求被轉(zhuǎn)發(fā)到K8S-Node，那么就可以訪問到Pod。

舉一個最簡單的例子，某開發(fā)環(huán)境的K8S部署在和辦公室同一個局域網(wǎng)，有下面兩條線路可以打通網(wǎng)絡，如下圖：

此時只需要公司的運維在網(wǎng)關路由器上添加靜態(tài)路由規(guī)則，把屬于K8S的Pod/Service CIDR的IP包全轉(zhuǎn)給其中某個K8S節(jié)點，這樣訪問10.96.0.1這樣的IP，網(wǎng)絡包會到達某個集群物理節(jié)點，而集群內(nèi)的物理節(jié)點或VM，一般K8S網(wǎng)絡插件(CNI)都會做與Pod/Service CIDR的互通。

如果K8S部署的機器和公司辦公室不在同一個網(wǎng)關下，或者部署在自建數(shù)據(jù)中心的，整個鏈路會多幾個網(wǎng)關，鏈路上每個網(wǎng)關都需要配置路由表路由相應的CIDR到相鄰的躍點，如果是辦公網(wǎng)絡到到達云上的K8S集群，也只需要從路由器經(jīng)過VPN到達云上即可，如下圖：

總結：本文主要講了K8S網(wǎng)絡基礎知識、局域網(wǎng)與K8S網(wǎng)絡如何打通，希望對你有幫助。如果覺得有誤，也請糾正，謝謝！

本篇完結！感謝你的閱讀，歡迎點贊 關注 收藏 私信！?。?/strong>