Kubernetes 集群外部的 HTTP/HTTPS 請求是如何達(dá)到 Pod 中的 container 的？

HTTP 請求流轉(zhuǎn)過程概述

如上圖所示，全過程大致為：

(1) 用戶從 web/mobile/pc 等客戶端發(fā)出 HTTP/HTTPS 請求。

(2) 由于應(yīng)用服務(wù)通常是通過域名的形式對外暴露，所以請求將會先進(jìn)行 DNS 域名解析，得到對應(yīng)的公網(wǎng) IP 地址。

(3) 公網(wǎng) IP 地址通常會綁定一個 Load Balancer 負(fù)載均衡器，此時請求會進(jìn)入此負(fù)載均衡器。

• Load Balancer 負(fù)載均衡器可以是硬件，也可以是軟件，它通常會保持穩(wěn)定（固定的公網(wǎng) IP 地址），因?yàn)槿绻袚Q IP 地址會因?yàn)?DNS 緩存的原因?qū)е路?wù)某段時間內(nèi)不可達(dá)。
• Load Balancer 負(fù)載均衡器是一個重要的中間層，對外承接公網(wǎng)流量，對內(nèi)進(jìn)行流量的管理和轉(zhuǎn)發(fā)。

(4) Load Balancer 再將請求轉(zhuǎn)發(fā)到 kubernetes 集群的某個流量入口點(diǎn)，通常是 ingress。

• ingress 負(fù)責(zé)集群內(nèi)部的路由轉(zhuǎn)發(fā)，可以看成是集群內(nèi)部的網(wǎng)關(guān)。
• ingress 只是配置，具體進(jìn)行流量轉(zhuǎn)發(fā)的是 ingress-controller，后者有多種選擇，比如 Nginx、HAProxy、Traefik、Kong 等等。

(5)  ingress 根據(jù)用戶自定義的路由規(guī)則進(jìn)一步轉(zhuǎn)發(fā)到 service。

• 比如根據(jù)請求的 path 路徑或 host 做轉(zhuǎn)發(fā)。

(6) service 根據(jù) selector（匹配 label 標(biāo)簽）將請求轉(zhuǎn)發(fā)到 pod。

• service 有多種類型，集群內(nèi)部最常用的類型就是 ClusterIP。
• service 本質(zhì)上也只是一種配置，這種配置最終會作用到 node 節(jié)點(diǎn)上的 kube-proxy 組件，后者會通過設(shè)置 iptables/ipvs 來完成實(shí)際的請求轉(zhuǎn)發(fā)。
• service 可能會對應(yīng)多個 pod，但最終請求只會被隨機(jī)轉(zhuǎn)發(fā)到一個 pod 上。

(7) pod 最后將請求發(fā)送給其中的 container 容器。

同一個 pod 內(nèi)部可能有多個 container，但是多個容器不能共用同一個端口，因此這里會根據(jù)具體的端口號將請求發(fā)給對應(yīng)的 container。

以上就是一種典型的集群外部 HTTP 請求如何達(dá)到 Pod 中的 container 的全過程。

需要注意的是，由于網(wǎng)絡(luò)配置靈活多變，以上請求流轉(zhuǎn)過程并不是唯一的方式，例如：

如果你使用的是云服務(wù)，那么可以通過使用 LoadBalancer 類型的 service 直接綁定一個云服務(wù)商提供的負(fù)載均衡器，然后再接 ingress 或者其它 service。

你也可以通過 NodePort 類型的 service 直接使用節(jié)點(diǎn)上的端口，通過這些節(jié)點(diǎn)自建負(fù)載均衡器。

如果你的服務(wù)特別簡單，沒啥內(nèi)部流量需要管理的，這時不用 ingress 也是可以的。

容器技術(shù)的底座

容器技術(shù)的底座有三樣?xùn)|西：

• Namespace（這里是指 Linux 系統(tǒng)內(nèi)核的命名空間）
• Cgroups
• UnionFS

正是 Linux 內(nèi)核的 namespace 實(shí)現(xiàn)了資源的隔離。因?yàn)槊總€ pod 有各自的 Linux namespace，所以不同的 pod 是資源隔離的。namespace 有多種，包括 PID、IPC、Network、Mount、Time 等等。其中 PID namespace 實(shí)現(xiàn)了進(jìn)程的隔離，因此 pod 內(nèi)可以有自己的 1 號進(jìn)程。而 Network namespace 則讓每個 pod 有了自己的網(wǎng)絡(luò)。

Pod 有自己的網(wǎng)絡(luò)，node 節(jié)點(diǎn)也有自己的網(wǎng)絡(luò)，那么流量是如何從 node 節(jié)點(diǎn)到 pod 的呢？

HTTP 請求流轉(zhuǎn)過程補(bǔ)充

每個 node 節(jié)點(diǎn)上都有：

(1)kubelet：節(jié)點(diǎn)的小管家。

(2)kube-proxy：操作節(jié)點(diǎn)的 iptables/ipvs 。

(3)plugins:

• CRI：容器運(yùn)行時接口
• CNI：容器網(wǎng)絡(luò)接口
• CSI（可選）：容器存儲接口

每個 node 節(jié)點(diǎn)有自己的 root namespace，其中也包括網(wǎng)絡(luò)相關(guān)的 root netns，每個 pod 有自己的 pod netns，從 node 到 pod 則可以通過 veth pairs 的方式連通，流量也正是通過此通道進(jìn)行的流轉(zhuǎn)。而構(gòu)建 veth pairs、設(shè)置 pod network namespace、為 pod 分配 IP 地址等等工作則正是 CNI 的任務(wù)。

至此，一個典型的 kubernetes 集群外部的 HTTP/HTTPS 請求如何達(dá)到 Pod 中的 container 的全過程就是這樣了。

參考資料：

• https://kubernetes.io/docs/concepts/services-networking/
• https://learnk8s.io/kubernetes-network-packets