在Rancher 1.2中實(shí)現(xiàn)基于CNI的扁平網(wǎng)絡(luò)

  Rancher 1.2 網(wǎng)絡(luò)現(xiàn)狀Rancher 1.2之于之前的版本在很多地方都有顛覆性的更新，今天我著重來談網(wǎng)絡(luò)方面。在1.2中Rancher實(shí)現(xiàn)了對(duì)CNI的支持，通過network-plugin來實(shí)現(xiàn)對(duì)CNI的調(diào)用；另外，network-plugin還實(shí)現(xiàn)了如為暴露端口的容器配置DNAT，MASQUERADE等操作。但是，1.2版本也并非徹底的擁抱CNI，原因如下： 01?Network-plugin默認(rèn)為必選項(xiàng)，其內(nèi)部自動(dòng)檢測(cè)容器是否expose端口到host，并為容器端口配置DNAT規(guī)則；另外，所有容器默認(rèn)使用docker0經(jīng)過三層轉(zhuǎn)發(fā)（通過Iptables規(guī)則控制）來訪問外網(wǎng)，即全部配置MASQERADE；這一點(diǎn)限制了網(wǎng)絡(luò)模型（二層廣播域只能在host內(nèi)部），將影響到希望使用另一張網(wǎng)卡來實(shí)現(xiàn)扁平網(wǎng)絡(luò)的用戶；02Network-plugin的啟動(dòng)依賴于Metadata，而Metadata和DNS server均使用docker0的bridge網(wǎng)絡(luò)（IP為169.254.169.250）。即，用戶私有化的CNI網(wǎng)絡(luò)必須要能夠訪問到docker0網(wǎng)絡(luò)，否則Rancher提供的服務(wù)發(fā)現(xiàn)與注冊(cè)以及其它為業(yè)務(wù)層提供的服務(wù)將不可用。03不支持多個(gè)網(wǎng)絡(luò)，官方宣稱只能選擇一個(gè)CNI網(wǎng)絡(luò)，在UI中對(duì)所添加的各類型的CNI網(wǎng)絡(luò)均顯示為托管網(wǎng)絡(luò)。其中系統(tǒng)基礎(chǔ)服務(wù)比如scheduler、health check以及l(fā)oad balance默認(rèn)均只能在托管網(wǎng)絡(luò)內(nèi)工作。如若手工添加了其它CNI網(wǎng)絡(luò)，將導(dǎo)致第二個(gè)CNI網(wǎng)絡(luò)內(nèi)，scheduler、health check以及l(fā)oad balance異常?？蛻粜枨?一??在很多場(chǎng)景中用戶對(duì)于容器網(wǎng)絡(luò)的使用，還是希望業(yè)務(wù)與管理隔離，即通過一張獨(dú)立的網(wǎng)卡來運(yùn)行業(yè)務(wù)流量。二???在混合組網(wǎng)的場(chǎng)景中，用戶一部分業(yè)務(wù)運(yùn)行在裸機(jī)中，另一部分業(yè)務(wù)運(yùn)行在Rancher容器內(nèi)，將這兩張網(wǎng)絡(luò)統(tǒng)一為一張扁平化網(wǎng)絡(luò)的呼聲也較大。 解決方案基于Rancher 1.2中CNI的諸多限制，有沒有辦法去實(shí)現(xiàn)扁平網(wǎng)絡(luò)呢？答案是肯定的!網(wǎng)絡(luò)整體拓?fù)湎瓤匆粡埦W(wǎng)絡(luò)部署圖，下圖可分為兩個(gè)區(qū)域，Rancher區(qū)域與裸機(jī)區(qū)域。Rancher區(qū)域HOST-1和HOST-2分別為Rancher的agent節(jié)點(diǎn)（每個(gè)節(jié)點(diǎn)有兩張網(wǎng)卡），按業(yè)務(wù)劃分，該區(qū)域內(nèi)部可以通過容器部署一些變動(dòng)大、常啟?；虺U(kuò)縮容的業(yè)務(wù)。 裸機(jī)區(qū)域 Host-3以及其它主機(jī)為物理服務(wù)器（即裸機(jī)），按照業(yè)務(wù)劃分，host-3上可運(yùn)行一些相對(duì)業(yè)務(wù)對(duì)硬件資源要求較高，且不常變動(dòng)的業(yè)務(wù)組件。 這兩個(gè)區(qū)域通過業(yè)務(wù)交換機(jī)二層互聯(lián)，如果網(wǎng)絡(luò)規(guī)模小，這樣的拓?fù)浣Y(jié)果是沒有問題的。如若網(wǎng)絡(luò)規(guī)模大，需要考慮廣播域的問題，為了避免廣播風(fēng)暴，一些客戶會(huì)使用一些支持SDN的設(shè)備來取代業(yè)務(wù)交換機(jī)，從而對(duì)二層廣播做限制。  扁平網(wǎng)絡(luò)內(nèi)部（包括兩個(gè)區(qū)域的所有主機(jī)）統(tǒng)一使用外部的路由器做網(wǎng)關(guān)，比如圖中，Rancher內(nèi)部的容器的子網(wǎng)范圍為10.43.0.0/24, IP地址池范圍為10.43.1.2-10.43.1.254。同理，裸機(jī)域內(nèi)，子網(wǎng)范圍為10.43.0.0/24, IP地址池范圍為10.43.2.2-10.43.2.254。   之所以要將管理網(wǎng)絡(luò)和業(yè)務(wù)網(wǎng)路經(jīng)過同一個(gè)路由器（或者防火墻）是因?yàn)閟cheduler需要訪問cattle，即管理網(wǎng)；另一方面，scheduler又需要由CNI網(wǎng)絡(luò)中的health check 做健康檢查和故障恢復(fù)。若考慮安全問題，可以在防火墻上配置規(guī)則，對(duì)業(yè)務(wù)網(wǎng)對(duì)管理網(wǎng)的訪問做限制。 Rancher內(nèi)部CNI網(wǎng)絡(luò)內(nèi)部CNI網(wǎng)絡(luò)主要需要解決兩個(gè)問題：?一??如何訪問Metadata和DNS server的地址169.254.169.250；二 ?采用獨(dú)立的網(wǎng)卡來轉(zhuǎn)發(fā)業(yè)務(wù)流量后，二層廣播域跨主機(jī)了，若每臺(tái)主機(jī)上還通過同一個(gè)IP 169.254.169.250訪問DNS和Metadata服務(wù)，如何解決地址沖突的問題； 下圖是宿主機(jī)內(nèi)部CNI網(wǎng)絡(luò)的拓?fù)鋱D以及流量轉(zhuǎn)發(fā)規(guī)則： 由于扁平網(wǎng)絡(luò)需要使用自定義的bridge，與docker0無關(guān)。同一個(gè)network內(nèi)部的所有容器屬同一個(gè)二層網(wǎng)絡(luò)，且都不可見169.254.169.250地址。為了讓容器可以訪問該地址，我們采用將br0（CNI bridge）與docker0連通，然后再該鏈路上的流量做限制來實(shí)現(xiàn)。具體如下：1、container-1內(nèi)部有到達(dá)169.254.169.250的一條主機(jī)路由，即要訪問169.254.169.250需要先訪問10.43.0.2；2、 通過veth-cni與veth-doc的鏈接，CNI bridge下的container-1可以將ARP請(qǐng)求發(fā)送到docker0的10.43.0.2地址上。由于10.1.0.2的ARP response報(bào)文是被veth-cni放行的，于是container-1能夠收到來自10.43.0.2的ARP response報(bào)文。 3、然后container-1開始發(fā)送到169.254.169.250的IP請(qǐng)求，報(bào)文首先被送到docker0的veth-doc上，docker0查詢路由表，將報(bào)文轉(zhuǎn)到DNS/metadata對(duì)應(yīng)的容器。然后IP報(bào)文原路返回，被docker0路由到veth1上往br0發(fā)送，由于來自169.254.169.250的IP報(bào)文都是被放行的，因此container-1最終能夠收到IP。 4、由于屬于該network的所有的宿主機(jī)的docker0上都需要綁定IP地址10.43.0.2；因此，該IP地址必須被預(yù)留，即，在catalog中填寫CNI的netconf配置時(shí)，不能將其放入IP地址池。 5、 同時(shí)，為了保障該地址對(duì)應(yīng)的ARP請(qǐng)求報(bào)文不被發(fā)送出主機(jī)，從而收到其他主機(jī)上對(duì)應(yīng)接口的ARP響應(yīng)報(bào)文，需要對(duì)所有請(qǐng)求10.1.0.2地址的ARP REQUEST報(bào)文做限制，不允許其通過br0發(fā)送到宿主機(jī)網(wǎng)卡。 具體轉(zhuǎn)發(fā)規(guī)則對(duì)應(yīng)的ebtables規(guī)則如下所示：Drop All traffic from veth-cni except:1、 IP response from 169.254.169.250 2、 ?ARP response from 10.43.0.2 ebtables -t broute -A...