在介紹Service這個api資源對象時，我們已經匯總過Service的幾種類型：ClusterIP、NodePort、LoadeBalancer，其實除了這三個外還有其它的類型，在本章節我們暫且不去討論。

這三種類型的Service，LoadBalancer依賴NodePort，而NodePort通常要和ClusterIP一起使用，如果在Service的yaml文件里定義type為LoadBalancer，則它會自動創建NodePort，而NodePort也會自動創建ClusterIP。

下面，再來演繹一下從Pod到Service的網絡變化情況：

1）單個Pod之間通信

單個Pod和Pod之間通信只能通過Pod的IP和Port來通信，如下圖

沒有多余的描述，只要知道對方Pod的IP以及服務的端口，直接去訪問就行了，簡單粗暴！

2）Pod有多個

當引入Deployment，并為Pod設置多個副本時，那么提供某一個服務（如Nginx服務）的Pod就不止一個了，此時即使知道了這些Pod的IP，那訪問起來也并不方便。所以，這里需要有一個統一入口，其它Pod通過這個統一入口去請求該服務（Nginx）對應的所有Pod。這時就有了Service這個資源對象，它主要作用就是用來提供統一入口，也就是說只需要一個IP就能訪問所有的Pod，而這個入口IP就是ClusterIP，也就是Service的IP。

3）外部資源訪問內部Pod

有了Service，的確可以很方便為內部的Pod提供入口，但是在集群外面訪問這個內部的資源就沒辦法了。于是，就有了這個NodePort，使用Service的NodePort類型，可以將Service的ClusterIP對應的Port映射到每一個Node的IP上，映射出去的Port范圍為30000~32767

4）借助公有云的負載均衡器

使用這個NodePort并不方便，畢竟它帶著一個長長的端口號，而且還有一個非常尷尬的問題，就是訪問時還得帶著Node的IP，如果這個Node掛掉，那么就無法訪問此資源，雖然可以通過另外一個Node去訪問，但這樣太麻煩在！所以，此時的解決方案是：借助三方的負載均衡器，將請求分發到所有的Node上，其底層還是NodePort。

總結：Service為內部Pod的統一入口，內部資源之間可以通過最簡單的ClusterIP進行通信，而外部資源訪問需要借助NodePort的形式，但是帶著長長端口不方便，于是又衍生了LoadBalancer的形式，這種形式需要借助三方的負載均衡器，將請求分發到每一個NodePort上。





審核編輯：劉清