本文是從 0 到 1 使用 Kubernetes 系列第七篇，上一篇《從 0 到 1 使用 Kubernetes 系列（六）：資料持久化實戰》介紹了 Kubernetes 中的幾種常用儲存型別，本文將介紹 K8S 網路相關的內容，

不同宿主機上運行的容器并不能通過 IP 相互訪問，那么 Kubernetes 是如何實作不同節點上 Pod 的互通？Pod 有生命周期，它的 IP 會隨著動態的創建和銷毀而動態變化，Kubernetes 又是怎樣對外提供穩定的服務？今天就為大家一一解答這些疑問，

Docker 網路

先來看一下 Docker 中的網路，在啟動 Docker 服務后，默認會創建一個 docker0 網橋（其上有一個 docker0 內部介面），它在內核層連通了其他的物理或虛擬網卡，這就將所有容器和本地主機都放到同一個物理網路，

Docker 默認指定了 docker0 介面的 IP 地址和子網掩碼，讓主機和容器之間可以通過網橋相互通信，它還給出了 MTU（介面允許接收的最大傳輸單元），通常是 1500 Bytes，或宿主主機網路路由上支持的默認值，這些值都可以在服務啟動的時候進行配置，

root@ubuntu:/root# ifconfig
...
docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 0.0.0.0
        ether 02:42:d2:00:10:6c  txqueuelen 0  (Ethernet)
...
root@ubuntu:/root# docker inspect busybox
···
"IPAddress": "172.17.0.2",
···

為了實作上述功能，Docker 主要用到了 linux 的 Bridge 、Network Namespace 、VETH，

Bridge 相當于是一個虛擬網橋，作業在第二層網路，也可以為它配置 IP，作業在三層網路，docker0 網關就是通過 Bridge 實作的，
Network Namespace 是網路命名空間，通過 Network Namespace 可以建立一些完全隔離的網路堆疊，比如通過 docker network create xxx 就是在建立一個 Network Namespace
VETH 是虛擬網卡的介面對，可以把兩端分別接在兩個不同的 Network Namespace 中，實作兩個原本隔離的 Network Namespace 的通信，

所以總結起來就是：Network Namespace 做了容器和宿主機的網路隔離，Bridge 分別在容器和宿主機建立一個網關，然后再用 VETH 將容器和宿主機兩個網路空間連接起來，但這都是在同一個主機上的網路實作，如果想要在多臺主機上進行網路就得看看下面介紹的 Kubernetes 網路，

Kubernetes 網路

Kubernetes 為了解決容器的“跨主通信”問題，提出了很多解決方案，常見思路有兩種：

直接在宿主機上建立不同宿主機上子網的路由規則；
通過特殊的網路設備封裝二層資料幀，根據目標 IP 地址匹配到對應的子網找到對應的宿主機 IP 地址，最后將轉發 IP 包，目的宿主機上同樣的特殊網路設備完成解封并根據本機路由表轉發，

Flannel

大家所熟知的 Flannel 專案是 CoreOS 公司推出的容器網路解決方案，它本身只是一個框架，為開發者提供容器網路功能的是 Flannel 的后端實作，目前有如下三種具體實作：

UDP
VXLAN
host-gw

下面的三層網路指的是七層網路模型中的底部的三層：網路層、資料鏈路層和物理層，

UDP 模式是最早支持，性能最差，但最容易理解和實作的容器跨主網路方案，Flannel UDP 模式提供的是一個三層的覆寫網路：首先對發出端的 IP 包進行 UDP 封裝，然后在接受端進行解封拿到原始的 IP 包，進而把這個包轉發給目標容器，它相當于在兩個容器之間打通一條“隧道”，使得兩個容器可以直接使用 IP 通信，而不關心容器和宿主機的分布情況，

Flannel UDP 模式原理圖

因為 Flannel 進行 UDP 封裝和解封都是在用戶態完成，而在 Linux 系統中背景關系切換和用戶態操作的代價非常大，這就是它性能不好的主要原因，

VXLAN 即 Virtual Extensible LAN（虛擬可擴展局域網），是 Linux 內核本身就支持的一種網路虛擬化技術，VXLAN 在內核態就完成了上面的封裝和解封作業，通過與 UDP 模式類似的“隧道”機制，構建出覆寫網路（Overlay Network），使得連接在這個 VXLAN 二層網路的“主機”可以像在局域網自由通信，

Flannel VXLAN 模式原理圖

host-gw 模式的作業原理是將每一個 Flannel 子網的下一跳設定為該子網對應的宿主機 IP 地址，

也就是說，這臺“主機”（host）會充當這條容器通信路徑里的“網關”（Getway），_Flannel host-gw 模式必須要求集群宿主機之間是二層連通的_，

Flannel host-gw 示意圖

Calico

Calico 專案提供的網路解決方案與 Flannel Host-gw 模式同理，但是不同于 Flannel 通過 Etcd 和宿主機的 flanneld 來維護路由資訊得做法，Calio 專案使用 BGP（邊界網關協議）來自動的在整個集群中分發路由訊息，它由三部分組成：

Calico 的 CNI 插件：這是 Calico 與 Kubernetes 對接的部分， Felix：它是一個 DaemonSet，負責在宿主機插入路由規則，以及維護 Calico 所需的網路設備等， BIRD：它是 BGP 的客戶端，負責在集群里分發路由規則資訊，

除了對路由資訊的維護方式之外，Calico 專案和 Flannel 的 host-gw 另一個不同是它不會在宿主機上創建任何網橋設備，

Calico 作業原理圖

CNI（容器網路介面）

CNI）是 CNCF 旗下的一個專案，由一組用于配置 Linux 容器的網路介面的規范和庫組成，同時還包含了一些插件，CNI 僅關心容器創建時的網路分配，和當容器被洗掉時釋放網路資源，其基本思想為： Kubernetes 在啟動 Infra 容器之后，就可以直接呼叫 CNI 網路插件，為這個 Infra 容器的 Network Namespace 配置符合預期的網路堆疊，

Kubernetes 使用 CNI 介面，維護一個單獨的網橋來代替 docker0，這個網橋就叫做 CNI 網橋，它在宿主機上的默認名稱是：cni0，以 Flannel 的 VXLAN 模式為例，在 Kubernetes 環境里，它的作業方式沒有變化，只是 docker0 網橋替換成了 CNI 網橋，CNI 網橋只是接管所有 CNI 插件負責的，即 Kuberntes 創建的容器（Pod），

Flannel vxlan cni 版

Service

Kubernetes 中 Pod 有生命周期，它的 IP 會隨著動態的創建和銷毀而動態變化，不能穩定的提供服務，Kubernetes Service 定義這樣一種抽象：一個 Pod 的邏輯分組，一種可以訪問它們的策略，開發者可以通過一個 Service 的入口地址訪問其背后的一組 Pod，一旦 Service 被創建，Kubernetes 就會自動為它分配一個可用的 Cluster IP，在 Service 的整個生命周期中它的 Cluster IP 都不會發生改變，這樣就解決了分布式集群的服務發現，

一個典型的 Service 定義如下：

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  selector:
    app: nginx
  ports:
    - nmae: dafault
      protocol: TCP
      port: 8000
      targetPort: 80

在這個 Service 例子中，筆者使用 selector 欄位宣告這個 Service 只代理 app=nginx 標簽的 pod，這個 Service 的 8000 埠代理 Pod 的 80 埠，

然后定義應用 Delpoyment 如下：

apiVersion: v1
kind: Delpoyment
metadata:
  name: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 3
  template:
    meatdata:
    lalels:
      app: nginx
    spec:
    containers:
      - name: nginx
        image: nginx
        ports:
          - containers: 80
            protocol: TCP

被 selector 選中的 Pod，就被稱為 Serivce 的 Endpoints，你可以使用 kubectl get ep 查看它們，如下所示：

$ kubectl get endpoints nginx
NAME    ENDPOINTS                                      AGE
nginx   172.20.1.16:80,172.20.2.22:80,172.20.2.23:80   1m

通過該 Service 的 VIP 10.68.57.93 地址，就可以訪問到它所代理的 Pod：

$ kubectl get svc nginx
NAME    TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE
nginx   ClusterIP   10.68.57.93   <none>        80/TCP    1m

$ curl 10.68.57.93
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
......
<h1>Welcome to nginx!</h1>
......
</html>

這個 VIP 地址是 Kubernetes 自動為 Service 分配的，訪問 Service 的 VIP 地址和代理的 80 埠，它就為我們回傳了默認的 nginx 頁面，這種方式稱為：Cluster IP 模式的 Service，

集群外訪問 Service

Servcie 的訪問資訊在 kubernates 集群外無效，因為所謂的 Service 的訪問介面，實際上是每臺宿主機上由 kube-proxy 生成的 iptables 規則，以及 kube-dns 生成的 DNS 記錄，

解決外部訪問 Kubernetes 集群里創建的 servcie 有以下幾種方法：

NodePort
LoadBalancer

NodePort 方法

下面是 NodePort 的例子：

apiVersion: v1
kind: Service
metadata:
  name: my-nginx
  labels:
    run: my-nginx
spec:
  type: NodePort
  ports:
    - name: http
      nodePort: 30080
      port: 8080
      targetPort: 80
      protocol: TCP

在這個 Service 定義中，宣告它的型別為 type=NodePort，此時在 ports 欄位中宣告了 Service 的 8080 埠代理 Pod 的 80 埠，

如果你不顯示宣告 nodePort 欄位，Kubernetes 會為你隨機分配可用埠來設定代理，這個埠的范圍默認為：30000-32767，這里設定為 30080，

這里就可以如此訪問這個 service：

<任何一臺宿主機 IP 地址>:30080

LoadBalancer

這種方法適用于公有云上的 Kubernetes 服務，通過指定一個 LoadBalancer 型別的 Service 實作，

apiVersion: v1
kind: Service
metadata:
  name: example-service
spec:
  ports:
    - port: 8765
      targetPort: 9379
  selector:
    app: example
  type: LoadBalancer

創建 Service 時，你可以選擇自動創建云網路負載均衡器，這提供了一個外部可訪問的 IP 地址，只要您的群集在受支持的云環境中運行，就可以將流量發送到群集節點上的正確埠，

Ingress

為代理不同后端 Service 而設定的路由規則集合就是 Kubernetes 里的 Ingress，

舉一個例子，這里有一個訂閱系統，它的域名是：https://wwww.example.com ，其中 http://www.example.com/book 是訂書系統，https://www.example.com/food 是訂餐系統，這兩個系統分別由 book 和 food 兩個 Deployment 來提供服務，

apiVersion: v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  tls:
    - hosts:
        - www.example.com
      secretName: example-secret
  rules:
    - host: www.example.com
      http:
        paths:
          - path: book
            backend:
              serviceName: book-svc
              servicePort: 80
          - path: /food
            backend:
              serviceName: food-svc
              servicePort: 80

這個 yaml 檔案值得關注的 rules 欄位，它叫作：IngressRules，

IngressRule 的 Key 就是 host，它必須是一個標準域名格式的字串，不能是 IP 地址，

host 欄位定義的值就是 Ingress 的入口，也就是說當用戶訪問 www.example.com 的時候，實際上訪問到的是這個 Ingress 物件，Kubernetes 就能根據 IngressRule 進行下一步轉發，這里定義兩個 path，它們分別對應 book 和 food 這個兩個 Deployment 的 Service，

由此不難看出，Ingress 物件其實就是 Kubernetes 專案對“反向代理”的一種抽象，

總結

今天這篇文主要介紹了 Kubernetes 集群實作容器跨主機通信的幾種方式的原理，并且介紹了如何使用 Service 對外界提供服務，

本文由豬齒魚技術團隊原創，轉載請注明出處

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

標籤：其他

上一篇：k8s之mutating webhook + gin（附加除錯技巧）

下一篇：2021第六屆數維杯A題新冠肺炎背景下的港口資源配置優化策略

從0到1使用Kubernetes系列（七）：網路