Kubernetes NodePort、LoadBalancer和Ingress介紹

最近，有人問我NodePorts，LoadBalancers和Ingress之間有什麼差別。 它們都是将外部流量引入群集的方式，但是分别以不同的方式完成。 讓我們來具體看看它們是如何工作的，以及何時使用它們。

注意：此處的所有内容均适用于Google Kubernetes Engine。 如果您在另一個雲上運作，使用minikube或其他東西，這些将略有不同。 我也沒有深入了解技術細節。 如果您有興趣了解更多資訊，

官方文檔 是一個很好的資源！

ClusterIP

ClusterIP服務是預設的Kubernetes服務。 它為您提供叢集内的其他應用程式可以通路的服務。 沒有外部通路權限。

ClusterIP服務的YAML如下所示：

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

如果您無法從網際網路通路ClusterIP服務，我為什麼要談論它呢？ 事實證明，您可以使用Kubernetes代理通路它！

啟動Kubernetes代理：

$ 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通路服務?

在某些情況下，您可以使用Kubernetes代理來通路您的服務。

1. 調試您的服務或出于某種原因直接從您的筆記本電腦連接配接它們
2. 允許内部流量，顯示内部dashboard等

因為此方法要求您作為經過身份驗證的使用者運作kubectl，是以不應使用此方法将服務公開給Internet或将其用于生産服務。

NodePort

NodePort服務是将外部流量直接發送給您的服務的最原始方式。 顧名思義，NodePort在所有節點（VM）上打開一個特定端口，并且發送到該端口的任何流量都将轉發到該服務。

注意：上圖并不是技術上最精确的圖示，但我認為它說明了NodePort的工作原理。

NodePort服務的YAML如下所示：

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

基本上，NodePort服務與普通的“ClusterIP”服務有兩點不同。 首先，類型是“NodePort”。還有一個名為nodePort的附加端口，用于指定在節點上打開的端口。 如果您不指定此端口，它将選擇一個随機端口。 大多數時候你應該讓Kubernetes選擇端口；正如thockin所說，對于你可以使用的端口有很多必要的說明。

什麼時候使用這種方法？

這種方法有許多缺點：

1. 每個端口隻能有一個服務
2. 您隻能使用端口30000-32767
3. 如果您的Node/VM的IP位址發生變化，您需要處理好

出于這些原因，我不建議在生産中使用此方法直接公開您的服務。 如果您運作的服務不必始終可用，或者您的成本非常敏感，則此方法适合您。 比如示範應用程式或臨時的東西。

LoadBalancer

LoadBalancer服務是将服務公開給Internet的标準方法。 在GKE上，這将啟動

Network Load Balancer

，它将為您提供單個IP位址，以便将所有流量轉發到您的服務。

什麼時候使用？

如果要直接公開服務，這是預設方法。 您指定的端口上的所有流量都将轉發到該服務。 沒有過濾，沒有路由等。這意味着您可以向其發送幾乎任何類型的流量，如HTTP、TCP、UDP、Websockets、gRPC等等。

最大的缺點是您使用LoadBalancer公開的每個服務都将獲得自己的IP位址，并且您必須為每個公開的服務支付LoadBalancer，這可能會變得昂貴！

Ingress

與上述所有示例不同，Ingress實際上不是一種服務。 相反，它位于多個服務的前面，充當叢集中的“智能路由器”或入口點。

您可以使用Ingress執行許多不同的操作，并且有許多類型的Ingress控制器，都具有不同的功能。

預設的GKE ingress controller将為您啟動

HTTP(S)負載均衡器

。 這将允許您執行基于路徑和子域的路由到後端服務。 例如，您可以将

foo.yourdomain.com

上的所有内容發送到foo服務，并将

youdomain.com/bar/

下的所有内容發送到bar服務。

使用L7 HTTP負載均衡器的GKE上的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

等。 還有Ingress控制器的插件，如

cert-manager

，可以為您的服務自動配置SSL證書。

如果要在同一IP位址下公開多個服務，Ingress是最有用的，并且這些服務都使用相同的L7協定（通常是HTTP）。 如果您使用GCP內建，您隻需支付一個負載均衡器，并且因為Ingress是“智能”的，您可以獲得大量開箱即用的功能（如SSL、身份驗證、路由等）。

本文轉自DockOne-

Kubernetes NodePort、LoadBalancer和Ingress介紹