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

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

下面，再來演繹一下從Pod到Service的網(wǎng)絡(luò)變化情況：

1）單個(gè)Pod之間通信

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

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

2）Pod有多個(gè)

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

3）外部資源訪問內(nèi)部Pod

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

4）借助公有云的負(fù)載均衡器

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

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





審核編輯：劉清