今天很高興可以和大家分享我們普元雲平臺SEM使用kubernetes時，關於pod、service網路通訊的實踐與大家分享。

以下為今天講的主要內容：

首先來看一下我們普元雲的總體架構圖

SEM –Software Enviroment Mgmt 向上承接業務需求，向下進行資源管理和排程。

SEM 後端對接的是容器，不是虛擬化技術。

SEM 後端選擇容器技術，為了適應上層應用的快速多變的需求，這也是容器特點之一。

SEM 後端是以Flannel+Kubernetes為核心。(選擇Flannel+Kubernetes 是兩者結合的比較好，之前大神宋瀟男也已經說明過。 )

容器的經典網路圖，網路使用bridge方式來。

在docker 1.9之前主支援none/host/bridge/container四種網路模型。而在docker 1.9版本後實現了原本實驗性的Networking元件的支援，可以在Swarm中使用它或者將其作為Compose 工具。建立虛擬網路並將其連線到容器實現多個主機上容器相互通訊。(kernel版本需要在3.19之上)

Kubernetes 不提供二層網路。二層網路是通過 Overlay Network來實現的。主要的flannel、openvswitch和weave等。這三種技術各有各的不同，且在部署過程中的難易度也有不同，效能上也差別。

普元雲平臺使用 flannel+kubernetes

Weave 主要是通過在宿主機上部署一個route的容器。 route攔截所有普通容器的ip請求，來實現容器間的網路通訊。

Flannel 是CoreOS團隊開發的網路工具，flannel使用etcd進行配置，這樣就可以保證多個flannel例項之間的配置一致性。

Flannel會為不同node的docker網橋配置不同IP段以保證docker容器的IP在叢集內唯一。因此flannel會重新配置docker0網橋。

Flannel已經支援UDP、VxLAN、AWS VPC和GCE路由等資料轉發模式。

Flannel是普元雲平臺網路實現技術，之前的微課程已經說明了。

Openvswitch 是通過SDN contrallor來實現。這是與weave和flannel的不同。

使用openvswitch需要提前進行ip段的規化，這是與flannel不同，openvswitch部署相較與weave和flannel有難度。

Kubernetes把Pod定義為最小管理單位，Pod是一個邏輯單位。Kubernetes通過PodIP實現容器網路變得靈活簡單。Flannel負責二層網路管理，為容器分配地址還是docker0來完成。

Kubernetes提供PodIP為Pod與Pod，Pod與worker node的網路處於同一層面。

Kubernetes為每個Pod都附屬了gcr.io/google_containers/pause:latest，這個容器只接管Pod的網路資訊，業務容器通過加入網路容器的網路來實現網路共享。此容器隨著pod建立而建立，隨著Pod刪除而刪除，正如其名字“pause”

由於Pod IP使用了overlay network，如圖在叢集內Pod1､Pod3, Pod3, Pod4, work node1和work ndoe2之間的通訊。

在kubernetes叢集中Node/Pod/Service的網路是扁平的網路。

Service在Pod之間起到服務代理的作用，對外表現為單一介面，將請求轉發給Pod，Service的網路轉發是kubernetes實現服務編排的關鍵一環。

在userspace機制，kubernetes proxy會為每一個service在主機上啟用隨機埠進行監聽，建立iptables規則進行重定向。這個機制下kubernetes proxy是反向代理的作用。

在iptables機制下，kubernetes proxy則是完全通過建立iptable規則，直接重定向Service IP的請求到Endpoints，如果endpoints發生變化，kubernetes proxy負責重新整理iptables規則。Kubernetes proxy只負責管理Service和endpoints，以及更新iptables規則。

Pod IP 帶來的好處，通過overlay network網路實現Pod滾動更新，也可以算是恢度釋出。

傳統進行容器更新的時候，通常都是先停止v1版本的容器，然後在執行v2版本的容器。更新過程中Pod所在的應用來會出現。

正是通過Pod IP， 使得kubernetes在進行rolling Deployment更新應用在kubernetes中是先建立新版本v2然後在刪除v1版本實現Pod應用更新。

普元公眾號：