Kubernetes的三種外部訪問方式：NodePort、LoadBalancer和Ingress
最近有些同學(xué)問我 NodePort，LoadBalancer 和 Ingress 之間的區(qū)別。它們都是將集群外部流量導(dǎo)入到集群內(nèi)的方式，只是實(shí)現(xiàn)方式不同。讓我們看一下它們分別是如何工作的，以及你該如何選擇它們。
注意：這里說的每一點(diǎn)都基于Google Kubernetes Engine。如果你用 minikube 或其它工具，以預(yù)置型模式（om prem）運(yùn)行在其它云上，對應(yīng)的操作可能有點(diǎn)區(qū)別。我不會太深入技術(shù)細(xì)節(jié)，如果你有興趣了解更多，官方文檔[1]是一個(gè)非常棒的資源。
ClusterIP
ClusterIP 服務(wù)是 Kubernetes 的默認(rèn)服務(wù)。它給你一個(gè)集群內(nèi)的服務(wù)，集群內(nèi)的其它應(yīng)用都可以訪問該服務(wù)。集群外部無法訪問它。
ClusterIP 服務(wù)的 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 服務(wù)，那么我們?yōu)槭裁匆懻撍?？那是因?yàn)槲覀兛梢酝ㄟ^ Kubernetes 的 proxy 模式來訪問該服務(wù)！
啟動 Kubernetes proxy 模式：
- $ kubectl proxy --port=8080
這樣你可以通過Kubernetes API，使用如下模式來訪問這個(gè)服務(wù)：
- http://localhost:8080/api/v1/proxy/namespaces/<NAMESPACE>/services/<SERVICE-NAME>:<PORT-NAME>/
要訪問我們上面定義的服務(wù)，你可以使用如下地址：
- http://localhost:8080/api/v1/proxy/namespaces/default/services/my-internal-service:http/
何時(shí)使用這種方式？
有一些場景下，你得使用 Kubernetes 的 proxy 模式來訪問你的服務(wù)：
- 由于某些原因，你需要調(diào)試你的服務(wù)，或者需要直接通過筆記本電腦去訪問它們。
- 容許內(nèi)部通信，展示內(nèi)部儀表盤等。
這種方式要求我們運(yùn)行 kubectl 作為一個(gè)未認(rèn)證的用戶，因此我們不能用這種方式把服務(wù)暴露到 internet 或者在生產(chǎn)環(huán)境使用。
NodePort
NodePort 服務(wù)是引導(dǎo)外部流量到你的服務(wù)的最原始方式。NodePort，正如這個(gè)名字所示，在所有節(jié)點(diǎn)（虛擬機(jī)）上開放一個(gè)特定端口，任何發(fā)送到該端口的流量都被轉(zhuǎn)發(fā)到對應(yīng)服務(wù)。
NodePort 服務(wù)的 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 服務(wù)主要有兩點(diǎn)區(qū)別于普通的“ClusterIP”服務(wù)。***，它的類型是“NodePort”。有一個(gè)額外的端口，稱為 nodePort，它指定節(jié)點(diǎn)上開放的端口值 。如果你不指定這個(gè)端口，系統(tǒng)將選擇一個(gè)隨機(jī)端口。大多數(shù)時(shí)候我們應(yīng)該讓 Kubernetes 來選擇端口，因?yàn)槿缭u論中 thockin 所說，用戶自己來選擇可用端口代價(jià)太大。
何時(shí)使用這種方式？
- 這種方法有許多缺點(diǎn)：
- 每個(gè)端口只能是一種服務(wù)
- 端口范圍只能是 30000-32767
如果節(jié)點(diǎn)/VM 的 IP 地址發(fā)生變化，你需要能處理這種情況
基于以上原因，我不建議在生產(chǎn)環(huán)境上用這種方式暴露服務(wù)。如果你運(yùn)行的服務(wù)不要求一直可用，或者對成本比較敏感，你可以使用這種方法。這樣的應(yīng)用的***例子是 demo 應(yīng)用，或者某些臨時(shí)應(yīng)用。
LoadBalancer
LoadBalancer 服務(wù)是暴露服務(wù)到 internet 的標(biāo)準(zhǔn)方式。在 GKE 上，這種方式會啟動一個(gè) Network Load Balancer[2]，它將給你一個(gè)單獨(dú)的 IP 地址，轉(zhuǎn)發(fā)所有流量到你的服務(wù)。
何時(shí)使用這種方式？
如果你想要直接暴露服務(wù)，這就是默認(rèn)方式。所有通往你指定的端口的流量都會被轉(zhuǎn)發(fā)到對應(yīng)的服務(wù)。它沒有過濾條件，沒有路由等。這意味著你幾乎可以發(fā)送任何種類的流量到該服務(wù)，像 HTTP，TCP，UDP，Websocket，gRPC 或其它任意種類。
這個(gè)方式的***缺點(diǎn)是每一個(gè)用 LoadBalancer 暴露的服務(wù)都會有它自己的 IP 地址，每個(gè)用到的 LoadBalancer 都需要付費(fèi)，這將是非常昂貴的。
Ingress
有別于以上所有例子，Ingress 事實(shí)上不是一種服務(wù)類型。相反，它處于多個(gè)服務(wù)的前端，扮演著“智能路由”或者集群入口的角色。
你可以用 Ingress 來做許多不同的事情，各種不同類型的 Ingress 控制器也有不同的能力。
GKE 上的默認(rèn) ingress 控制器是啟動一個(gè) HTTP(S) Load Balancer[3]。它允許你基于路徑或者子域名來路由流量到后端服務(wù)。例如，你可以將任何發(fā)往域名 foo.yourdomain.com 的流量轉(zhuǎn)到 foo 服務(wù)，將路徑 yourdomain.com/bar/path 的流量轉(zhuǎn)到 bar 服務(wù)。
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
何時(shí)使用這種方式？
Ingress 可能是暴露服務(wù)的***大方式，但同時(shí)也是最復(fù)雜的。Ingress 控制器有各種類型，包括 Google Cloud Load Balancer， Nginx，Contour，Istio，等等。它還有各種插件，比如 cert-manager[5]，它可以為你的服務(wù)自動提供 SSL 證書。
如果你想要使用同一個(gè) IP 暴露多個(gè)服務(wù)，這些服務(wù)都是使用相同的七層協(xié)議（典型如 HTTP），那么Ingress 就是最有用的。如果你使用本地的 GCP 集成，你只需要為一個(gè)負(fù)載均衡器付費(fèi)，且由于 Ingress是“智能”的，你還可以獲取各種開箱即用的特性（比如 SSL、認(rèn)證、路由等等）。
相關(guān)鏈接：
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
