[[275296]]

名詞解釋

1、網絡的命名空間：Linux在網絡棧中引入網絡命名空間，將獨立的網絡協議棧隔離到不同的命令空間中，彼此間無法通信;docker利用這一特性，實現不容器間的網絡隔離。

2、Veth設備對：也叫虛擬網絡接口對。Veth設備對的引入是為了實現在不同網絡命名空間的通信。

3、Iptables/Netfilter：Netfilter負責在內核中執行各種掛接的規則(過濾、修改、丟棄等)，運行在內核 模式中;Iptables模式是在用戶模式下運行的進程，負責協助維護內核中Netfilter的各種規則表;通過二者的配合來實現整個Linux網絡協議棧中靈活的數據包處理機制。

4、網橋：網橋是一個二層網絡設備,通過網橋可以將linux支持的不同的端口連接起來,并實現類似交換機那樣的多對多的通信。

5、路由：Linux系統包含一個完整的路由功能，當IP層在處理數據發送或轉發的時候，會使用路由表來決定發往哪里。

令人頭大的網絡模型

Kubernetes對集群內部的網絡進行了重新抽象，以實現整個集群網絡扁平化。我們可以理解網絡模型時，可以完全抽離物理節點去理解，我們用圖說話，先有基本印象。

 

其中，重點講解以下幾個關鍵抽象概念。

一個Service

Service是Kubernetes為為屏蔽這些后端實例(Pod)的動態變化和對多實例的負載均衡而引入的資源對象。Service通常與deployment綁定，定義了服務的訪問入口地址，應用(Pod)可以通過這個入口地址訪問其背后的一組由Pod副本組成的集群實例。Service與其后端Pod副本集群之間則是通過Label Selector來實現映射。

Service的類型(Type)決定了Service如何對外提供服務，根據類型不同，服務可以只在Kubernetes cluster中可見，也可以暴露到集群外部。Service有三種類型，ClusterIP，NodePort和LoadBalancer。具體的使用場景會在下文中進行闡述。

在測試環境查看：

$ kubectl get svc --selector app=nginx 
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE 
nginx ClusterIP 172.19.0.166 <none> 80/TCP 1m 
$ kubectl describe svc nginx 
Name: nginx 
Namespace: default 
Labels: app=nginx 
Annotations: <none> 
Selector: app=nginx 
Type: ClusterIP 
IP: 172.19.0.166 
Port: <unset> 80/TCP 
TargetPort: 80/TCP 
Endpoints: 172.16.2.125:80,172.16.2.229:80 
Session Affinity: None 
Events: <none> 

上述信息中該svc后端代理了2個Pod實例:172.16.2.125:80,172.16.2.229:80

二個IP

Kubernetes為描述其網絡模型的IP對象，抽象出Cluster IP和Pod IP的概念。

PodIP是Kubernetes集群中每個Pod的IP地址。它是Docker Engine 根據docker0網橋的IP地址段進行分配的，是一個虛擬的二層網絡。Kubernetes中Pod間能夠彼此直接通訊，Pod里的容器訪問另外一個Pod里的容器，是通過Pod IP所在進行通信。

Cluster IP僅作用于Service，其沒有實體對象所對應，因此Cluster IP無法被ping通。它的作用是為Service后端的實例提供統一的訪問入口。當訪問ClusterIP時，請求將被轉發到后端的實例上，默認是輪詢方式。Cluster IP和Service一樣由kube-proxy組件維護，其實現方式主要有兩種，iptables和IPVS。在1.8版本后kubeproxy開始支持IPVS方式。在上例中，SVC的信息中包含了Cluster IP。

這里未列出nodeip概念，由于其本身是物理機的網卡IP。因此可理解為nodeip就是物理機IP。

三個Port

在Kubernetes中，涉及容器，Pod，Service，集群各等多個層級的對象間的通信，為在網絡模型中區分各層級的通信端口，這里對Port進行了抽象。

Port

該Port非一般意義上的TCP/IP中的Port概念，它是特指Kubernetes中Service的port，是Service間的訪問端口，例如Mysql的Service默認3306端口。它僅對進群內容器提供訪問權限，而無法從集群外部通過該端口訪問服務。

nodePort

nodePort為外部機器提供了訪問集群內服務的方式。比如一個Web應用需要被其他用戶訪問，那么需要配置type=NodePort，而且配置nodePort=30001，那么其他機器就可以通過瀏覽器訪問scheme://node:30001訪問到該服務，例如http://node:30001。

targetPort

targetPort是容器的端口(最根本的端口入口)，與制作容器時暴露的端口一致(DockerFile中EXPOSE)，例如docker.io官方的nginx暴露的是80端口。

舉一個例子來看如何配置Service的port：

kind: Service 
apiVersion: v1 
metadata: 
 name: mallh5-service 
 namespace: abcdocker 
spec: 
 selector: 
 app: mallh5web 
 type: NodePort 
 ports: 
 - protocol: TCP 
 port: 3017 
 targetPort: 5003 
 nodePort: 31122 

這里舉出了一個service的yaml，其部署在abcdocker的namespace中。這里配置了nodePort，因此其類型Type就是NodePort，注意大小寫。若沒有配置nodePort，那這里需要填寫ClusterIP，即表示只支持集群內部服務訪問。

集群內部通信

單節點通信

集群單節點內的通信，主要包括兩種情況，同一個pod內的多容器間通信以及同一節點不同pod間的通信。由于不涉及跨節點訪問，因此流量不會經過物理網卡進行轉發。

通過查看路由表，也能窺見一二：

root@node-1:/opt/bin# route -n 
Kernel IP routing table 
Destination Gateway Genmask Flags Metric Ref Use Iface 
0.0.0.0 172.23.100.1 0.0.0.0 UG 0 0 0 eth0 
10.1.0.0 0.0.0.0 255.255.0.0 U 0 0 0 flannel.1 #flannel 網絡內跨節點的通信會交給 flannel.1 處理 
10.1.1.0 0.0.0.0 255.255.255.0 U 0 0 0 docker0 #flannel 網絡內節點內的通信會走 docker0 

1 Pod內通信

如下圖所示：

 

 

這種情況下，同一個pod內共享網絡命名空間，容器之間通過訪問127.0.0.1:(端口)即可。圖中的veth*即指veth對的一端(另一端未標注，但實際上是成對出現)，該veth對是由Docker Daemon掛載在docker0網橋上，另一端添加到容器所屬的網絡命名空間，圖上顯示是容器中的eth0。

圖中演示了bridge模式下的容器間通信。docker1向docker2發送請求，docker1，docker2均與docker0建立了veth對進行通訊。

當請求經過docker0時，由于容器和docker0同屬于一個子網，因此請求經過docker2與docker0的veth*對，轉發到docker2，該過程并未跨節點，因此不經過eth0。

2 Pod間通信

同節點pod間通信

由于Pod內共享網絡命名空間(由pause容器創建)，所以本質上也是同節點容器間的通信。同時，同一Node中Pod的默認路由都是docker0的地址，由于它們關聯在同一個docker0網橋上，地址網段相同，所有它們之間應當是能直接通信的。來看看實際上這一過程如何實現。如上圖，Pod1中容器1和容器2共享網絡命名空間，因此對pod外的請求通過pod1和Docker0網橋的veth對(圖中掛在eth0和ethx上)實現。

 

 

訪問另一個pod內的容器，其請求的地址是PodIP而非容器的ip，實際上也是同一個子網間通信，直接經過veth對轉發即可。

跨節點通信

CNI：容器網絡接口

CNI 是一種標準，它旨在為容器平臺提供網絡的標準化。不同的容器平臺(比如目前的 kubernetes、mesos 和 rkt)能夠通過相同的接口調用不同的網絡組件。

目前kubernetes支持的CNI組件種類很多，例如：bridge calico calico-ipam dhcp flannel host-local ipvlan loopback macvlan portmap ptp sample tuning vlan。在docker中，主流的跨主機通信方案主要有一下幾種：

1)基于隧道的overlay網絡：按隧道類型來說，不同的公司或者組織有不同的實現方案。docker原生的overlay網絡就是基于vxlan隧道實現的。ovn則需要通過geneve或者stt隧道來實現的。flannel最新版本也開始默認基于vxlan實現overlay網絡。

2)基于包封裝的overlay網絡：基于UDP封裝等數據包包裝方式，在docker集群上實現跨主機網絡。典型實現方案有weave、flannel的早期版本。

3)基于三層實現SDN網絡：基于三層協議和路由，直接在三層上實現跨主機網絡，并且通過iptables實現網絡的安全隔離。典型的方案為Project Calico。同時對不支持三層路由的環境，Project Calico還提供了基于IPIP封裝的跨主機網絡實現

通信方式

 

 

集群內跨節點通信涉及到不同的子網間通信，僅靠docker0無法實現，這里需要借助CNI網絡插件來實現。圖中展示了使用flannel實現跨節點通信的方式。

簡單說來，flannel的用戶態進程flanneld會為每個node節點創建一個flannel.1的網橋，根據etcd或apiserver的全局統一的集群信息為每個node分配全局唯一的網段，避免地址沖突。同時會為docker0和flannel.1創建veth對，docker0將報文丟給flannel.1,。

Flanneld維護了一份全局node的網絡表，通過flannel.1接收到請求后，根據node表，將請求二次封裝為UDP包，扔給eth0，由eth0出口進入物理網路發送給目的node。

在另一端以相反的流程。Flanneld解包并發往docker0，進而發往目的Pod中的容器。

外部訪問集群

從集群外訪問集群有多種方式，比如loadbalancer，Ingress，nodeport，nodeport和loadbalancer是service的兩個基本類型，是將service直接對外暴露的方式，ingress則是提供了七層負載均衡，其基本原理將外部流量轉發到內部的service，再轉發到后端endpoints，在平時的使用中，我們可以依據具體的業務需求選用不同的方式。這里主要介紹nodeport和ingress方式。

Nodeport

通過將Service的類型設置為NodePort，就可以在Cluster中的主機上通過一個指定端口暴露服務。注意通過Cluster中每臺主機上的該指定端口都可以訪問到該服務，發送到該主機端口的請求會被kubernetes路由到提供服務的Pod上。采用這種服務類型，可以在kubernetes cluster網絡外通過主機IP：端口的方式訪問到服務。

這里給出一個influxdb的例子，我們也可以針對這個模板去修改成其他的類型：

kind: Service 
apiVersion: v1 
metadata: 
 name: influxdb 
spec: 
 type: NodePort 
 ports: 
 - port: 8086 
 nodePort: 31112 
 selector: 
 name: influxdb 

Ingress

Ingress是推薦在生產環境使用的方式，它起到了七層負載均衡器和Http方向代理的作用，可以根據不同的url把入口流量分發到不同的后端Service。外部客戶端只看到foo.bar.com這個服務器，屏蔽了內部多個Service的實現方式。采用這種方式，簡化了客戶端的訪問，并增加了后端實現和部署的靈活性，可以在不影響客戶端的情況下對后端的服務部署進行調整。

其部署的yaml可以參考如下模板：

apiVersion: extensions/v1beta1 
kind: Ingress 
metadata: 
 name: test 
 annotations: 
 ingress.kubernetes.io/rewrite-target: / 
spec: 
 rules: 
 - host: test.name.com 
 http: 
 paths: 
 - path: /test 
 backend: 
 serviceName: service-1 
 servicePort: 8118 
 - path: /name 
 backend: 
 serviceName: service-2 
 servicePort: 8228 

這里我們定義了一個ingress模板，定義通過test.name.com來訪問服務，在虛擬主機test.name.com下面定義了兩個Path，其中/test被分發到后端服務s1，/name被分發到后端服務s2。

集群中可以定義多個ingress，來完成不同服務的轉發，這里需要一個ingress controller來管理集群中的Ingress規則。Ingress Contronler 通過與 Kubernetes API 交互，動態的去感知集群中 Ingress 規則變化，然后讀取它，按照自定義的規則，規則就是寫明了哪個域名對應哪個service，生成一段 Nginx 配置，再寫到 Nginx-ingress-control的 Pod 里，這個 Ingress Contronler 的pod里面運行著一個nginx服務，控制器會把生成的nginx配置寫入/etc/nginx.conf文件中，然后 reload使用配置生效。

Kubernetes提供的Ingress Controller模板如下：

apiVersion: extensions/v1beta1 
kind: Ingress 
metadata: 
 name: test 
 annotations: 
 ingress.kubernetes.io/rewrite-target: / 
spec: 
 rules: 
 - host: foo.bar.com 
 http: 
 paths: 
 - path: /foo 
 backend: 
 serviceName: s1 
 servicePort: 80 
 - path: /bar 
 backend: 
 serviceName: s2 
 servicePort: 80 

總結及展望

本文針對kubernetes的網絡模型，從一個service，二個IP，三個port出發進行圖解。詳解kubernetes集群內及集群外部訪問方式。