Kubernetes中的PodIP、ClusterIP和外部IP
Kubernetes是Google開源的容器集群管理系統，是Docker容器的主要集群管理系統之一。
其中，Kubernetes中管理主要有三種類型的IP:Pod IP 、Cluster IP 和 外部IP。
Pod IP
Kubernetes的最小部署單元是Pod。利用Flannel作為不同HOST之間容器互通技術時，由Flannel和etcd維護了一張節點間的路由表。Flannel的設計目的就是為集群中的所有節點重新規劃IP地址的使用規則，從而使得不同節點上的容器能夠獲得“同屬一個內網”且”不重復的”IP地址，並讓屬於不同節點上的容器能夠直接通過內網IP通信。
每個Pod啟動時，會自動創建一個鏡像為gcr.io/google_containers/pause:0.8.0的容器，容器內部與外部的通信經由此容器代理，該容器的IP也可以稱為Pod IP。
Cluster IP
Pod IP 地址是實際存在於某個網卡(可以是虛擬設備)上的，但Service Cluster IP就不一樣了，沒有網絡設備為這個地址負責。它是由kube-proxy使用Iptables規則重新定向到其本地端口，再均衡到後端Pod的。
Pod IP 地址是實際存在於某個網卡(可以是虛擬設備)上的，但Service Cluster IP就不一樣了，沒有網絡設備為這個地址負責。它是由kube-proxy使用Iptables規則重新定向到其本地端口，再均衡到後端Pod的。
就拿上面我們提到的圖像處理程序為例。當我們的Service被創建時，Kubernetes給它分配一個地址10.0.0.1。這個地址從我們啟動API的service-cluster-ip-range參數(舊版本為portal_net參數)指定的地址池中分配，比如–service-cluster-ip-range=10.0.0.0/16。假設這個Service的端口是1234。集群內的所有kube-proxy都會註意到這個Service。當proxy發現一個新的service後，它會在本地節點打開一個任意端口，建相應的iptables規則，重定向服務的IP和port到這個新建的端口，開始接受到達這個服務的連接。
當一個客戶端訪問這個service時，這些iptable規則就開始起作用，客戶端的流量被重定向到kube-proxy為這個service打開的端口上，kube-proxy隨機選擇一個後端pod來服務客戶。這個流程如下圖所示：
根據Kubernetes的網絡模型，使用Service Cluster IP和Port訪問Service的客戶端可以坐落在任意代理節點上。外部要訪問Service，我們就需要給Service外部訪問IP。
外部IP
Service對象在Cluster IP range池中分配到的IP只能在內部訪問，如果服務作為一個應用程序內部的層次，還是很合適的。如果這個Service作為前端服務，準備為集群外的客戶提供業務，我們就需要給這個服務提供公共IP了。
外部訪問者是訪問集群代理節點的訪問者。為這些訪問者提供服務，我們可以在定義Service時指定其spec.publicIPs，一般情況下publicIP 是代理節點的物理IP地址。和先前的Cluster IP range上分配到的虛擬的IP一樣，kube-proxy同樣會為這些publicIP提供Iptables 重定向規則，把流量轉發到後端的Pod上。有了publicIP，我們就可以使用load balancer等常用的互聯網技術來組織外部對服務的訪問了。
spec.publicIPs在新的版本中標記為過時了，代替它的是spec.type=NodePort，這個類型的service，系統會給它在集群的各個代理節點上分配一個節點級別的端口，能訪問到代理節點的客戶端都能訪問這個端口，從而訪問到服務。
Kubernetes中的PodIP、ClusterIP和外部IP