<th id="0poub"></th>
  1. <th id="0poub"><track id="0poub"><dl id="0poub"></dl></track></th><dd id="0poub"><track id="0poub"></track></dd>

    <dd id="0poub"></dd>
    <dd id="0poub"><pre id="0poub"></pre></dd><th id="0poub"></th>
    <th id="0poub"><track id="0poub"></track></th>
    <tbody id="0poub"><pre id="0poub"></pre></tbody>
    <em id="0poub"><acronym id="0poub"><kbd id="0poub"></kbd></acronym></em>
    logo

    地址:深圳南山區大沖國際中心21樓

    聯系我們 : contact@wise2c.com

    產品支持 : service@wise2c.com

    售前咨詢 : sales@wise2c.com

    電話: +86 (755) 33268246

    粵ICP備16049363號

    十二月 2016

    • All
    • 技術漫談
    • 最佳實踐
    • 睿云新聞
    • 行業資訊

    在Rancher 1.2中實現基于CNI的扁平網絡

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

    Read More