背景

在業(yè)務(wù)使用 Kubernetes 進行編排管理時，針對業(yè)務(wù)的南北流量的接入，在 Kuberentes 中通常有幾種方案，本文就接入的方案進行簡單介紹。

流量接入方案

Kubernetes 社區(qū)通過為集群增設(shè)入口點的方案，解決對外流量的管理。

通過 kube-proxy 進行代理

通常在最簡單的測試或個人開發(fā)環(huán)境，可以通過 kubectl port-forward 來啟動一個 kube-proxy 進程代理內(nèi)部的服務(wù)至該命令執(zhí)行的宿主機節(jié)點，如果該宿主機具備公網(wǎng) IP，且轉(zhuǎn)發(fā)監(jiān)聽端口為0.0.0.0就可以實現(xiàn)公網(wǎng)訪問該服務(wù)，該方式可以代理單個 Pod，或者 Deployment，或者 Servcie。

$ kubectl port-forward -h
Forward one or more local ports to a pod. This command requires the node to have 'socat' installed.
 Use resource type/name such as deployment/mydeployment to select a pod. Resource type defaults to 'pod' if omitted.

 If there are multiple pods matching the criteria, a pod will be selected automatically. The forwarding session ends
when the selected pod terminates, and rerun of the command is needed to resume forwarding.
Examples:
  # Listen on ports 5000 and 6000 locally, forwarding data to/from ports 5000 and 6000 in the pod
  kubectl port-forward pod/mypod 5000 6000
  # Listen on ports 5000 and 6000 locally, forwarding data to/from ports 5000 and 6000 in a pod selected by the
deployment
  kubectl port-forward deployment/mydeployment 5000 6000
  # Listen on port 8443 locally, forwarding to the targetPort of the service's port named "https" in a pod selected by
the service
  kubectl port-forward service/myservice 8443:https
  # Listen on port 8888 locally, forwarding to 5000 in the pod
  kubectl port-forward pod/mypod 8888:5000
  # Listen on port 8888 on all addresses, forwarding to 5000 in the pod
  kubectl port-forward --address 0.0.0.0 pod/mypod 8888:5000
  # Listen on port 8888 on localhost and selected IP, forwarding to 5000 in the pod
  kubectl port-forward --address localhost,10.19.21.23 pod/mypod 8888:5000
  # Listen on a random port locally, forwarding to 5000 in the pod
  kubectl port-forward pod/mypod :5000

NodePort 方式

其次較常用的為 NodePort 方式，將 K8s 中 service 的類型修改為 NodePort 方式，會得到一個端口范圍在 30000-32767 端口范圍內(nèi)的宿主機端口，同樣宿主機具有公網(wǎng) IP 就可以實現(xiàn)對服務(wù)的暴露，但是 NodePort 會占用宿主機端口，一個 Service 對應(yīng)一個 NodePort，該方式僅為四層，無法實現(xiàn) SSL 證書的卸載，如果將服務(wù)轉(zhuǎn)發(fā)到單個 Node 節(jié)點的 NodePort 也無法實現(xiàn)高可用，一般需要在 NodePort 前搭配負載均衡來添加多個后端 NodePort 已實現(xiàn)高可用。

LoadBalancer

四層

四層流量轉(zhuǎn)發(fā)一個 LB 的端口只能對應(yīng)一個 Service，Servcie 的 Type 為 NodePort，例如如下圖，LoadBalancer 上的 88 端口對應(yīng)轉(zhuǎn)發(fā)到后端 NodePort 的 32111 端口，對應(yīng)到 servcieA；LB 上的 8080 端口對應(yīng)轉(zhuǎn)發(fā)到后端 NodePort32001 端口；該方案可以通過添加多個 NodePort 方式實現(xiàn)高可用，但是由于為四層無法實現(xiàn)對 SSL 的卸載，對應(yīng) NodePort 需要在 LB 占用一個端口。

七層

七層可以借助 LB 的域名轉(zhuǎn)發(fā)，實現(xiàn)一個域名端口對應(yīng)多個 Service，如圖可以根據(jù) path 路徑，/cmp 對應(yīng) NodePort 的 32111，/gateway 對應(yīng) NodePort 的 32000 端口，不僅可以實現(xiàn)高可用，而且七層可以實現(xiàn) SSL 卸載。

目前一般公有云的 LB 級別都具備四層和七層的功能，配合使用可以實現(xiàn)靈活的業(yè)務(wù)流量暴露。

Ingress

在 K8s 中，存在有 Ingress 資源來實現(xiàn)單個域名轉(zhuǎn)發(fā)根據(jù)不同的路徑或其他配置規(guī)則轉(zhuǎn)發(fā)到 K8 集群內(nèi)部不同的 Service，但是用戶請求需要訪問 Ingress 實現(xiàn)控制器的 NodePort 例如 Ingress-nginx 的 Controller 的 Service 的 NodePort，針對具體的業(yè)務(wù)域名一般不會帶端口，所以一般前面還需要一層 80/443 的端口轉(zhuǎn)發(fā)。

一般 Ingress 的 Controller 實現(xiàn)業(yè)界也有不少解決方案，例如比較知名的 Ingress—nginx/Ingress-traefik 等。

LoadBalancer + Ingress

如下圖所示在最前面有一個四層 LB 實現(xiàn)端口 80/443 轉(zhuǎn)發(fā)至 ingress-provider 的 Service 的 NodePort，K8s 集群內(nèi)部配置有多個 service。

Ingress-nginx 詳解

在上面的幾種方案中，均有用到 Ingress，Nginx-ingress 為 Nginx 官方提供的實現(xiàn) K8s ingress 資源的方案，同時 Kubernetes 官方也提供了基于 Nginx 實現(xiàn)的 Ingress 方案。

Nginx Ingress 由資源對象 Ingress、Ingress 控制器、Nginx 三部分組成，Ingress 控制器的目標(biāo)是構(gòu)建完成一個配置文件(nginx.conf)，主要通過檢測配置文件發(fā)生改變后重載 Nginx 實現(xiàn)，但并不是僅在 Upstream 更改時重載 Nginx（部署應(yīng)用程序時修改 Endpoints），使用 lua-nginx-module 實現(xiàn)。

根據(jù)下圖可以更好理解 Ingress-nginx 的使用場景。

圖中展示如下信息：

• 一個 K8s 集群。
• 集群用戶管理、用戶 A 和用戶 B，它們通過 Kubernetes API 使用集群。
• 客戶端 A 和客戶端 B，它們連接到相應(yīng)用戶部署的應(yīng)用程序 A 和 B。
• IC，由 Admin 部署在名稱空間 nginx-ingress 中的 pod 中，并通過 ConfigMap nginx-ingress 進行配置。Admin 通常部署至少兩個 pod 以實現(xiàn)冗余。IC 使用 Kubernetes API 獲取集群中創(chuàng)建的最新入口資源，然后根據(jù)這些資源配置 NGINX。
• 應(yīng)用程序 A 由用戶 A 在命名空間 A 中部署了兩個吊艙。為了通過主機 A.example.com 向其客戶機（客戶機 A）公開應(yīng)用程序，用戶 A 創(chuàng)建入口 A。
• 用戶 B 在命名空間 B 中部署了一個 pod 的應(yīng)用程序 B。為了通過主機 B.example.com 向其客戶機（客戶機 B）公開應(yīng)用程序，用戶 B 創(chuàng)建 VirtualServer B。
• 公共端點，它位于 IC 吊艙前面。這通常是一個 TCP 負載均衡器（云、軟件或硬件），或者這種負載均衡器與 NodePort 服務(wù)的組合?？蛻舳?A 和 B 通過公共端點連接到他們的應(yīng)用程序。

黃色和紫色箭頭表示與客戶端通信量相關(guān)的連接，黑色箭頭表示對 Kubernetes API 的訪問。

為了簡單，沒有顯示許多必要的 Kubernetes 資源，如部署和服務(wù)，管理員和用戶也需要創(chuàng)建這些資源。

其他

在 K8s 中，通常云廠商的 LB 一般云廠商提供適配 CNI，會在創(chuàng)建 K8s 集群時會自動創(chuàng)建 LB 類型的 servcie，例如阿里的 ACK，騰訊的 TKE，華為的 CCE 等，但是在我們自建或個人測試場景，開源的 Metallb[1]是一個不錯的選擇，其作用通過 K8s 原生的方式提供 LB 類型的 Service 支持，開箱即用，當(dāng)然還有青云科技 KubeSphere 團隊開源的負載均衡器插件 OpenELB[2],是為物理機（Bare-metal）、邊緣（Edge）和私有化環(huán)境設(shè)計的負載均衡器插件，可作為 Kubernetes、K3s、KubeSphere 的 LB 插件對集群外暴露 “LoadBalancer” 類型的服務(wù)。在 2021 年 11 月已進入 CNCF 沙箱（Sandbox）托管，也是解決用戶將 Kubernetes 集群部署在裸機上，或是私有化環(huán)境特別是物理機或邊緣集群，Kubernetes 并不提供 LoadBalancer 的痛點，提供與基于云的負載均衡器相同的用戶體驗。

引用鏈接

[1]Metallb: https://github.com/metallb/metallb。

[2]OpenELB: https://openelb.io/。