局域網(wǎng)與Kubernetes內(nèi)部網(wǎng)絡(luò)如何互通

作者：不焦躁的程序員 2023-09-07 23:59:44

本文主要講了K8S網(wǎng)絡(luò)基礎(chǔ)知識、局域網(wǎng)與K8S網(wǎng)絡(luò)如何打通，希望對你有幫助。

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

一、問題描述

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

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

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

由于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)，實(shí)現(xiàn)互聯(lián)互通是經(jīng)常遇到的問題。

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

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

二、常見術(shù)語

在探索CNI插件之前先了解下幾個(gè)術(shù)語：

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

三、Pod通信

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

1.同一個(gè)節(jié)點(diǎn)中的Pod通信

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

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

2.不同節(jié)點(diǎn)的Pod通信

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

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

四、網(wǎng)絡(luò)插件

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

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

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

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

1.網(wǎng)絡(luò)初窺

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

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

2.Calico的IPIP模式：

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

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

在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)的，比如進(jìn)入到Pod，查看網(wǎng)絡(luò)情況，在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

在到這個(gè)Pod所在K8S-Node執(zhí)行命令ip addr，可以看到有一個(gè)編號是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標(biāo)記的是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

3.Calico的BGP模式：

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

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

BGP模式的優(yōu)點(diǎn)：少了封包和解包的過程，性能高一些。
BGP模式的缺點(diǎn)：需要維護(hù)更多的路由規(guī)則。
IPIP隧道模式的優(yōu)點(diǎn)：簡單，原因是大部分工作都是由 Linux 內(nèi)核的模塊實(shí)現(xiàn)了，應(yīng)用層面工作量較少。
IPIP隧道模式的缺點(diǎn)：主要的問題因?yàn)橐獍影阅艿汀?/li>

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

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

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

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

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

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