有一個問題就是現在我的業務配置設定在多個Pod上，那麼如果我某個Pod死掉豈不是業務完蛋了，當然也會有人說Pod死掉沒問題啊，K8S自身機制Deployment和Controller會動态的建立和銷毀Pod來保證應用的整體穩定性，那這時候還會有問題，那就是每個Pod産生的IP都是動态的，那是以說重新啟動了我對外通路的IP豈不是要變了，别急，下面我們來解決下這個問題。
可以通過Service來解決如上所遇到的問題，那麼什麼是Service呢？
Service是kubernetes最核心的概念，通過建立Service，可以為一組具有相同功能的容器應用提供一個統一的入口位址，并且将請求進行負載分發到後端的各個容器應用上。
簡單來說Service就是一個把所有Pod都池化的一個組，然後對外統一固定一個IP，具體是哪些Pod可以通過之前介紹到的Label标簽來進行設定。
在建立Service之前先看看我們在部署應用的時候建立的nginx.yml
剛在有提到，就是說哪些Pod被Service池化是根據Label标簽來的，那麼可以看到圖上所辨別的nginx字樣，後面我們建立Service會用到。
下面來建立個Service看看
解釋下這個yml檔案哈，其意思就是說呢V1是api的版本，然後Kind表示目前資源類型為Service，selector選擇之前Label标簽為nginx的Pod作為Service池化的對象，最後說的是把Service的8080端口映射到Pod的80端口。
執行kubectl apply建立Servie nginx-svc
| 1 | kubcetl apply –f nginx-svc.yml |
建立完成之後nginx-svc會配置設定到一個cluster-ip，可以通過該ip通路後端nginx業務。
建立完之後可以檢視service詳情檢視後端都包含哪些pod
| kubectl describe service nginx-svc |
那它是怎麼實作的呢？答案是通過iptables實作的位址轉換和端口轉換，可以用iptables-save檢視。
那這時候有人說了，還是不能外網通路啊，别急下面我們來進行外網位址通路設定。在實際生産環境中，對Service的通路可能會有兩種來源：Kubernetes叢集内部的程式（Pod）和Kubernetes叢集外部，為了滿足上述的場景，Kubernetes service有以下三種類型：
1.ClusterIP：提供一個叢集内部的虛拟IP（與Pod不在同一網段)，以供叢集内部的pod之間通信使用。
2.NodePort：在每個Node上打開一個随機端口并且每個Node的端口都是一樣的，通過<NodeIP>:NodePort的方式Kubernetes叢集外部的程式可以通路Service。
3.LoadBalancer：利用Cloud Provider特有的Load Balancer對外提供服務，Cloud Provider負責将Load Balancer的流量導向Service。
本篇文章我們着重講下第二種方式，也就是NodePort方式，修改nginx-svc.yml檔案，也就是剛才前面建立的Service檔案，相信細心的同學會發現在之前截圖的時候已經做好了NodePort，因為我的環境已經配置好了是以這樣就不在截圖了，配置很簡單，可以網上看下截圖，就是添加一個type：NodePort，然後重新建立下nginx-svc，指令的話和建立的指令一樣，我們來看看建立完事的結果。
如果剛開始你沒有設定NodePort這個type的時候在端口那隻會顯示一個8080端口，而設定了之後會看到多了一個端口也就是31337，那8080大家鬥志是cluster-ip監聽的端口，那31337就是在節點上新起的一個端口，Kubernetes會從30000~32767中配置設定一個可用的端口，每個節點都會監聽這個端口，并轉發給Service，也就是防止說一個節點挂了影響通路。可能有人會問了，說這裡的Service可不可以固定？當時可以了，可以在Service nginx-svc.yml檔案裡面添加一個nodeport。
最後我們可以驗證下，我這裡就不截圖了，太長了。
curl x.x.x.x:31337
那OK可能會有人說這個通路是随機的還是負載均衡的？答案是負載均衡的，依舊是采用iptables實作的，感興趣的可以自己研究下iptables裡面做的那些規則，這裡就不再贅述了。
初級玩家的話，使用系統性，點點滑鼠即可操作的容器也是棒棒哒~
華為雲容器引擎，一個點點滑鼠就可以完成容器建立的應用服務！美滋滋~
目前，華為雲容器引擎推出容器體驗館，7天免費！歡迎體驗哦~
https://www.huaweicloud.com/product/cce.html