直接訪問Pod的問題

Pod創建完成后，如何訪問Pod呢？直接訪問Pod會有如下幾個問題：

• Pod會隨時被Deployment這樣的控制器刪除重建，那訪問Pod的結果就會變得不可預知。
• Pod的IP地址是在Pod啟動后才被分配，在啟動前并不知道Pod的IP地址。
• 應用往往都是由多個運行相同鏡像的一組Pod組成，逐個訪問Pod也變得不現實。

舉個例子，假設有這樣一個應用程序，使用Deployment創建了前臺和后臺，前臺會調用后臺做一些計算處理。后臺運行了3個Pod，這些Pod是相互獨立且可被替換的，當Pod出現狀況被重建時，新建的Pod的IP地址是新IP，前臺的Pod無法直接感知。

圖 Pod間訪問

使用Service解決Pod的訪問問題

Kubernetes中的Service對象就是用來解決上述Pod訪問問題的。Service有一個固定IP地址（在創建CCE集群時有一個服務網段的設置，這個網段專門用于給Service分配IP地址），Service將訪問它的流量轉發給Pod，具體轉發給哪些Pod通過Label來選擇，而且Service可以給這些Pod做負載均衡。

那么對于上面的例子，為后臺添加一個Service，通過Service來訪問Pod，這樣前臺Pod就無需感知后臺Pod的變化。

圖 通過Service訪問Pod

Service的類型

Kubernetes允許指定一個需要的類型的Service，類型的取值以及行為如下：

• 集群內訪問(ClusterIP)

集群內訪問表示工作負載暴露給同一集群內其他工作負載訪問的方式，可以通過“集群內部域名”訪問。

• 節點訪問(NodePort)

節點訪問( NodePort )是指在每個節點的IP上開放一個靜態端口，通過靜態端口對外暴露服務。節點訪問 ( NodePort )會路由到ClusterIP服務，這個ClusterIP服務會自動創建。通過請求:NodeIP:NodePort，可以從集群的外部訪問一個NodePort服務。

• 負載均衡(LoadBalancer)

負載均衡( LoadBalancer )可以通過彈性負載均衡從公網訪問到工作負載，與彈性IP方式相比提供了高可靠的保障，一般用于系統中需要暴露到公網的服務。