1. Overview

我們生產(chǎn)k8s對(duì)外暴露服務(wù)有多種方式，其中一種使用external-ips?clusterip?service?ClusterIP Service方式對(duì)外暴露服務(wù)，kube-proxy使用iptables mode。這樣external ips可以指定固定幾臺(tái)worker節(jié)點(diǎn)的IP地址(worker節(jié)點(diǎn)服務(wù)已經(jīng)被驅(qū)逐，作為流量轉(zhuǎn)發(fā)節(jié)點(diǎn)不作為計(jì)算節(jié)點(diǎn))，并作為lvs vip下的rs來負(fù)載均衡。根據(jù)vip:port來訪問服務(wù)，并且根據(jù)port不同來區(qū)分業(yè)務(wù)。相比于NodePort Service那樣可以通過所有worker節(jié)點(diǎn)的node_ip:port來訪問更高效，也更容易落地生產(chǎn)。但是，traffic packet是怎么根據(jù)集群外worker節(jié)點(diǎn)的node_ip:port或者集群內(nèi)cluster_ip:port訪問方式找到pod ip的？

并且，我們生產(chǎn)k8s使用calico來作為cni插件，采用 Peered with TOR (Top of Rack) routers方式部署，每一個(gè)worker node和其置頂交換機(jī)建立bgp peer配對(duì)，置頂交換機(jī)會(huì)繼續(xù)和上層核心交換機(jī)建立bgp peer配對(duì)，這樣可以保證pod ip在公司內(nèi)網(wǎng)可以直接被訪問。

但是，traffic packet知道了pod ip，又是怎么跳到pod的呢？

以上問題可以歸并為一個(gè)問題：數(shù)據(jù)包是怎么一步步跳轉(zhuǎn)到pod的？很長時(shí)間以來，一直在思考這些問題。

2. 原理分析

實(shí)際上答案很簡單：訪問業(yè)務(wù)服務(wù)vip:port或者說node_ip:port，當(dāng)packet到達(dá)node_ip所在機(jī)器如worker A節(jié)點(diǎn)時(shí)，會(huì)根據(jù)iptable rules一步步找到pod ip；找到了pod ip后，由于使用calico bgp部署方式，核心交換機(jī)和置頂交換機(jī)都有該pod ip所在的ip段的路由，packet最后會(huì)跳轉(zhuǎn)到某一個(gè)worker節(jié)點(diǎn)比如worker B，而worker B上有calico早就寫好的路由規(guī)則route和虛擬網(wǎng)卡virtual interface，再根據(jù)veth pair從而由host network namespace跳轉(zhuǎn)到pod network namespace，從而跳轉(zhuǎn)到對(duì)應(yīng)的pod。

首先可以本地部署個(gè)k8s集群模擬測試下，這里使用 install minikube with calico ：

然后部署個(gè)業(yè)務(wù)pod，這里使用nginx為例，副本數(shù)為2，并創(chuàng)建ClusterIP Service with ExternalIPs和NodePort Service：

部署完成后，就可以通過 ExternalIP ClusterIP Service或者NodePort Service兩種方式訪問業(yè)務(wù)服務(wù)：

3. iptables寫自定義規(guī)則

當(dāng)數(shù)據(jù)包通過node_ip:port或者cluster_ip:port訪問服務(wù)時(shí)，會(huì)在當(dāng)前worker節(jié)點(diǎn)被內(nèi)核DNAT(Destination Network Address Translation)為pod ip，反向packet又會(huì)被SNAT(Source Network Address Translation)。這里借用calico官網(wǎng)的非常生動(dòng)的兩張圖說明About?Kubernetes?Services?：

cluster-ip service 訪問流程：

node-port service 訪問流程：

由于我們生產(chǎn)k8s的kube-proxy使用iptables mode，所以這些snat/dnat規(guī)則是kube-proxy進(jìn)程通過調(diào)用iptables命令來實(shí)現(xiàn)的。iptables使用各種chain來管理大量的iptable rules，主要是五鏈四表，五鏈包括：prerouting/input/output/forward/postrouting chain，四表包括：

raw/mangle/nat/filter table，同時(shí)也可以用戶自定義chain。數(shù)據(jù)包packet進(jìn)過內(nèi)核時(shí)經(jīng)過五鏈四表流程圖如下：

而kube-proxy進(jìn)程會(huì)在nat table內(nèi)自定義KUBE-SERVICES chain，并在PREROUTING內(nèi)生效，可以通過命令查看，然后在查看KUBE-SERVICES chain中的規(guī)則：

可以看到，如果在集群內(nèi)通過cluster_ip:port即10.196.52.1:8088，或者在集群外通過external_ip:port即192.168.64.57:8088方式訪問服務(wù)，都會(huì)在內(nèi)核里匹配到 KUBE-SVC-JKOCBQALQGD3X3RT chain的規(guī)則，這個(gè)對(duì)應(yīng)nginx-demo-1 service；如果是在集群內(nèi)通過cluster_ip:port即10.196.89.31:8089，或者集群外通過nodeport_ip:port即192.168.64.57:31755方式訪問服務(wù)，會(huì)匹配到 KUBE-SVC-6JCCLZMUQSW27LLD chain的規(guī)則，這個(gè)對(duì)應(yīng)nginx-demo-2 service：
然后繼續(xù)查找 KUBE-SVC-JKOCBQALQGD3X3RT chain和 KUBE-SVC-6JCCLZMUQSW27LLD chain的規(guī)則，發(fā)現(xiàn)每一個(gè) KUBE-SVC-xxx 都會(huì)跳轉(zhuǎn)到 KUBE-SEP-xxx chain上，并且因?yàn)閜od副本數(shù)是2，這里就會(huì)有兩個(gè) KUBE-SEP-xxx chain，并且以50%概率跳轉(zhuǎn)到任何一個(gè) KUBE-SEP-xxx chain，即rr(round robin)負(fù)載均衡算法，這里kube-proxy使用iptables statistic module來設(shè)置的，最后就會(huì)跳轉(zhuǎn)到pod ip 10.217.120.72:80(這里假設(shè)訪問這個(gè)pod)?？傊?，經(jīng)過kube-proxy調(diào)用iptables命令，根據(jù)service/endpoint設(shè)置對(duì)應(yīng)的chain，最終一步步跳轉(zhuǎn)到pod ip，從而數(shù)據(jù)包packet下一跳是該pod ip：

總之，不管是通過cluster_ip:port、external_ip:port還是node_ip:port方式訪問業(yè)務(wù)服務(wù)，packet通過kube-proxy進(jìn)程自定義的各種chain找到了下一跳pod ip地址。

但是，packet如何知道這個(gè)pod ip在哪個(gè)節(jié)點(diǎn)呢？

4. calico寫自定義routers和virtual interface

上文已經(jīng)說過，我們部署calico方式可以保證pod ip在集群外是可以被路由的，這是因?yàn)榻粨Q機(jī)上會(huì)有node level的路由規(guī)則，在交換機(jī)上執(zhí)行 dis bgp routing-table會(huì)有類似如下路由規(guī)則。表示如果訪問 10.20.30.40/26 pod網(wǎng)段下一跳是worker B的IP地址。這些路由規(guī)則是部署在每一個(gè)worker節(jié)點(diǎn)的bird進(jìn)程(bgp client)分發(fā)的，交換機(jī)通過BGP學(xué)習(xí)來的：

所以，packet在知道了pod ip 10.217.120.72:80?后(這里假設(shè)訪問了pod nginx-demo-1-7f67f8bdd8-fxptt)，很容易找到了worker B節(jié)點(diǎn)，本文章示例即是minikube節(jié)點(diǎn)。查看該節(jié)點(diǎn)的路由表和網(wǎng)卡，找到了在host network namespace這一側(cè)是網(wǎng)卡 cali1087c975dd9，編號(hào)是13，這個(gè)編號(hào)很重要，可以通過編號(hào)知道這個(gè)veth pair的另一端在哪個(gè)pod network namespace。發(fā)現(xiàn) pod nginx-demo-1-7f67f8bdd8-fxptt 的網(wǎng)卡eth0就是veth pair的另一端，并且編號(hào)也是13：

（版權(quán)歸原作者所有，侵刪）