k8s-service中iptable node port實(shí)現(xiàn)原理是什么

本篇文章給大家分享的是有關(guān)k8s-service中iptable node port實(shí)現(xiàn)原理是什么，小編覺(jué)得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說(shuō)，跟著小編一起來(lái)看看吧。

在這里我們主要介紹node port的實(shí)現(xiàn)原理，當(dāng)然我們這里的k8s容器網(wǎng)絡(luò)還是基于iptable的，不是基于ipvs的。

部署的nginx-ingress-controller的service我們可以看到：

• 這個(gè)service為node prot類型

• cluster ip為10.254.188.128

• 這個(gè)cluster ip關(guān)聯(lián)了1個(gè)endpoints：10.1.27.2

• host的8080端口映射到了cluster ip的80端口和pod的80端口

• host的8443端口映射到了cluster ip的443端口和pod的443端口

kubectl describe service service-nginx-ingress -n kube-system

對(duì)node port類型的service來(lái)說(shuō)，訪問(wèn)host的port就訪問(wèn)到了這個(gè)服務(wù)。所以從host網(wǎng)絡(luò)角度來(lái)看，當(dāng)host收到數(shù)據(jù)包的時(shí)候應(yīng)該是進(jìn)入host network namespace的PREROUTING chain中，我們查看host network namespace的PREROUTING chain。

iptables -nvL -t nat

根據(jù)規(guī)則，對(duì)于PREROUTING chain中，所有的流量都走到了KUBE-SERVICES這個(gè)target中。

查看KUBE-SERVICES target：

iptables -nvL -t nat | grep KUBE-SVC

在KUBE-SERVICES target中我們可以看到當(dāng)訪問(wèn)nginx-ingress-controller-service在host上的8080或者8443port的時(shí)候，根據(jù)規(guī)則匹配到了KUBE-NODEPORTS這個(gè)target。

查看KUBE-NODEPORTS target：

iptables -nvL -t nat

在KUBE-NODEPORTS target中我們可以看到當(dāng)訪問(wèn)8080和8443時(shí)：

• KUBE-MARK-MASQ均會(huì)匹配

• KUBE-SVC-QY5PTWKILTPBPDCE匹配8080端口訪問(wèn)

• KUBE-SVC-SQYXO6PN7K55YEZU匹配8443端口訪問(wèn)

查看KUBE-MARK-MASQ target：

這里只是做了一下標(biāo)記，并沒(méi)有nat target。

iptables -nvL -t nat

查看KUBE-SVC-QY5PTWKILTPBPDCE和KUBE-SVC-SQYXO6PN7K55YEZU兩個(gè)target：

iptables -nvL -t nat

我們可以看到

• KUBE-SVC-QY5PTWKILTPBPDCE匹配進(jìn)入KUBE-SEP-WM2TRROMQQXWNW4W

• KUBE-SVC-SQYXO6PN7K55YEZU匹配進(jìn)入KUBE-SEP-7XLQX5JZL77UC7RY

• 看到這里細(xì)心的同學(xué)是不是覺(jué)得很熟悉，沒(méi)錯(cuò)，這和上一篇文章里cluster ip類型的service在ipable里如出一轍。唯一不同的是上一篇文章里的例子nginx-application-service有2個(gè)endpoints，這里nginx-ingress-controller-service只有一個(gè)endpoint。所以會(huì)匹配到一個(gè)KUBE-SEP-XXX，如果有多個(gè)endpoints，那么一定會(huì)leverage內(nèi)核隨機(jī)模塊random按百分比來(lái)均勻的匹配，從而實(shí)現(xiàn)對(duì)pord的訪問(wèn)負(fù)載均衡。

查看KUBE-SEP-WM2TRROMQQXWNW4W和KUBE-SEP-7XLQX5JZL77UC7RY兩個(gè)target：

iptables -nvL -t nat

我們可以看到

• 做了MASQ操作，當(dāng)然這個(gè)應(yīng)該是出站engress流量(限定了source ip)，不是我們的入站ingress流量。

• 做了DNAT操作，把原來(lái)的cluster ip給DANT轉(zhuǎn)換成了pod的ip 10.1.27.2，把原來(lái)的port轉(zhuǎn)換成了80或者443 port。

• 根據(jù)iptable，經(jīng)過(guò)PREROUTING chain發(fā)現(xiàn)DNAT之后的10.1.27.2不是本地的ip(肯定不是，因?yàn)檫@個(gè)ip是pod的ip，當(dāng)然不會(huì)在host的network namespace里)。所以就走到了Forwarding chain中，根據(jù)host network namespace的路由表來(lái)決定下一跳地址。

所以綜合上面的例子，對(duì)于ipable方式的k8s集群內(nèi)node port類型的service總結(jié)為：

• 在host netwok namespace的PREROUTING chain中會(huì)匹配KUBE-SERVICES target。

• 在KUBE-SERVICES target會(huì)匹配KUBE-NODEPORTS target

• 在KUBE-NODEPORTS target會(huì)根據(jù)prot來(lái)匹配KUBE-SVC-XXX target

以上就是k8s-service中iptable node port實(shí)現(xiàn)原理是什么，小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見(jiàn)到或用到的。希望你能通過(guò)這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注億速云行業(yè)資訊頻道。