Kubernetes的三種外部訪問方式：NodePort、LoadBalancer和Ingress
最近有些同學問我 NodePort，LoadBalancer 和 Ingress 之間的區別。它們都是將集群外部流量導入到集群內的方式，只是實現方式不同。讓我們看一下它們分別是如何工作的，以及你該如何選擇它們。

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

注意：這里說的每一點都基于Google Kubernetes Engine。如果你用 minikube 或其它工具，以預置型模式（om prem）運行在其它云上，對應的操作可能有點區別。我不會太深入技術細節，如果你有興趣了解更多，官方文檔[1]是一個非常棒的資源。

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

如果 從Internet 沒法訪問 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 作為一個未認證的用戶，因此我們不能用這種方式把服務暴露到 internet 或者在生產環境使用。

NodePort

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

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”服務。第一，它的類型是“NodePort”。有一個額外的端口，稱為 nodePort，它指定節點上開放的端口值 。如果你不指定這個端口，系統將選擇一個隨機端口。大多數時候我們應該讓 Kubernetes 來選擇端口，因為用戶自己來選擇可用端口代價太大。

何時使用這種方式？

這種方法有許多缺點：
每個端口只能是一種服務
端口范圍只能是 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 文件類似如下：

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 可能是暴露服務的最強大方式，但同時也是最復雜的。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

原文鏈接：http://cloud.51cto.com/art/201804/570386.htm

總結

以上是生活随笔為你收集整理的Kubernetes的三种集群外部访问方式及使用场景说明：NodePort、LoadBalancer和Ingress的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。