深入玩轉K8S之外網如何訪問業務應用

PaaS小魔仙發表於2018-07-04
K8S
有一個問題就是現在我的業務分配在多個Pod上，那麼如果我某個Pod死掉豈不是業務完蛋了，當然也會有人說Pod死掉沒問題啊，K8S自身機制Deployment和Controller會動態的建立和銷燬Pod來保證應用的整體穩定性，那這時候還會有問題，那就是每個Pod產生的IP都是動態的，那所以說重新啟動了我對外訪問的IP豈不是要變了，別急，下面我們來解決下這個問題。
可以通過Service來解決如上所遇到的問題，那麼什麼是Service呢？

Service是kubernetes最核心的概念，通過建立Service，可以為一組具有相同功能的容器應用提供一個統一的入口地址，並且將請求進行負載分發到後端的各個容器應用上。


簡單來說Service就是一個把所有Pod都池化的一個組，然後對外統一固定一個IP，具體是哪些Pod可以通過之前介紹到的Label標籤來進行設定。
在建立Service之前先看看我們在部署應用的時候建立的nginx.yml
1.png

剛在有提到，就是說哪些Pod被Service池化是根據Label標籤來的，那麼可以看到圖上所標識的nginx字樣，後面我們建立Service會用到。

下面來建立個Service看看
2.png

解釋下這個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
1 kubectl describe service nginx-svc
3.png

那它是怎麼實現的呢？答案是通過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，命令的話和建立的命令一樣，我們來看看建立完事的結果。
4.png

如果剛開始你沒有設定NodePort這個type的時候在埠那隻會顯示一個8080埠，而設定了之後會看到多了一個埠也就是31337，那8080大家鬥志是cluster-ip監聽的埠，那31337就是在節點上新起的一個埠，Kubernetes會從30000~32767中分配一個可用的埠，每個節點都會監聽這個埠，並轉發給Service，也就是防止說一個節點掛了影響訪問。可能有人會問了，說這裡的Service可不可以固定？當時可以了，可以在Service nginx-svc.yml檔案裡面新增一個nodeport。

5.png

最後我們可以驗證下，我這裡就不截圖了，太長了。

curl x.x.x.x:31337

那OK可能會有人說這個訪問是隨機的還是負載均衡的？答案是負載均衡的，依舊是採用iptables實現的，感興趣的可以自己研究下iptables裡面做的那些規則，這裡就不再贅述了。

本文轉自DockOne-深入玩轉K8S之外網如何訪問業務應用


相關文章