Kubernetes網絡分析-Container間通信

本文假設你已經搭建好了kubernetes叢集，那麼請求是如何到達pod，然後被container處理的。都是幹貨。

上圖顯示了kubernetes的基本結構圖。

最重要的是最後一句話：一個pod内的container共享同樣的網絡位址空間。這是通過mapped container做到的。

基本描述為下：

2.1 共享網絡模式

下面是一個例子來驗證，我這裡建立了一個busybox的pod。

我們去192.168.1.226看下這個pod和其container.

發現有兩個容器，一個是pause容器，一個是busybox容器。其中pause容器為主網絡容器，其他容器都共享pause容器的網絡模式。我們分别看下其網絡模式。下面是兩個容器的網絡模式。

是以可以看到fc8580292210(busybox)使用的是pause容器的網絡空間。

讓我們進一步驗證。

2.2 ip位址和hostname、網絡io

下面我在 192.168.1.224 搭建了一個dns的pod，裡面有4個容器，共享一個網絡空間，我們采用檢視其ip位址、hostname和網絡io的方式來鑒定。 下面是容器的id号

我們檢視前三個 b00a08d078d6 4e843585b938 296ff779abb2的上述屬性。

2.2.1 dns設定和hostname

2.2.2 ip位址

2.2.3 網絡連接配接io

下面分析下最複雜的container之間的通信。

3.1 pod 之内 container 通信

先說最簡單的, pod内的container通信，由于共享網絡位址空間，直接通路127.0.0.1即可。

3.2 跨機器之間contianer通信

3.2.1 背景引導

例子： 192.168.1.224的fluentd-elasticsearch容器要連接配接192.168.1.223的elasticsearch-logging容器。

那麼這個過程是如何完成的呢？？？

3.2.2 container間通信流程

192.168.1.224/fluentd-elasticsearch -> 192.168.1.223/elasticsearch-logging

192.168.1.224/fluentd-elasticsearch 需要連接配接到elasticsearch-logging容器.

kubernetes的container之間的通信最為複雜。下面是一個小結：

首先需要一個可用的跨機器的容器間網絡請求，我這裡是flannel，最終的container間通信是通過flannel達成的。

kubernetes讓在一個pod的一組container共享一個網絡空間，進而讓關聯密切的container之間的通信變得十分容易。

如果要通路kubernetes叢集的其他服務，則需要經過主控端的iptables的nat規則，請求會發給kube-proxy，kube-proxy知道所有的服務的endpoints，并且知道服務請求是由哪些pod來處理(而這通過label selector完成)。

kube-proxy選擇出相應的pod，并且把請求發送給他們處理，而這個pod的位址是 172.16.x.x 也就是docker0網橋橋接的位址，也就是說這時候交給flannel這一層進行處理(如果跨機器的話)或者直接交給本機處理(不跨機器)。