最近有些同學問我 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 來選擇端口，因爲如評論中 thockin 所說，用戶自己來選擇可用端口代價太大。
何時使用這種方式？
- 這種方法有許多缺點：
- 每個端口只能是一種服務
- 端口範圍只能是 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