流量接入方案

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

通過 kube-proxy 進(jìn)行代理

通常在最簡(jiǎn)單的測(cè)試或個(gè)人開發(fā)環(huán)境，可以通過 kubectl port-forward 來啟動(dòng)一個(gè) kube-proxy 進(jìn)程代理內(nèi)部的服務(wù)至該命令執(zhí)行的宿主機(jī)節(jié)點(diǎn)，如果該宿主機(jī)具備公網(wǎng) IP，且轉(zhuǎn)發(fā)監(jiān)聽端口為0.0.0.0就可以實(shí)現(xiàn)公網(wǎng)訪問該服務(wù)，該方式可以代理單個(gè) 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 方式，會(huì)得到一個(gè)端口范圍在 30000-32767 端口范圍內(nèi)的宿主機(jī)端口，同樣宿主機(jī)具有公網(wǎng) IP 就可以實(shí)現(xiàn)對(duì)服務(wù)的暴露，但是 NodePort 會(huì)占用宿主機(jī)端口，一個(gè) Service 對(duì)應(yīng)一個(gè) NodePort，該方式僅為四層，無(wú)法實(shí)現(xiàn) SSL 證書的卸載，如果將服務(wù)轉(zhuǎn)發(fā)到單個(gè) Node 節(jié)點(diǎn)的 NodePort 也無(wú)法實(shí)現(xiàn)高可用，一般需要在 NodePort 前搭配負(fù)載均衡來添加多個(gè)后端 NodePort 已實(shí)現(xiàn)高可用。

LoadBalancer

四層

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

七層

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

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

Ingress

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

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

LoadBalancer + Ingress

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

Ingress-nginx 詳解

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

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

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

圖中展示如下信息：

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

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

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

其他

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