Kubernetes的三種外部訪問方式:NodePort、LoadBalancer和Ingress(轉發)

原文 http://cloud.51cto.com/art/201804/570386.htm前端

Kubernetes的三種外部訪問方式:NodePort、LoadBalancer和Ingress

最近有些同窗問我 NodePort,LoadBalancer 和 Ingress 之間的區別。它們都是將集羣外部流量導入到集羣內的方式,只是實現方式不一樣。讓咱們看一下它們分別是如何工做的,以及你該如何選擇它們。node

做者:池劍鋒 譯來源: Docker| 2018-04-12 13:35

技術沙龍 | 4月21日多位區塊鏈專家進行區塊鏈技術應用場景解讀!

 

最近有些同窗問我 NodePort,LoadBalancer 和 Ingress 之間的區別。它們都是將集羣外部流量導入到集羣內的方式,只是實現方式不一樣。讓咱們看一下它們分別是如何工做的,以及你該如何選擇它們。git

注意:這裏說的每一點都基於Google Kubernetes Engine。若是你用 minikube 或其它工具,以預置型模式(om prem)運行在其它雲上,對應的操做可能有點區別。我不會太深刻技術細節,若是你有興趣瞭解更多,官方文檔[1]是一個很是棒的資源。github

ClusterIPsql

ClusterIP 服務是 Kubernetes 的默認服務。它給你一個集羣內的服務,集羣內的其它應用均可以訪問該服務。集羣外部沒法訪問它。後端

ClusterIP 服務的 YAML 文件相似以下:api

  1. apiVersion: v1 
  2. kind: Service 
  3. metadata:   
  4.   name: my-internal-service 
  5. selector:     
  6.   app: my-app 
  7. spec: 
  8.   type: ClusterIP 
  9.   ports:   
  10.   - name: http 
  11.     port: 80 
  12.     targetPort: 80 
  13.     protocol: TCP 

若是 從Internet 無法訪問 ClusterIP 服務,那麼咱們爲何要討論它呢?那是由於咱們能夠經過 Kubernetes 的 proxy 模式來訪問該服務!app

啓動 Kubernetes proxy 模式:負載均衡

  1. $ kubectl proxy --port=8080 

這樣你能夠經過Kubernetes API,使用以下模式來訪問這個服務:dom

  1. http://localhost:8080/api/v1/proxy/namespaces/<NAMESPACE>/services/<SERVICE-NAME>:<PORT-NAME>/ 

要訪問咱們上面定義的服務,你可使用以下地址:

  1. http://localhost:8080/api/v1/proxy/namespaces/default/services/my-internal-service:http/ 

什麼時候使用這種方式?

有一些場景下,你得使用 Kubernetes 的 proxy 模式來訪問你的服務:

  • 因爲某些緣由,你須要調試你的服務,或者須要直接經過筆記本電腦去訪問它們。
  • 允許內部通訊,展現內部儀表盤等。

這種方式要求咱們運行 kubectl 做爲一個未認證的用戶,所以咱們不能用這種方式把服務暴露到 internet 或者在生產環境使用。

NodePort

NodePort 服務是引導外部流量到你的服務的最原始方式。NodePort,正如這個名字所示,在全部節點(虛擬機)上開放一個特定端口,任何發送到該端口的流量都被轉發到對應服務。

NodePort 服務的 YAML 文件相似以下:

  1. apiVersion: v1 
  2. kind: Service 
  3. metadata:   
  4.   name: my-nodeport-service 
  5. selector:     
  6.   app: my-app 
  7. spec: 
  8.   type: NodePort 
  9.   ports:   
  10.   - name: http 
  11.     port: 80 
  12.     targetPort: 80 
  13.     nodePort: 30036 
  14.     protocol: TCP 

NodePort 服務主要有兩點區別於普通的「ClusterIP」服務。第一,它的類型是「NodePort」。有一個額外的端口,稱爲 nodePort,它指定節點上開放的端口值 。若是你不指定這個端口,系統將選擇一個隨機端口。大多數時候咱們應該讓 Kubernetes 來選擇端口,由於如評論中 thockin 所說,用戶本身來選擇可用端口代價太大。

什麼時候使用這種方式?

  1. 這種方法有許多缺點:
  2. 每一個端口只能是一種服務
  3. 端口範圍只能是 30000-32767

若是節點/VM 的 IP 地址發生變化,你須要能處理這種狀況

基於以上緣由,我不建議在生產環境上用這種方式暴露服務。若是你運行的服務不要求一直可用,或者對成本比較敏感,你可使用這種方法。這樣的應用的最佳例子是 demo 應用,或者某些臨時應用。

LoadBalancer

LoadBalancer 服務是暴露服務到 internet 的標準方式。在 GKE 上,這種方式會啓動一個 Network Load Balancer[2],它將給你一個單獨的 IP 地址,轉發全部流量到你的服務。

什麼時候使用這種方式?

若是你想要直接暴露服務,這就是默認方式。全部通往你指定的端口的流量都會被轉發到對應的服務。它沒有過濾條件,沒有路由等。這意味着你幾乎能夠發送任何種類的流量到該服務,像 HTTP,TCP,UDP,Websocket,gRPC 或其它任意種類。

這個方式的最大缺點是每個用 LoadBalancer 暴露的服務都會有它本身的 IP 地址,每一個用到的 LoadBalancer 都須要付費,這將是很是昂貴的。

Ingress

有別於以上全部例子,Ingress 事實上不是一種服務類型。相反,它處於多個服務的前端,扮演着「智能路由」或者集羣入口的角色。

你能夠用 Ingress 來作許多不一樣的事情,各類不一樣類型的 Ingress 控制器也有不一樣的能力。

GKE 上的默認 ingress 控制器是啓動一個 HTTP(S) Load Balancer[3]。它容許你基於路徑或者子域名來路由流量到後端服務。例如,你能夠將任何發往域名 foo.yourdomain.com 的流量轉到 foo 服務,將路徑 yourdomain.com/bar/path 的流量轉到 bar 服務。

GKE 上用 L7 HTTP Load Balancer[4]生成的 Ingress 對象的 YAML 文件相似以下:

  1. apiVersion: extensions/v1beta1 
  2. kind: Ingress 
  3. metadata: 
  4.   name: my-ingress 
  5. spec: 
  6.   backend: 
  7.     serviceName: other 
  8.     servicePort: 8080 
  9.   rules: 
  10.   - host: foo.mydomain.com 
  11.     http: 
  12.       paths: 
  13.       - backend: 
  14.           serviceName: foo 
  15.           servicePort: 8080 
  16.   - host: mydomain.com 
  17.     http: 
  18.       paths: 
  19.       - path: /bar/* 
  20.         backend: 
  21.           serviceName: bar 
  22.           servicePort: 8080 

什麼時候使用這種方式?

Ingress 多是暴露服務的最強大方式,但同時也是最複雜的。Ingress 控制器有各類類型,包括 Google Cloud Load Balancer, Nginx,Contour,Istio,等等。它還有各類插件,好比 cert-manager[5],它能夠爲你的服務自動提供 SSL 證書。

若是你想要使用同一個 IP 暴露多個服務,這些服務都是使用相同的七層協議(典型如 HTTP),那麼Ingress 就是最有用的。若是你使用本地的 GCP 集成,你只須要爲一個負載均衡器付費,且因爲 Ingress是「智能」的,你還能夠獲取各類開箱即用的特性(好比 SSL、認證、路由等等)。

相關連接:

https://kubernetes.io/docs/concepts/services-networking/service/

https://cloud.google.com/compute/docs/load-balancing/network/

https://cloud.google.com/compute/docs/load-balancing/http/

https://cloud.google.com/compute/docs/load-balancing/http/

https://github.com/jetstack/cert-manager

相關文章
相關標籤/搜索