本文介紹容器環(huán)境常見網(wǎng)絡(luò)應(yīng)用場景及對(duì)應(yīng)場景的 Kubernetes CNI 插件功能實(shí)現(xiàn)。幫助搭建和使用云原生環(huán)境的小伙伴快速選擇心儀的網(wǎng)絡(luò)工具。

常見網(wǎng)絡(luò)插件

我們?cè)趯W(xué)習(xí)容器網(wǎng)絡(luò)的時(shí)候，肯定都聽說過 Docker 的 bridge 網(wǎng)絡(luò)，Vethpair，VxLAN 等術(shù)語，從 Docker 到 Kubernetes 后，學(xué)習(xí)了 Flannel、Calico 等主流網(wǎng)絡(luò)插件，分別代表了 Overlay 和 Underlay 的兩種網(wǎng)絡(luò)傳輸模式，也是很經(jīng)典的兩款 CNI 網(wǎng)絡(luò)插件。那么，還有哪些好用的 CNI 插件呢 ? 我們看看 CNCF Landscape:

拋去商業(yè)版 CNI，此次分享來聊聊幾款熱門開源 CNI 插件，分別為 Kube-OVN、Antrea、Cilium。Kube-OVN 和 Antrea 都是基于 OpenvSwitch 的項(xiàng)目，Cilium 使用 eBPF 這款革命性的技術(shù)作為數(shù)據(jù)路徑，亦是這兩年很火熱的一個(gè)開源容器項(xiàng)目。

那么，又回到學(xué)習(xí)新產(chǎn)品的第一步，如何快速部署 K8s 體驗(yàn)不同地 CNI 插件呢？還是交給我們親愛的 Kubekey 吧。

Kubekey作為一個(gè)開源的 Kubernetes 和 KubeSphere集群部署工具，可以輕松的部署 Kubernetes 集群，提供節(jié)點(diǎn)管理、操作系統(tǒng)安全加固、容器運(yùn)行時(shí)管理、網(wǎng)絡(luò)存儲(chǔ)安裝、Etcd 管理等。Kubekey 支持一鍵部署 Calico / Flannel / Cilium / Kube-OVN 等網(wǎng)絡(luò)插件，只需在 kk 的配置文件中注明 network 的 plugin 值即可：

??network:
????plugin:?calico/kubeovn/cilium
????kubePodsCIDR:?10.233.64.0/18
????kubeServiceCIDR:?10.233.0.0/18

對(duì)于 antrea，由于版本較新，目前可通過 addon 的形式添加 helm 文件的形式進(jìn)行一鍵安裝：

??addons:
??-?name:?antrea
????namespace:?kube-system
????sources:?
??????chart:?
????????name:?antrea
????????repo:?https://charts.antrea.io
????????#?values:

在此基礎(chǔ)上，可以通過以下一條命令

????→?kk?create?cluster?--with-kubernetes?--with-kubesphere

創(chuàng)建一個(gè) Kubernetes 集群并安裝 KubeSphere，在此之上體驗(yàn)不同的 CNI 在 Kubernetes 的功能應(yīng)用。畢竟，哪個(gè)運(yùn)維人員不喜歡頁面友好的容器管理平臺(tái)呢？

網(wǎng)絡(luò)應(yīng)用場景

現(xiàn)在我們已經(jīng)有了一個(gè) Kubernetes 集群，先來思考一下，容器網(wǎng)絡(luò)除了讓集群正常運(yùn)行，能讓安裝 Kubernetes 后 Pending 的 CoreDNS running 起來以外還有哪些使用場景？

這里我通過一張圖總結(jié)了七個(gè)主要使用的場景，應(yīng)該也涵蓋大部分運(yùn)維人員網(wǎng)絡(luò)需求。

• 固定 IP。對(duì)于現(xiàn)存虛擬化 / 裸機(jī)業(yè)務(wù) / 單體應(yīng)用遷移到容器環(huán)境后，都是通過 IP 而非域名進(jìn)行服務(wù)間調(diào)用，此時(shí)就需要 CNI 插件有固定 IP 的功能，包括 Pod/Deployment/Statefulset。
• 網(wǎng)絡(luò)隔離。不同租戶或不同應(yīng)用之間，容器組應(yīng)該是不能互相調(diào)用或通信的。
• 多集群網(wǎng)絡(luò)互聯(lián)。 對(duì)于不同的 Kubernetes 集群之間的微服務(wù)進(jìn)行互相調(diào)用的場景，需要多集群網(wǎng)絡(luò)互聯(lián)。這種場景一般分為 IP 可達(dá)和 Service 互通，滿足不同的微服務(wù)實(shí)例互相調(diào)用需求。
• 出向限制。對(duì)于容器集群外的數(shù)據(jù)庫 / 中間件，需能控制特定屬性的容器應(yīng)用才可訪問，拒絕其他連接請(qǐng)求。
• 入向限制。限制集群外應(yīng)用對(duì)特定容器應(yīng)用的訪問。
• 帶寬限制。容器應(yīng)用之間的網(wǎng)絡(luò)訪問加以帶寬限制。
• 出口網(wǎng)關(guān)訪問。對(duì)于訪問集群外特定應(yīng)用的容器，設(shè)置出口網(wǎng)關(guān)對(duì)其進(jìn)行 SNAT 以達(dá)到統(tǒng)一出口訪問的審計(jì)和安全需求。 理完需求和應(yīng)用場景，我們來看看如何通過不同的 CNI 插件解決以上痛點(diǎn)。

網(wǎng)絡(luò)插件功能實(shí)現(xiàn)

固定 IP

基本上主流 CNI 插件都有自己的 IPAM 機(jī)制，都支持固定 IP 及 IP Pool 的分配，并且各個(gè) CNI 插件殊途同歸的都使用了 Annotation 的方式指定固定 IP。對(duì)于 Pod，分配固定 IP，對(duì)于 Deployment，使用 IP Pool 的方式分配。對(duì)于有狀態(tài)的 Statefulset，使用 IP Pool 分配后，會(huì)根據(jù) Pool 的分配順序記好 Pod 的 IP，以保證在 Pod 重啟后仍能拿到同樣的 IP。

Calico

??"cni.projectcalico.org/ipAddrs":?"[\"192.168.0.1\"]"

Kube-OVN

ovn.kubernetes.io/ip_address:?192.168.100.100
ovn.kubernetes.io/ip_pool:?192.168.100.201,192.168.100.202

Antrea

Antrea IPAM 只能在 Bridge 模式下使用，因此可以在 Multus 的輔佐下，主網(wǎng)卡使用 NodeIPAM 分配，副網(wǎng)卡使用 Antrea IPAM 分配 VLAN 類型網(wǎng)絡(luò)地址。

????ipam.antrea.io/ippools:?'pod-ip-pool1'
????ipam.antrea.io/pod-ips:?'<ip-in-pod-ip-pool1>'

Cilium

Not?Yet!

多集群網(wǎng)絡(luò)互聯(lián)

對(duì)于多集群網(wǎng)絡(luò)互聯(lián)，假設(shè)有現(xiàn)有多個(gè)集群，不同的微服務(wù)運(yùn)行在不同的集群中，集群 1 的 App01 需要和集群 2 的 App02 進(jìn)行通信，由于他們都是通過 IP 注冊(cè)在集群外的 VM 注冊(cè)中心的，所以 App01 和 App02 只能通過 IP 通信。在這種場景下，就需要多集群 Pod 互聯(lián)互通。

Calico

對(duì)于 Calico 這種原生對(duì) BGP 支持很好的 CNI 插件來說，很容易實(shí)現(xiàn)這一點(diǎn)，只要兩個(gè)集群通過 BGP 建立鄰居，將各自的路由宣告給對(duì)方即可實(shí)現(xiàn)動(dòng)態(tài)路由的建立。若存在多個(gè)集群，使用 BGP RR 的形式也很好解決。但這種解決方式可能不是最理想的，因?yàn)樾枰臀锢砭W(wǎng)絡(luò)環(huán)境進(jìn)行配合和聯(lián)調(diào)，這就需要網(wǎng)絡(luò)人員和容器運(yùn)維人員一同進(jìn)行多集群網(wǎng)絡(luò)的建設(shè)，在后期運(yùn)維和管理上都有不大方便和敏捷的感覺。

那 Calico VxLAN 模式呢？

既然說到 VxLAN，可以和 Kube-OVN、Antrea、Cilium 放到一起來看，四種 CNI 都支持 Overlay 的網(wǎng)絡(luò)模型，都支持通過 VxLAN/GENEVE 的形式建立隧道網(wǎng)絡(luò)打通容器網(wǎng)絡(luò)通信。這就賦予運(yùn)維人員較高的靈活性，對(duì)于容器網(wǎng)絡(luò)的調(diào)教、IPAM 分配、網(wǎng)絡(luò)監(jiān)控和可觀察性、網(wǎng)絡(luò)策略調(diào)整都由容器集群運(yùn)維人員負(fù)責(zé)，而網(wǎng)絡(luò)人員則只需要提前劃好物理網(wǎng)絡(luò)大段，保證容器集群 Node 之間網(wǎng)絡(luò)互通即可。

那如何去實(shí)現(xiàn) overlay 網(wǎng)絡(luò)的多集群互聯(lián)呢？

Submariner

CNCF 有個(gè)沙箱項(xiàng)目叫 Submariner，它通過在不同集群建立不同的網(wǎng)關(guān)節(jié)點(diǎn)并打通隧道的形式實(shí)現(xiàn)多集群通信。從官方這張架構(gòu)圖來說明：

簡單來說，Submariner 由一個(gè)集群元數(shù)據(jù)中介服務(wù)（broker）掌握不同集群的信息（Pod/Service CIDR），通過 Route Agent 將 Pod 流量從 Node 導(dǎo)向網(wǎng)關(guān)節(jié)點(diǎn)（Gateway Engine），然后由網(wǎng)關(guān)節(jié)點(diǎn)打通隧道丟到另一個(gè)集群中去，這個(gè)過程就和不同主機(jī)的容器之間使用 VxLAN 網(wǎng)絡(luò)通信的概念是一致的。 要達(dá)成集群連接也很簡單，在其中一個(gè)集群部署 Broker，然后通過 kubeconfig 或 context 分別進(jìn)行注冊(cè)即可。

????→?subctl?deploy-broker?--kubeconfig?~/.kube/config1
????→?subctl?join?--kubeconfig?~/.kube/config1?broker-info.subm?--clusterid?ks1?--natt=false?--cable-driver?vxlan?--health-check=false
????→?subctl?join?--kubeconfig?~/.kube/config2?broker-info.subm?--clusterid?ks2?--natt=false?--cable-driver?vxlan?--health-check=false
????→?subctl?show?all
??Showing?Endpoints
CLUSTER?ID????????????????????ENDPOINT?IP?????PUBLIC?IP???????CABLE?DRIVER????????TYPE
ks1???????????????????????????192.168.100.10??139.198.21.149??vxlan???????????????local
ks2???????????????????????????192.168.100.20??139.198.21.149??vxlan???????????????remote

Cilium

Cilium Cluster Mesh 和 Submariner 有異曲同工之妙，可以通過隧道形式或 NativeRoute 形式實(shí)現(xiàn)集群互聯(lián)。

Cilium 開啟多集群網(wǎng)絡(luò)連接也很簡單：

????→?cilium?clustermesh?enable?--context?$CLUSTER1
????→?cilium?clustermesh?enable?--context?$CLUSTER2

KubeOVN

Kube-OVN 還提供一個(gè) OVNIC 的組件，它運(yùn)行一個(gè)路由中繼的 OVN-IC 的 Docker 容器，作為兩個(gè)集群的網(wǎng)關(guān)節(jié)點(diǎn)，將不同集群的 Pod 網(wǎng)絡(luò)進(jìn)行連通。

多集群服務(wù)互訪

除了 Pod IP 的互聯(lián)互通，多集群網(wǎng)絡(luò)還可考慮集群間的 Service 互訪，Submariner、Cilium、Antrea 都能實(shí)現(xiàn)。Submariner 和 Antrea 都使用了 Kubernetes 社區(qū)的 MultiCluster Service 并在此之上結(jié)合自身組件實(shí)現(xiàn)多集群的服務(wù)訪問。MultiCluster Service 通過 ServiceExport 和 ServiceImport 的 CRD，ServiceExport 將需要公開的服務(wù)導(dǎo)出，然后通過 ServiceImport 將此服務(wù)導(dǎo)入到另一個(gè)集群。

Submariner

拿?Submariner^[6]?實(shí)現(xiàn)舉例，有兩個(gè)集群 ks1 和 ks2，ks1 在 test 命名空間有一個(gè)服務(wù) nginx，此時(shí)通過 ServiceExport 將 nginx 服務(wù)進(jìn)行導(dǎo)出，Submariner 會(huì)把這個(gè) nginx.test.svc.cluster.local?服務(wù)發(fā)現(xiàn)為 nginx.test.svc.clusterset.local，兩個(gè)集群的 coredns 都會(huì)建立一個(gè)新的 clusterset.local 的存根域，將所有匹配 cluster.set 的請(qǐng)求發(fā)送給 submariner 的服務(wù)發(fā)現(xiàn)的組件。同時(shí) ServiceImport 導(dǎo)入到 ks2 集群，ks2 集群的 Pod 就可以通過 nginx.test.svc.clusterset.local?解析到 ks1 集群的 nginx Service。如果兩個(gè)集群都有 nginx 的同名服務(wù)，此時(shí) submariner 就可以優(yōu)先本地進(jìn)行訪問，本地服務(wù)端點(diǎn)有故障后再訪問其他集群的 nginx 服務(wù)，是不是可以開始構(gòu)建雙活服務(wù)了哈哈。

Antrea

Antrea 實(shí)現(xiàn)方式類似，也是結(jié)合 ServiceExport 和 ServiceImport 并進(jìn)行封裝成 ResourceExport 和 ResourceImport 構(gòu)建多集群服務(wù)，在每個(gè)集群選擇一個(gè)節(jié)點(diǎn)作為網(wǎng)關(guān)，通過網(wǎng)關(guān)打通不同集群隧道來實(shí)現(xiàn)多集群服務(wù)的訪問。

Cilium

Cilium 沒有用 MultiService 的概念，Cilium 通過 Global Service 的概念構(gòu)建多集群訪問服務(wù)訪問。

從這張圖可以看出，Cilium 更適合做多活集群的多集群服務(wù)訪問需求，通過對(duì)相應(yīng)的服務(wù)添加 Annotation 的做法，把不同集群的服務(wù)設(shè)定為 global-service，并通過 shared-service 和 service-affinity 來控制服務(wù)是否能被其他集群訪問及服務(wù)親和性。以下是一個(gè)例子：

apiVersion:?v1
kind:?Service
metadata:
??name:?nginx
??annotations:
????io.cilium/global-service:?'true'
????io.cilium/shared-service:?'true'
????io.cilium/service-affinity:?'local'
????#?Possible?values:
????#?-?local
????#????preferred?endpoints?from?local?cluster?if?available
????#?-?remote
????#????preferred?endpoints?from?remote?cluster?if?available
????#?none?(default)
????#????no?preference.?Default?behavior?if?this?annotation?does?not?exist???
spec:
??type:?ClusterIP
??ports:
????-?port:?80
??selector:
????name:?nginx

以上，當(dāng)有多集群互訪需求又不想 CNI 強(qiáng)相關(guān)時(shí)，可以嘗試玩一下 Submariner，作為 CNCF Landscape Network 中一個(gè)專注于多集群互訪的 SandBox 項(xiàng)目，Submariner 提供多集群網(wǎng)絡(luò)通信，服務(wù)發(fā)現(xiàn)，以及安全加密，是一個(gè)很好的選擇。

網(wǎng)絡(luò)策略

對(duì)于 Pod 網(wǎng)絡(luò)隔離、入向限制、出向限制的網(wǎng)絡(luò)場景，可以整合成網(wǎng)絡(luò)策略一同來說。主流開源 CNI 都支持 Kubernetes NetworkPolicy，通過 Network Policy，可以在 3 層或 4 層做相應(yīng)的網(wǎng)絡(luò)安全限制。Network Policy 通過 Ingress 和 Egress 兩種進(jìn)行網(wǎng)絡(luò)限制，默認(rèn)都是放行的。也就是說，設(shè)置 Kubernetes 網(wǎng)絡(luò)策略，主要以白名單的形式對(duì)集群內(nèi)的流量進(jìn)行安全限制。

比如只允許指定 label 的 Pod 訪問集群外數(shù)據(jù)庫（通過 CIDR 指定）

apiVersion:?networking.K8s.io/v1
kind:?NetworkPolicy
metadata:
??name:?ingress-allow
??namespace:?default
spec:
??podSelector:?
????matchLabels:
??????role:?db
??policyTypes:
??-?Egress
egress:
????-?to:
????????-?ipBlock:
????????????cidr:?192.168.100.40/24
??????ports:
????????-?protocol:?TCP
??????????port:?3306

apiVersion:?networking.K8s.io/v1
kind:?NetworkPolicy
metadata:
??name:?ingress-allow
??namespace:?default
spec:
??podSelector:
????matchLabels:
??????role:?app
??policyTypes:
????-?Ingress
??ingress:
????-?from:
????????-?ipBlock:
????????????cidr:?172.17.0.0/16
????????????except:
??????????????-?172.17.1.0/24
????????-?namespaceSelector:
????????????matchLabels:
??????????????project:?web-project
????????-?podSelector:
????????????matchLabels:
??????????????role:?web

雖然 Network Policy 能滿足大多場景，但是不是感覺還是少了點(diǎn)東西？比如 7 層策略、基于 NodeSelector、Drop/Reject 類型的策略指定、指定 Egress 節(jié)點(diǎn)進(jìn)行控制等高級(jí)能力。這個(gè)時(shí)候 Cilium 和 Antrea 就大放異彩了。

Cilium

Cilium 有兩個(gè) CRD，CiliumNetworkPolicy 和 CiliumClusterwideNetworkPolicy，來實(shí)現(xiàn)單集群和多集群的網(wǎng)絡(luò)策略能力。Cilium 支持 3、4、7 層網(wǎng)絡(luò)策略。并增加 EndPoint Selector 和 Node Selector。除了普通的基于 PodSelector 和 CIDR 的限制，Cilium 可以支持更多種策略，比如：

DNS 限制策略，只允許 app: test-app 的端點(diǎn)通過 53 端口去 kube-system 命名空間的 "K8s:K8s-app": kube-dns 標(biāo)簽的 DNS 服務(wù)器訪問 my-remote-service.com：

apiVersion:?"cilium.io/v2"
kind:?CiliumNetworkPolicy
metadata:
??name:?"to-fqdn"
spec:
??endpointSelector:
????matchLabels:
??????app:?test-app
??egress:
????-?toEndpoints:
??????-?matchLabels:
??????????"K8s:io.kubernetes.pod.namespace":?kube-system
??????????"K8s:K8s-app":?kube-dns
??????toPorts:
????????-?ports:
???????????-?port:?"53"
?????????????protocol:?ANY
??????????rules:
????????????dns:
??????????????-?matchPattern:?"*"
????-?toFQDNs:
????????-?matchName:?"my-remote-service.com"

Http 限制策略 , 只允許 org: empire 標(biāo)簽的端點(diǎn)對(duì) deathstar 的 /v1/request-landing 進(jìn)行 POST 操作：

apiVersion:?"cilium.io/v2"
kind:?CiliumNetworkPolicy
metadata:
??name:?"rule"
spec:
??description:?"L7?policy?to?restrict?access?to?specific?HTTP?call"
??endpointSelector:
????matchLabels:
??????org:?empire
??????class:?deathstar
??ingress:
??-?fromEndpoints:
????-?matchLabels:
????????org:?empire
????toPorts:
????-?ports:
??????-?port:?"80"
????????protocol:?TCP
??????rules:
????????http:
????????-?method:?"POST"
??????????path:?"/v1/request-landing"

kafka 策略控制：

apiVersion:?"cilium.io/v2"
kind:?CiliumNetworkPolicy
metadata:
??name:?"rule1"
spec:
??description:?"enable?empire-hq?to?produce?to?empire-announce?and?deathstar-plans"
??endpointSelector:
????matchLabels:
??????app:?kafka
??ingress:
??-?fromEndpoints:
????-?matchLabels:
????????app:?empire-hq
????toPorts:
????-?ports:
??????-?port:?"9092"
????????protocol:?TCP
??????rules:
????????kafka:
????????-?role:?"produce"
??????????topic:?"deathstar-plans"
????????-?role:?"produce"
??????????topic:?"empire-announce"

Antrea

Antrea 除了增加現(xiàn)有 NetworkPolicy 功能外，抽象了 Antrea NetworkPolicy 和 Antrea ClusterNetworkPolicy 兩個(gè) CRD 實(shí)現(xiàn)命名空間級(jí)別和集群級(jí)別的安全管理。，還提供了 Group，Tier 的概念，用于資源分組和優(yōu)先級(jí)設(shè)計(jì)，嗯，果真是 NSX 的親兄弟。因此 Antrea 有零信任的網(wǎng)絡(luò)策略安全防護(hù)手段，可以實(shí)現(xiàn)嚴(yán)格的 pod 和命名空間隔離。

網(wǎng)絡(luò)層 Antrea 增加了對(duì) ICMP 和 IGMP，Mutlicast 的限制，禁 ping 人員狂喜。

apiVersion:?crd.antrea.io/v1alpha1
kind:?ClusterNetworkPolicy
metadata:
??name:?acnp-reject-ping-request
spec:
????priority:?5
????tier:?securityops
????appliedTo:
??????-?podSelector:
??????????matchLabels:
????????????role:?server
????????namespaceSelector:
??????????matchLabels:
????????????env:?prod
????egress:
??????-?action:?Reject
????????protocols:
??????????-?icmp:
??????????????icmpType:?8
??????????????icmpCode:?0
????????name:?DropPingRequest
????????enableLogging:?true

基于 FQDN 的過濾：

apiVersion:?crd.antrea.io/v1alpha1
kind:?ClusterNetworkPolicy
metadata:
??name:?acnp-fqdn-all-foobar
spec:
??priority:?1
??appliedTo:
??-?podSelector:
??????matchLabels:
????????app:?client
??egress:
??-?action:?Allow
????to:
??????-?fqdn:?"*foobar.com"
????ports:
??????-?protocol:?TCP
????????port:?8080
??-?action:?Drop?

設(shè)置不同類型的 Group，基于 Group 設(shè)置網(wǎng)絡(luò)策略，就不用對(duì)同類業(yè)務(wù)寫一堆 Label 了

apiVersion:?crd.antrea.io/v1alpha3
kind:?Group
metadata:
??name:?test-grp-with-namespace
spec:
??podSelector:
????matchLabels:
??????role:?db
??namespaceSelector:
????matchLabels:
??????env:?prod
---
#?Group?that?selects?IP?block?10.0.10.0/24.
apiVersion:?crd.antrea.io/v1alpha3
kind:?Group
metadata:
??name:?test-grp-ip-block
spec:
??ipBlocks:
????-?cidr:?10.0.10.0/24
---
apiVersion:?crd.antrea.io/v1alpha3
kind:?Group
metadata:
??name:?test-grp-svc-ref
spec:
??serviceReference:
????name:?test-service
????namespace:?default
---
#?Group?that?includes?the?previous?Groups?as?childGroups.
apiVersion:?crd.antrea.io/v1alpha3
kind:?Group
metadata:
??name:?test-grp-nested
spec:
??childGroups:?[test-grp-sel,?test-grp-ip-blocks,?test-grp-svc-ref]

Egress

對(duì)于特定業(yè)務(wù)出集群需不暴露 IP 或符合安全審計(jì)需求的場景，需要 Pod IP -> External IP 對(duì)外部業(yè)務(wù)進(jìn)行訪問。Cilium，Kube-OVN，Antrea 都有類似 Egress Gateway/Egress IP 的功能，特定標(biāo)簽的 Pod 通過 SNAT 為 Egress IP 訪問集群外服務(wù)。

Cilium

apiVersion:?cilium.io/v2
kind:?CiliumEgressGatewayPolicy
metadata:
??name:?egress-sample
spec:
??selectors:
??-?podSelector:
??????matchLabels:
????????app:?snat-pod
????????io.kubernetes.pod.namespace:?default
??destinationCIDRs:
??-?"0.0.0.0/0"
??egressGateway:
????nodeSelector:
??????matchLabels:
????????node.kubernetes.io/name:?node1
????egressIP:?10.168.60.100

KubeOVN

apiVersion:?v1
kind:?Pod
metadata:
??name:?pod-gw
??annotations:
????ovn.kubernetes.io/eip:?172.10.0.1
????#或ovn.kubernetes.io/snat:?172.10.0.1
spec:
??containers:
??-?name:?eip-pod
????image:?nginx:alpine

Antrea:

apiVersion:?crd.antrea.io/v1alpha2
kind:?Egress
metadata:
??name:?egress-staging-web
spec:
??appliedTo:
????namespaceSelector:
??????matchLabels:
????????kubernetes.io/metadata.name:?staging
????podSelector:
??????matchLabels:
????????app:?web
??externalIPPool:?external-ip-pool
??#或IP形式?egressIP:?10.10.10.1

帶寬管理

kube-ovn 和 Clium 都支持帶寬管理，kube-ovn 還支持 QoS 調(diào)整，只需要 Annotation 一下即可搞定：

Kube-OVN

apiVersion:?v1
kind:?Pod
metadata:
??name:?qos
??namespace:?ls1
??annotations:
????ovn.kubernetes.io/ingress_rate:?"3"
????ovn.kubernetes.io/egress_rate:?"1"
????ovn.kubernetes.io/latency:?3
????ovn.kubernetes.io/loss:?20

Cilium

apiVersion:?v1
kind:?Pod
metadata:
??annotations:
????kubernetes.io/egress-bandwidth:?10M
...

以上。就是此次分享的全部內(nèi)容了，讀到這里你可以也會(huì)感慨，從最早學(xué) Docker，Vethpair 熟悉容器網(wǎng)絡(luò)原理，到搭建 K8s 后節(jié)點(diǎn) NotReady 就 apply 個(gè) Flannel 逐步了解 CNI 插件機(jī)制，到今天的 CNCF Network&Service Proxy 生態(tài)的花團(tuán)錦簇，云原生網(wǎng)絡(luò)在日新月異的發(fā)展著，容器網(wǎng)絡(luò)從最初的連通性到現(xiàn)在演變出更多的玩法和適用性，不論是網(wǎng)絡(luò)功能、安全控制、網(wǎng)絡(luò)洞察和可觀測性，都在更好地為運(yùn)維人員服務(wù)。若要體驗(yàn)更多功能，快到開源社區(qū)選擇喜歡的容器網(wǎng)絡(luò)項(xiàng)目 Hands on Lab 吧！