Kubernetes服務訪問-Nodeport、Loadbalancer和Ingress

本文翻譯自：https://medium.com/google-cloud/kubernetes-nodeport-vs-loadbalancer-vs-ingress-when-should-i-use-what-922f010849e0

最近，有人問我 NodePort，LoadBalancer 和 Ingress 之間的區別是什麼。 它們是將外部流量引入羣集的不一樣方式，而且實現方式不同。 咱們來看看它們是如何工做的，以及何時該用哪一種。

注意：本文適用於 Google Kubernetes Engine。 若是你在其餘公有云、混合雲、minikube 等上運行，可能會略有不一樣。 例如，您不能在 minikube 上使用 LoadBalancer。 我也沒有深刻技術細節。 若是您有興趣瞭解更多，官方文檔是一個很好的資源！

ClusterIP

ClusterIP 服務是默認的 Kubernetes 服務。 它爲您提供集羣內部其餘應用程序能夠訪問的服務， 外部沒法訪問。

ClusterIP 服務的 YAML 相似這樣：

apiVersion: v1
kind: Service
metadata:  
  name: my-internal-service
selector:    
  app: my-app
spec:
  type: ClusterIP
  ports:  
  - name: http
    port: 80
    targetPort: 80
    protocol: TCP

若是你不能從集羣外部上訪問一個 ClusterIP 服務，我爲何要談論它？ 由於你可使用 Kubernetes Proxy 來訪問它！啓動 Kubernetes Proxy:

$ kubectl proxy --port=8080

如今，你可使用以下的 Kubernetes API 訪問服務：

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

因此，若是要訪問咱們剛剛定義的服務，可使用下面的地址：

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

何時用？

有幾種狀況可使用 Kubernetes Proxy 來訪問您的服務：

• 調試您的服務，或因爲某種緣由直接從你筆記本電腦鏈接到它們
• 容許內部流量，顯示內部儀表盤等

因爲此方法要求您用已受權用戶運行 kubectl ，所以您不該該使用此方法將您的服務公開到公網上或將其用於生產。

NodePort

NodePort 服務是暴露服務的最原始方式。 顧名思義，NodePort 會在全部節點（VM）上打開一個特定的端口，而且發送到此端口的任何流量都將轉發到該服務。NodePort 服務的 YAML 相似這樣：

apiVersion: v1
kind: Service
metadata:  
  name: my-nodeport-service
selector:    
  app: my-app
spec:
  type: NodePort
  ports:  
  - name: http
    port: 80
    targetPort: 80
    nodePort: 30036
    protocol: TCP

基本上，NodePort 服務與普通的 「ClusterIP」 服務 YAML 定義有兩點區別。 首先，type 是 「NodePort」。還有一個稱爲 nodePort 的附加端口，指定在節點上打開哪一個端口。 若是你不指定這個端口，它會選擇一個隨機端口。

何時用？

這種方法有許多缺點：

• 每一個端口只能有一個服務
• 默認您只能使用端口30000-32767
• 若是您的 節點/虛擬機 IP 地址發生更改，則須要處理該問題

因爲這些緣由，我不建議在生產中使用這種方法。 若是您運行的服務沒必要始終可用，或者您很是關注成本，則此方法適用於您，好比演示程序或臨時應用。

LoadBalancer

LoadBalancer 服務暴露服務的標準方式。 在 GKE 上，這將啓動一個網絡負載平衡器，它將爲您提供一個將全部流量轉發到您的服務的IP地址。

何時用？

若是你想直接暴露一個服務，這是默認的方法(GKE上)。 您指定的端口上的全部流量都將被轉發到該服務， 沒有過濾、路由等。這意味着您能夠發送幾乎任何類型的流量，如 HTTP，TCP，UDP，Websockets，gRPC 或其餘。

最大的缺點是，您使用 LoadBalancer 公開的每項服務都將得到本身的 IP 地址，而且您必須爲每一個暴露的服務使用一個 LoadBalancer，這可能會付出比較大的代價！

Ingress

與以上全部例子不一樣，Ingress 實際上不是一種服務。相反，它位於多個服務以前，充當集羣中的「智能路由器」或入口點。

您可使用 Ingress 作不少不一樣的事情，而且有許多類型的 Ingress 控制器，具備不一樣的功能。

GKE 默認的 Ingress 控制器將爲您啓動一個 HTTP（S）負載均衡器。 這將使您能夠執行基於路徑和基於子域名的路由到後端服務。 例如，您能夠將 foo.yourdomain.com 上的全部內容發送到 foo 服務，並將 yourdomain.com/bar/ 路徑下全部內容發送到 bar 服務的。在 GKE 上的 七層 HTTP 負載均衡器 的 Ingress 對象 YAML 定義相似這樣：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  backend:
    serviceName: other
    servicePort: 8080
  rules:
  - host: foo.mydomain.com
    http:
      paths:
      - backend:
          serviceName: foo
          servicePort: 8080
  - host: mydomain.com
    http:
      paths:
      - path: /bar/*
        backend:
          serviceName: bar
          servicePort: 8080

何時用？

Ingress 多是暴露服務最強大的方式了，但也多是最複雜的。 來自 Google Cloud Load Balancer, Nginx, Contour, Istio 等的 Ingress 控制器類型不少。 還有用於 Ingress 控制器的插件，如 cert-manager，能夠爲您的服務自動提供 SSL 證書。

若是您但願在相同的 IP 地址下暴露多個服務，而且這些服務都使用相同的L7協議（一般是HTTP），則 Ingress 是最有用的。 若是您使用原生 GCP 集成，您只需支付一個負載平衡器，因爲 Ingress 很「智能」，您能夠得到許多開箱即用的功能（如 SSL，Auth，路由等）