深入剖析kubernetes07容器網(wǎng)絡(luò)8講36丨說只有softmulti tenancy

在Kubernetes里，網(wǎng)絡(luò)能力的定義，是依靠一種專門的API對(duì)象來描述的，即一個(gè)完整的Network對(duì)象的示例，如下所示apiVersion:kind:name:test-namespace:role: ---- cidr:--project:-role:-protocol: port:-- cidr:-protocol: port:我在和你前面的內(nèi)容時(shí)已經(jīng)（這里你可以再回顧下第34篇文章《Kubernetes網(wǎng)絡(luò)模型與CNI網(wǎng)絡(luò)插件》中的相關(guān)內(nèi)容），Kubernetes里的Pod默認(rèn)都是“允許所有”（AcceptAll）的，即：Pod發(fā)送請(qǐng)求。而如果你要對(duì)這個(gè)情況作出限制，就必須通過Network對(duì)象來指定。Network的限制范圍，比如：當(dāng)前Namespace里攜帶了role=db的Pod而如果你把podSelectorpodSelector:那么這個(gè)Network就會(huì)作用于當(dāng)前Namespace下的所有Pod而一旦Pod被Network選中，那么這個(gè)Pod就會(huì)進(jìn)入“所有”（DenyAll）的狀態(tài)，即：這個(gè)Pod既不允許被外界，也不允許對(duì)外界發(fā)起。而Network定義的規(guī)則，其實(shí)就是“白”例如，在我們上面這個(gè)例子里，我在Types字段，定義了這個(gè)Network的類型是ingress和egress，即：它既會(huì)影響流入（ingress）請(qǐng)求，也會(huì)影響流出（egress）然后，在ingress字段里，我定義了from和ports，即：允許流入的“白”和端口。namespaceSelector和podSelector。而在egress字段里，我則定義了to和ports，即：允許流出的“白”和端口。這里允許流出的“白”的定義方法與ingress類似。只不過，這一次ipblock字段指定綜上所述，這個(gè)Network對(duì)象，指定的規(guī)則如下所示該規(guī)則只對(duì)defaultNamespace下的，攜帶了role=db的Pod有效。限制的請(qǐng)求類型包括ingress（流入）和egress（流出）。Kubernetes會(huì)任何被Pod的請(qǐng)求，除非這個(gè)請(qǐng)求來自于以下“白名單”里的對(duì)象，并且的是被Pod的6379端口。這些“白”對(duì)象包括：defaultNamespace里的，攜帶了role=fronted的任何Namespace里的、攜帶了project=myproject的任何源地址屬于172.17.0.0/16網(wǎng)段，且不屬于172.17.1.0/24Kubernetes會(huì)被Pod對(duì)外發(fā)起任何請(qǐng)求，除非請(qǐng)求的目的地址屬10.0.0.0/24網(wǎng)段，并且的是該網(wǎng)段地址的5978端口需要注意的是，定義一個(gè)Network對(duì)象的過程，容易犯錯(cuò)的是“白”部（fromto）--user:-role:namespaceSelectorpodSelector，是“或”（OR）的關(guān)系。所以說，這個(gè)from字段定義了兩種情況，無論是Namespace滿足條件，還是Pod滿足條件，這個(gè)Network都會(huì)生效。--56user:789namespaceSelectorpodSelector，其實(shí)是“與”（AND）的關(guān)系。所以說，這個(gè)from字段只定義了一種情況，只有Namespace和Pod同時(shí)滿足條件，這個(gè)Network才會(huì)生效。CNI網(wǎng)絡(luò)插件就必須是支持Kubernetes的Network的在具體實(shí)現(xiàn)上，凡是支持Network的CNI網(wǎng)絡(luò)插件，都著一個(gè)NetworkController，通過控制循環(huán)的方式對(duì)Network對(duì)象的增刪改查做出響應(yīng)，然后在宿主機(jī)上完成iptables規(guī)則的配置工作。在Kubernetes生態(tài)里，目前已經(jīng)實(shí)現(xiàn)了Network的網(wǎng)絡(luò)插件包括Calico、kube-routerFlannel所以說，如果想要在使用Flannel的同時(shí)還使用Network的話，你就需要再額外安裝一個(gè)網(wǎng)絡(luò)插件，比如Calico項(xiàng)目，來負(fù)責(zé)執(zhí)行Network。FlannelCalico那么，這些網(wǎng)絡(luò)插件，又是如何根據(jù)Network對(duì)Pod進(jìn)行的呢接下來，我就以三層網(wǎng)絡(luò)插件為例（Calicokube-router），來為你分析一下這部為了方便講解，這一次我編寫了一個(gè)比較簡單的Network對(duì)象，如下所示apiVersion:kind:name:test-namespace:role:--project:-role:-protocol: port:可以看到，我們指定的ingress“白”，是任何Namespace里，攜帶project=myproject的Pod；以及defaultNamespace里，攜帶了role=frontend的Pod。允許被的端口是：6379。而被的對(duì)象，是所有攜帶了role=db的Pod那么這個(gè)時(shí)候，Kubernetes的網(wǎng)絡(luò)插件就會(huì)使用這個(gè)Network的定義，在宿主機(jī)上生成iptables規(guī)則。這個(gè)過程，我可以通過如下所示的一段Go語言風(fēng)格的偽代碼來為fordstIP:=range所有被network.spec.podSelector選中的Pod的IP地forsrcIP:=range所有被ingress.from.podSelector選中的Pod的IPforport,protocol:=rangeingress.portsiptables-AKUBE-NWPLCY-CHAIN-s$srcIP-d$dstIP-p$protocol-m$protocol-- 7可以看到，這是一條最基本的、通過匹配條件決定下一步動(dòng)作的iptables規(guī)則。KUBE-NWPLCY-CHAINIPsrcIP、目的地址是dstIP、協(xié)議是protocol、目的端口是port的時(shí)候，就允許它通過（ACCEPT）。而正如這段偽代碼所示，匹配這條規(guī)則所需的這四個(gè)參數(shù)，都是從Network對(duì)象里Network對(duì)應(yīng)的iptable規(guī)則來實(shí)現(xiàn)的此外，在設(shè)置好上述“”規(guī)則之后，網(wǎng)絡(luò)插件還需要想辦法，將所有對(duì)被Pod的請(qǐng)求，都轉(zhuǎn)發(fā)到上述KUBE-NWPLCY-CHAIN規(guī)則上去進(jìn)行匹配。并且，如果匹配不在CNIiptables第一組規(guī)則，負(fù)責(zé)“”對(duì)被Pod的請(qǐng)求。生成這一組規(guī)則的偽代碼，如下所forpod:=range該Node上的所有Podifpod是network.spec.podSelector選中的3iptables-AFORWARD-d$podIP-mphysdev--physdev-is-bridged-jKUBE-POD-4iptables-AFORWARD-d$podIP-jKUBE-POD-SPECIFIC-FW-567}可以看到，這里的的iptables規(guī)則使用到了內(nèi)置鏈：FORWARD。它是什么意思呢？說到這里，我就得為你稍微普及一下iptables的知識(shí)了。實(shí)際上，iptables只是一個(gè)操作Linux內(nèi)核NetfilterNetfilter子系統(tǒng)的作用，就是Linux可以看到，這幅示意圖中，IP包“一進(jìn)一出”的兩條路徑上，有幾個(gè)關(guān)鍵的“檢查點(diǎn)”，它們正是Netfilter設(shè)置“”的地方。在iptables中，這些“檢查點(diǎn)”被稱為：鏈（Chain）iptables可以看到，當(dāng)一個(gè)IP包通過網(wǎng)卡進(jìn)入主機(jī)之后，它就進(jìn)入了Netfilter（InputPath）NetfilterPREROUTINGLinuxHook（比如，在執(zhí)行路由判斷的代碼之前，內(nèi)核會(huì)先調(diào)用PREROUTING的Hook）。而在經(jīng)過路由之后，IP包的去向就分為了兩種：我們先說一下IP包的第一種去向。這時(shí)候，IP包將繼續(xù)向上層協(xié)議棧流動(dòng)。在它進(jìn)入傳輸層之前，Netfilter會(huì)設(shè)置一個(gè)名叫INPUT的“檢查點(diǎn)”。到這里，IP包流入路徑（Input接下來，這個(gè)IP包通過傳輸層進(jìn)入用戶空間，交給用戶進(jìn)程處理。而處理完成后，用戶進(jìn)程會(huì)通過本機(jī)發(fā)出返回的IP包。這時(shí)候，這個(gè)IP包就進(jìn)入了流出路徑（OutputPath）。此時(shí)，IP包首先還是會(huì)經(jīng)過主機(jī)的路由表進(jìn)行路由。路由結(jié)束后，Netfilter就會(huì)設(shè)置一個(gè)OUTPUTOUTPUT你可能會(huì)覺得奇怪，為什么在流出路徑結(jié)束后，NetfilterIP徑（ForwardPath）。在轉(zhuǎn)發(fā)路徑中，Netfilter會(huì)設(shè)置一個(gè)名叫FORWARD的“檢查FORWARD“檢查點(diǎn)”完成后，IPIP已經(jīng)確定，它就不會(huì)再經(jīng)過路由，也自然不會(huì)經(jīng)過OUTPUT，而是會(huì)直接來到所以說，POSTROUTINGNetfilter這些鏈路層的“檢查點(diǎn)”對(duì)應(yīng)的操作界面叫作ebtables。所以，準(zhǔn)確地說，數(shù)據(jù)包在LinuxNetfilter（這是一幅來自Netfilteriptables在iptables里，這些叫作：表。比如，同樣是OUTPUT這個(gè)“檢查點(diǎn)”，filterOutputnatOutputiptables所以說，iptables”（Output）上，按順序執(zhí)行幾個(gè)不同的檢查動(dòng)作（比如，先執(zhí)行nat，再執(zhí)行filter）。在理解了iptables的工作原理之后，我們?cè)倩氐絅etwork上來。這時(shí)候，前面由網(wǎng)絡(luò)插件設(shè)置的、負(fù)責(zé)“”進(jìn)入Pod的請(qǐng)求的三條iptables規(guī)則，就很容易讀懂了：iptables-AFORWARD-d$podIP-mphysdev--physdev-is-bridged-jKUBE-POD-SPECIFIC-FW-iptables-AFORWARD-d$podIP-jKUBE-POD-SPECIFIC-FW-其中，第一條FORWARD鏈“”的是一種特殊情況：它對(duì)應(yīng)的是同一臺(tái)宿主機(jī)上容器之間經(jīng)過CNI網(wǎng)橋進(jìn)行通信的流入數(shù)據(jù)包。其中，–physdev-is-bridged的意思就是，這個(gè)FORWARD鏈匹配的是，通過本機(jī)上的網(wǎng)橋設(shè)備，發(fā)往目的地址是podIP的IP包。當(dāng)然，如果是像CalicoCNIkube-router其實(shí)是一個(gè)簡化版的Calico，它也使用BGP來路由信息，但是使用CNIbridge插件負(fù)責(zé)跟Kubernetes進(jìn)行交互。而第二條FORWARD鏈“”的則是最普遍的情況，即：容器跨主通信。這時(shí)候，流入容器的數(shù)據(jù)包都是經(jīng)過路由轉(zhuǎn)發(fā)（FORWARD檢查點(diǎn)）來的。不難看到，這些規(guī)則最后都跳轉(zhuǎn)（即：-j）KUBE-POD-SPECIFIC-FW-CHAIN規(guī)則上。它正是網(wǎng)絡(luò)插件為Network設(shè)置的第二組規(guī)則。而這個(gè)KUBE-POD-SPECIFIC-FW-CHAIN的作用，就是做出“允許”或者“”的判斷。這部分功能的實(shí)現(xiàn)，可以簡單描述為下面這樣的iptables規(guī)則：iptables-AKUBE-POD-SPECIFIC-FW-CHAIN-jKUBE-NWPLCY-iptables-AKUBE-POD-SPECIFIC-FW-CHAIN-jREJECT--reject-withicmp-port-可以看到，首先在第一條規(guī)則里，我們會(huì)把IP包轉(zhuǎn)交給前面定義的KUBE-NWPLCY-CHAINIP而如果匹配失敗，IP包就會(huì)來到第二條規(guī)則上?？梢钥吹?，它是一條REJECT規(guī)則。通過這條規(guī)則，不滿足Network定義的請(qǐng)求就會(huì)被掉，從而實(shí)現(xiàn)了對(duì)該容器的“隔以上，就是CNI網(wǎng)絡(luò)插件實(shí)現(xiàn)Network的基本方法了。當(dāng)然，對(duì)于不同的插件來在本篇文章中，我主要和你了Kubernetes對(duì)Pod進(jìn)行“”的，即可以看到，Network實(shí)際上只是宿主機(jī)上的一系列iptables規(guī)則。這跟傳統(tǒng)里面的安全組（SecurityGroup）其實(shí)是非常類似的。Kubernetes的網(wǎng)絡(luò)模型以及大多數(shù)容器網(wǎng)絡(luò)實(shí)現(xiàn)，其實(shí)既不會(huì)保證容器之間二層網(wǎng)絡(luò)的互通，也不會(huì)實(shí)現(xiàn)容器之間的二層網(wǎng)絡(luò)。這跟項(xiàng)目管理虛擬機(jī)的方式，是完全不同所以說，Kubernetes從底層的設(shè)計(jì)上，更傾向于假設(shè)你已經(jīng)有了一套完整的物理基礎(chǔ)設(shè)施。然后，Kubernetes負(fù)責(zé)在此基礎(chǔ)上提供一種“弱多租戶”（softmulti-并且，基于上述思路，Kubernetes將來也不大可能把Namespace變成一個(gè)具有實(shí)質(zhì)意義的機(jī)制，或者把它映射成為“子網(wǎng)”或者“租戶”。畢竟你可以看到，Network對(duì)象的描述能力，要比基于Namespace這也是為什么，到目前為止，Kubernetes當(dāng)然，隨著Kubernetes社區(qū)以及