前面幾篇文章學習瞭如何搭建K8S、如何部署應用、如何利用Label和DaemonSet來根據實際情況部署業務應用，這時候就有人問了，說都搭建完了那怎麼訪問我的業務應用啊，那麼本篇文章就來講述下如何訪問應用，同時還有一個問題就是現在我的業務分配在多個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
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裏面做的那些規則，這裏就不再贅述了。本文參考了Kubernetes 官網，後面章節我們來討論ingress負載均衡。