Kubernetes CNI 插件選型和應用場景探討-有解無憂

作者：馬偉，青云科技容器顧問，云原生愛好者，目前專注于云原生技術，云原生領域技術堆疊涉及 Kubernetes、KubeSphere、KubeKey 等，

本文介紹容器環境常見網路應用場景及對應場景的 Kubernetes CNI 插件功能實作，幫助搭建和使用云原生環境的小伙伴快速選擇心儀的網路工具，

常見網路插件

我們在學習容器網路的時候，肯定都聽說過 Docker 的 bridge 網路，Vethpair，VxLAN 等術語，從 Docker 到 kubernetes 后，學習了 Flannel、Calico 等主流網路插件，分別代表了 Overlay 和 Underlay 的兩種網路傳輸模式，也是很經典的兩款 CNI 網路插件，那么，還有哪些好用的 CNI 插件呢 ? 我們看看 CNCF Landscape:

拋去商業版 CNI，此次分享來聊聊幾款熱門開源 CNI 插件，分別為 Kube-OVN、Antrea、Cilium，Kube-OVN 和 Antrea 都是基于 OpenvSwitch 的專案，Cilium 使用 eBPF 這款革命性的技術作為資料路徑，亦是這兩年很火熱的一個開源容器專案，

那么，又回到學習新產品的第一步，如何快速部署 K8s 體驗不同地 CNI 插件呢？還是交給我們親愛的 Kubekey 吧，

Kubekey 作為一個開源的 Kubernetes 和 KubeSphere 集群部署工具，可以輕松的部署 Kubernetes 集群，提供節點管理、作業系統安全加固、容器運行時管理、網路存盤安裝、Etcd 管理等，Kubekey 支持一鍵部署 Calico / Flannel / Cilium / Kube-OVN 等網路插件，只需在 kk 的組態檔中注明 network 的 plugin 值即可：

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

對于 antrea，由于版本較新，目前可通過 addon 的形式添加 helm 檔案的形式進行一鍵安裝：

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

在此基礎上，可以通過以下一條命令

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

創建一個 kubernetes 集群并安裝 KubeSphere，在此之上體驗不同的 CNI 在 Kubernetes 的功能應用，畢竟，哪個運維人員不喜歡頁面友好的容器管理平臺呢？

網路應用場景

現在我們已經有了一個 Kubernetes 集群，先來思考一下，容器網路除了讓集群正常運行，能讓安裝 Kubernetes 后 Pending 的 CoreDNS running 起來（抖個雞靈-_-）以外還有哪些使用場景？

這里我通過一張圖總結了七個主要使用的場景，應該也涵蓋大部分運維人員網路需求，

固定 IP，對于現存虛擬化 / 裸機業務 / 單體應用遷移到容器環境后，都是通過 IP 而非域名進行服務間呼叫，此時就需要 CNI 插件有固定 IP 的功能，包括 Pod/Deployment/Statefulset，
網路隔離，不同租戶或不同應用之間，容器組應該是不能互相呼叫或通信的，
多集群網路互聯，對于不同的 Kubernetes 集群之間的微服務進行互相呼叫的場景，需要多集群網路互聯，這種場景一般分為 IP 可達和 Service 互通，滿足不同的微服務實體互相呼叫需求，
出向限制，對于容器集群外的資料庫 / 中間件，需能控制特定屬性的容器應用才可訪問，拒絕其他連接請求，
入向限制，限制集群外應用對特定容器應用的訪問，
帶寬限制，容器應用之間的網路訪問加以帶寬限制，
出口網關訪問，對于訪問集群外特定應用的容器，設定出口網關對其進行 SNAT 以達到統一出口訪問的審計和安全需求，
理完需求和應用場景，我們來看看如何通過不同的 CNI 插件解決以上痛點，

網路插件功能實作

固定 IP

基本上主流 CNI 插件都有自己的 IPAM 機制，都支持固定 IP 及 IP Pool 的分配，并且各個 CNI 插件殊途同歸的都使用了 Annotation 的方式指定固定 IP，對于 Pod，分配固定 IP，對于 Deployment，使用 IP Pool 的方式分配，對于有狀態的 Statefulset，使用 IP Pool 分配后，會根據 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 的輔佐下，主網卡使用 NodeIPAM 分配，副網卡使用 Antrea IPAM 分配 VLAN 型別網路地址，

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

Cilium

Not Yet!

多集群網路互聯

對于多集群網路互聯，假設有現有多個集群，不同的微服務運行在不同的集群中，集群 1 的 App01 需要和集群 2 的 App02 進行通信，由于他們都是通過 IP 注冊在集群外的 VM 注冊中心的，所以 App01 和 App02 只能通過 IP 通信，在這種場景下，就需要多集群 Pod 互聯互通，

Calico

對于 Calico 這種原生對 BGP 支持很好的 CNI 插件來說，很容易實作這一點，只要兩個集群通過 BGP 建立鄰居，將各自的路由宣告給對方即可實作動態路由的建立，若存在多個集群，使用 BGP RR 的形式也很好解決，但這種解決方式可能不是最理想的，因為需要和物理網路環境進行配合和聯調，這就需要網路人員和容器運維人員一同進行多集群網路的建設，在后期運維和管理上都有不大方便和敏捷的感覺，

那 Calico VxLAN 模式呢？

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

那如何去實作 overlay 網路的多集群互聯呢？

Submariner

CNCF 有個沙箱專案叫 Submariner，它通過在不同集群建立不同的網關節點并打通隧道的形式實作多集群通信，從官方這張架構圖來說明：

簡單來說，Submariner 由一個集群元資料中介服務（broker）掌握不同集群的資訊（Pod/Service CIDR），通過 Route Agent 將 Pod 流量從 Node 導向網關節點（Gateway Engine），然后由網關節點打通隧道丟到另一個集群中去，這個程序就和不同主機的容器之間使用 VxLAN 網路通信的概念是一致的，
要達成集群連接也很簡單，在其中一個集群部署 Broker，然后通過 kubeconfig 或 context 分別進行注冊即可，

??  → 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 形式實作集群互聯，

Cilium 開啟多集群網路連接也很簡單：

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

KubeOVN

Kube-OVN 還提供一個 OVNIC 的組件，它運行一個路由中繼的 OVN-IC 的 Docker 容器，作為兩個集群的網關節點，將不同集群的 Pod 網路進行連通，

多集群服務互訪

除了 Pod IP 的互聯互通，多集群網路還可考慮集群間的 Service 互訪，Submariner、Cilium，Antrea 都能實作，Submariner 和 Antrea 都使用了 Kubernetes 社區的 MultiCluster Service 并在此之上結合自身組件實作多集群的服務訪問，MultiCluster Service 通過 ServiceExport 和 ServiceImport 的 CRD，ServiceExport 將需要公開的服務匯出，然后通過 ServiceImport 將此服務匯入到另一個集群，

Submariner

拿 Submariner 實作舉例，有兩個集群 ks1 和 ks2，ks1 在 test 命名空間有一個服務 nginx，此時通過 ServiceExport 將 nginx 服務進行匯出，Submariner 會把這個 nginx.test.svc.cluster.local 服務發現為 nginx.test.svc.clusterset.local，兩個集群的 coredns 都會建立一個新的 clusterset.local 的存根域，將所有匹配 cluster.set 的請求發送給 submariner 的服務發現的組件，同時 ServiceImport 匯入到 ks2 集群，ks2 集群的 Pod 就可以通過 nginx.test.svc.clusterset.local 決議到 ks1 集群的 nginx Service，如果兩個集群都有 nginx 的同名服務，此時 submariner 就可以優先本地進行訪問，本地服務端點有故障后再訪問其他集群的 nginx 服務，是不是可以開始構建雙活服務了哈哈，

Antrea

Antrea 實作方式類似，也是結合 ServiceExport 和 ServiceImport 并進行封裝成 ResourceExport 和 ResourceImport 構建多集群服務，在每個集群選擇一個節點作為網關，通過網關打通不同集群隧道來實作多集群服務的訪問，

Cilium

Cilium 沒有用 MultiService 的概念，Cilium 通過 Global Service 的概念構建多集群訪問服務訪問，

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

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

以上，當有多集群互訪需求又不想 CNI 強相關時，可以嘗試玩一下 Submariner，作為 CNCF Landscape Network 中一個專注于多集群互訪的 SandBox 專案，Submariner 提供多集群網路通信，服務發現，以及安全加密，是一個很好的選擇，

網路策略

對于 Pod 網路隔離、入向限制、出向限制的網路場景，可以整合成網路策略一同來說，主流開源 CNI 都支持 Kubernetes NetworkPolicy，通過 Network Policy，可以在 3 層或 4 層做相應的網路安全限制，Network Policy 通過 Ingress 和 Egress 兩種進行網路限制，默認都是放行的，也就是說，設定 Kubernetes 網路策略，主要以白名單的形式對集群內的流量進行安全限制，

比如只允許指定 label 的 Pod 訪問集群外資料庫（通過 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 能滿足大多場景，但是不是感徑訓是少了點東西？比如 7 層策略、基于 NodeSelector、Drop/Reject 型別的策略指定、指定 Egress 節點進行控制等高級能力，這個時候 Cilium 和 Antrea 就大放異彩了，

Cilium

Cilium 有兩個 CRD，CiliumNetworkPolicy 和 CiliumClusterwideNetworkPolicy，來實作單集群和多集群的網路策略能力，Cilium 支持 3、4、7 層網路策略，并增加 EndPoint Selector 和 Node Selector，除了普通的基于 PodSelector 和 CIDR 的限制，Cilium 可以支持更多種策略，比如：

DNS 限制策略，只允許 app: test-app 的端點通過 53 埠去 kube-system 命名空間的 "K8s:K8s-app": kube-dns 標簽的 DNS 服務器訪問 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 標簽的端點對 deathstar 的 /v1/request-landing 進行 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 除了增加現有 NetworkPolicy 功能外，抽象了 Antrea NetworkPolicy 和 Antrea ClusterNetworkPolicy 兩個 CRD 實作命名空間級別和集群級別的安全管理，，還提供了 Group，Tier 的概念，用于資源分組和優先級設計，嗯，果真是 NSX 的親兄弟，因此 Antrea 有零信任的網路策略安全防護手段，可以實作嚴格的 pod 和命名空間隔離，

網路層 Antrea 增加了對 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

設定不同型別的 Group，基于 Group 設定網路策略，就不用對同類業務寫一堆 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

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

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 調整，只需要 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
...

以上，就是此次分享的全部內容了，讀到這里你可以也會感慨，從最早學 docker0，Vethpair 熟悉容器網路原理，到搭建 K8s 后節點 NotReady 就 apply 個 Flannel 逐步了解 CNI 插件機制，到今天的 CNCF Network&Service Proxy 生態的花團錦簇，云原生網路在日新月異的發展著，容器網路從最初的連通性到現在演變出更多的玩法和適用性，不論是網路功能、安全控制、網路洞察和可觀測性，都在更好地為運維人員服務，若要體驗更多功能，快到開源社區選擇喜歡的容器網路專案 Hands on Lab 吧！

本文由博客一文多發平臺 OpenWrite 發布！

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/531464.html

標籤：其他

上一篇：UE代碼重構方法

下一篇：華為云API中心：匯聚千行百業API資產，打造API全生命周期極致體驗