本問(wèn)討論了Calico項(xiàng)目的目的，以及探討了用從上世紀(jì)90年代以來(lái)發(fā)展起來(lái)的網(wǎng)絡(luò)架構(gòu)，三層網(wǎng)絡(luò)模型，L2與L3層轉(zhuǎn)發(fā)模式，論證了如何基于現(xiàn)有基礎(chǔ)，通過(guò)采用新興的“奶牛模式”，來(lái)實(shí)現(xiàn)云網(wǎng)絡(luò)架構(gòu)的可擴(kuò)展性和高性能。
最近，有很多關(guān)于Calico項(xiàng)目的討論，但是大多數(shù)討論只是圍繞著通過(guò)把現(xiàn)有互聯(lián)網(wǎng)基礎(chǔ)架構(gòu)應(yīng)用到數(shù)據(jù)中心來(lái)實(shí)現(xiàn)擴(kuò)展性和簡(jiǎn)化網(wǎng)絡(luò)架構(gòu)來(lái)進(jìn)行的。
然而，當(dāng)審視這個(gè)項(xiàng)目時(shí)，還是有一部分人會(huì)用我稱之為“經(jīng)典企業(yè)鏡頭”的方式來(lái)進(jìn)行，這種方式將會(huì)對(duì)Calico項(xiàng)目帶來(lái)誤解，或者將傳統(tǒng)網(wǎng)絡(luò)模型應(yīng)用到Calico上。其原因在于Calico是從一個(gè)非常不同的視角發(fā)展而來(lái)的，因此用傳統(tǒng)模式來(lái)分析它不一定能奏效。
這些誤解集中在三點(diǎn)，下面我會(huì)逐點(diǎn)展開(kāi)。在此之前，我還是要指出，在可擴(kuò)展式架構(gòu)方法和經(jīng)典企業(yè)架構(gòu)方法之間還是有哲學(xué)基本概念上的差別。
提起經(jīng)典企業(yè)架構(gòu)方法，一些特質(zhì)包括：當(dāng)企業(yè)數(shù)據(jù)中心建設(shè)時(shí)，系統(tǒng)將會(huì)長(zhǎng)期運(yùn)行而且很好地自包含(self-contained);每個(gè)應(yīng)用都會(huì)有各自的需求，因此會(huì)有非常客制化的架構(gòu)設(shè)計(jì)，或者說(shuō)架構(gòu)模板會(huì)非常多;必須要在增長(zhǎng)的復(fù)雜度和架構(gòu)靈活度之間尋找最佳點(diǎn);因?yàn)樾枨蠼?jīng)常是靜態(tài)的，因此，最佳點(diǎn)基本上需要合理的妥協(xié)。
隨著可擴(kuò)展或者云中心架構(gòu)時(shí)代的來(lái)臨，我們今天采用的架構(gòu)知識(shí)表明：真實(shí)的基礎(chǔ)架構(gòu)需求更多時(shí)候是統(tǒng)一的(同樣的協(xié)議，相似的存儲(chǔ)模型，相似的計(jì)算模式)，但也是更加動(dòng)態(tài)和更加擴(kuò)展化的。這就引出了我們常說(shuō)的“寵物和奶牛模式”。不幸的是，網(wǎng)絡(luò)架構(gòu)還是被當(dāng)做寵物模式，“被接受”的模式還是試圖將正在使用的，脆弱的，靜態(tài)的設(shè)計(jì)模式一直到新的，可擴(kuò)展式的，更少客制化的環(huán)境。明顯的，向一個(gè)脆弱的，靜態(tài)網(wǎng)絡(luò)模式注入可擴(kuò)展性必將帶來(lái)新的“挑戰(zhàn)”。在Calio項(xiàng)目中，我們將在網(wǎng)絡(luò)上采用更多的“奶牛”模式，實(shí)際上，從云中其它模塊(可擴(kuò)展式，非常動(dòng)態(tài)的，單一設(shè)計(jì)模式)中借鑒驅(qū)動(dòng) (drivers)，從而整合成擴(kuò)展性很好，可以用于公有云的網(wǎng)絡(luò)模塊。我們相信這是一條通向云、可擴(kuò)展環(huán)境的可選道路，它拋棄了不必要的復(fù)雜性，從而帶來(lái)了動(dòng)態(tài)和擴(kuò)展性。
真正為大家所知的是Calico是可擴(kuò)展架構(gòu)，因此，比overlay方式更有效。但是更重要的是，對(duì)于一般的使用場(chǎng)景非常有效，只對(duì)必須的場(chǎng)景增加相應(yīng)的復(fù)雜度。100%的純粹架構(gòu)功能設(shè)計(jì)相對(duì)簡(jiǎn)單，只要你并不在意復(fù)雜度帶來(lái)的操作上的困難。目前的辦法是為不同子網(wǎng)采用不同的架構(gòu)，在盡量不碰到麻煩的情況下帶來(lái)最佳的效果。我們相信Calico項(xiàng)目正式朝著這個(gè)方向努力的。
關(guān)于Calico，最主要的三點(diǎn)建議是：
L3 vs. L2 and overlays vs. native
最近幾個(gè)項(xiàng)目，我們聽(tīng)到很多關(guān)于“Calico為了可擴(kuò)展性回歸了L2”，或者“Calico使用microsegmentation模式(一種從L3路由架構(gòu)看起來(lái)更像L2層的模式) ”。這兩種說(shuō)法，混淆了兩個(gè)概念：
網(wǎng)絡(luò)上轉(zhuǎn)發(fā)量子(quata)是什么?或者說(shuō)轉(zhuǎn)發(fā)系統(tǒng)基于底層包的哪個(gè)比特?
網(wǎng)(fabric)中是什么把轉(zhuǎn)發(fā)節(jié)點(diǎn)整合成一個(gè)大網(wǎng)絡(luò)
讓我們分開(kāi)討論。
網(wǎng)絡(luò)中什么是轉(zhuǎn)發(fā)量子?
今天在可擴(kuò)展或者云架構(gòu)中，大部分應(yīng)用產(chǎn)生的數(shù)據(jù)包都是IP包。如果發(fā)現(xiàn)非IP包(或者IP相關(guān)，像 ICMP)，那我就可能要拍磚了。。。IPX, NetBEUI, EtherTalk, Banyan Vines, ATM, and DECNet 等系統(tǒng)已經(jīng)過(guò)時(shí)很久了 (我猜DECNet 有可能在一些暗黑角落仍然會(huì)生存一段時(shí)間). 當(dāng)人們提到“我需要L2網(wǎng)絡(luò)”時(shí)候，更多時(shí)候意味著“我需要一個(gè)私有IP網(wǎng)絡(luò)”或者“我不想為了這個(gè)應(yīng)用改變從上世紀(jì)90年代就使用的架構(gòu)”。(好吧， 上世紀(jì)90年代令人窒息的， 三層結(jié)婚蛋糕似的網(wǎng)絡(luò)回歸。)
因?yàn)镮P是我們目前使用網(wǎng)絡(luò)的原子(quata)，因此使用它作為轉(zhuǎn)發(fā)模式才有意義。IETF選擇L2OL3打包模式(PWE3,L2VPN等等)，其原因就是：L3是現(xiàn)實(shí)中的標(biāo)準(zhǔn)，為什么不使用現(xiàn)實(shí)標(biāo)準(zhǔn)，在此之上打包呢(傳統(tǒng)的L2)。但是他們忘記了，這種想問(wèn)題的方法會(huì)走向死胡同，就如同將基于Ethernet的IP包包裝在VXLAN上似的，有意義嗎?效率可以接受嗎?容易排錯(cuò)嗎?如果我們真的認(rèn)為Ethernet是正確的轉(zhuǎn)發(fā)原子(quata)，我們直接建一個(gè)L2網(wǎng)絡(luò)不可以嗎?---哦，看起來(lái)我們?cè)?jīng)嘗試過(guò)，但是并不成功，對(duì)嗎?
使用IP作為轉(zhuǎn)發(fā)原子(quata)帶來(lái)一個(gè)問(wèn)題，L2層分段的概念會(huì)丟失很多信息。在一個(gè)以太網(wǎng)絡(luò)，兩個(gè)節(jié)點(diǎn)之間要么在一個(gè)段內(nèi)是相連的，要么是不相連的。如果是相連的，他們之間可以轉(zhuǎn)發(fā)，如果不相連則不能轉(zhuǎn)發(fā)。 IP并沒(méi)有一個(gè)段的概念(甚至是子段，將L2層段概念對(duì)應(yīng)于IP地址段)。而在一個(gè)純粹的IP網(wǎng)段，路由器轉(zhuǎn)發(fā)“longest prefix match(最長(zhǎng)前綴匹配)” 一般來(lái)說(shuō)IP地址可以被一組比特前綴分組， (例如： 192.0.2.0/24, 198.51.100.16/30, and 2001:db8:://128)，這些分組跟底層物理拓?fù)錄](méi)有任何關(guān)系，或者，可以說(shuō)所有符合以上分組特征的地址從路由器角度來(lái)看共享一個(gè)路由 。因此，如果一個(gè)路由器有一條路由 192.0.2.0/24 是通過(guò) interface 1, 而192.0.2.26/32 通過(guò) interface 2, 那么所有的通過(guò)192.0.2.0/24的流量都會(huì)通過(guò) interface 1, 除非目的地址是 192.0.2.26, 會(huì)通過(guò) interface 2. 這種方式允許一些在Ethernet無(wú)效的方式也可以被采用，使得“microsegmentation”的概念在IP網(wǎng)絡(luò)中真正有意義。
Calico方法有一些前提。所有(或者幾乎所有)流量都是可以被轉(zhuǎn)發(fā)的IP，IP地址不是寫死的，而是采用某種自發(fā)現(xiàn)服務(wù)(比如，DNS)。這兩種模式在業(yè)界至少有15年歷史，也許我們可以讓這種上世紀(jì)90年代的網(wǎng)絡(luò)技術(shù)用的更久。基于這種模式，Calico團(tuán)隊(duì)相信我們并不需要把IP流量打包進(jìn)L2層，就如同將IP流量打包進(jìn)其他網(wǎng)絡(luò)層(例如VXLAN，NVGRE等等)，最后把他們又打包成另外一個(gè)IP包，這是完全沒(méi)有必要的。我們和大家在談?wù)揅alico項(xiàng)目，或者在大會(huì)，交流會(huì)上期望表達(dá)這一觀點(diǎn)，因此，我們不希望也不會(huì)使用打包的方式作為Calico項(xiàng)目主要的傳輸機(jī)制。
[page]網(wǎng)內(nèi)如何連接節(jié)點(diǎn)(網(wǎng)：internal fabri)
一些不太理解路由網(wǎng)絡(luò)工作原理的人可能會(huì)說(shuō)：“Calico回歸Ethernet是因?yàn)榭蓴U(kuò)展的原因”。這和Calico網(wǎng)站討論物理、網(wǎng)絡(luò)拓?fù)涞奈臋n有關(guān)，這些可以從 here 和 here獲得。
在互聯(lián)網(wǎng)架構(gòu)編年史中，你會(huì)發(fā)現(xiàn)如何讓背板操作和路由器更好的結(jié)合是一個(gè)長(zhǎng)期的“宗教式的”戰(zhàn)爭(zhēng)。某些人使用switching方式(首先是 ATM，然后是Ethernet或者M(jìn)PLS)，其他人使用routing(比如PPP over SDH)，其原因并不是某些人更聰明些，而是不同的操作有不同的需求和限制。IP網(wǎng)絡(luò)的優(yōu)美之處在于幾乎有無(wú)窮多的選擇可以跟路由器相連，可以直連其它路由器(edge-router，或者core-router概念)，從數(shù)據(jù)中心角度來(lái)看更像一個(gè)L3網(wǎng)絡(luò);你可以使用switching，例如 Ethernet或者M(jìn)PLS，前者最有代表的是L2層，后者則是以大型服務(wù)提供商為代表。實(shí)際上，你甚至可以采用 carrier pigeons (如果某個(gè)人可以為Calico實(shí)現(xiàn)IP over Avian Carrier，Calico團(tuán)隊(duì)會(huì)有大獎(jiǎng)給你)。
使用IP轉(zhuǎn)發(fā)設(shè)計(jì)，然后將計(jì)算節(jié)點(diǎn)、服務(wù)器、從節(jié)點(diǎn)都連接到路由器上，我們?cè)试S基礎(chǔ)架構(gòu)來(lái)決定這些服務(wù)器如何相連，并把這一決定對(duì)應(yīng)用層隔離，或者簡(jiǎn)單說(shuō)，我們可以將架構(gòu)和應(yīng)用解耦。
與做任何工程設(shè)計(jì)類似，要在很多因素中間做折中，基礎(chǔ)架構(gòu)設(shè)計(jì)必須要權(quán)衡這些因素，最終決定怎樣在Calico路由器間互連。 (今天很多大規(guī)模部署Calico的客戶使用Trident II based ToRs 作為L(zhǎng)3互聯(lián)的方式。不帶路由聚合會(huì)產(chǎn)生128K IPV4的負(fù)載。對(duì)于沒(méi)有很多路由聚合的長(zhǎng)前綴匹配場(chǎng)景，除了仍然具有IP的匹配性外，仍然具有高擴(kuò)展性)。
我們?cè)诰W(wǎng)站文檔部分發(fā)布了一些關(guān)于不同互聯(lián)方式的想法，但是因?yàn)榇嬖贚2和L3不同連接Calico節(jié)點(diǎn)的方式，不同的選擇將會(huì)影響到路由的擴(kuò)展性，但是這并不意味著Calico將會(huì)“回歸Ethernet”。任何互聯(lián)Calico節(jié)點(diǎn)的架構(gòu)， 最終都會(huì)轉(zhuǎn)發(fā)IP包。
“私有”網(wǎng)問(wèn)題
另外一個(gè)我們經(jīng)常聽(tīng)到的問(wèn)題是：從上世紀(jì)90年代的網(wǎng)絡(luò)并未消失，一些關(guān)鍵應(yīng)用寫死了IP地址;或者某些公司之間收購(gòu)，大家都使用10.1.1.1作為關(guān)鍵應(yīng)用的IP地址，而且無(wú)法更改。我們承認(rèn)這個(gè)時(shí)間并不太平，這類事情很有可能發(fā)生，那么Calico怎么處理這類問(wèn)題呢?讓咱們首先看看其他人怎么做?
全部打包(Encapsulate everything)
網(wǎng)絡(luò)供應(yīng)商最喜歡打包模式……，網(wǎng)絡(luò)操作人員卻恰恰相反……然而即使 overlay操作，或者打包網(wǎng)絡(luò)很困難，對(duì)這類問(wèn)題的回答基本都是“全部打包”。如果你假設(shè)大部分流量并不是基于IPV4節(jié)點(diǎn)的，那么這個(gè)方案影響不大。但是如果不是這樣的話，你的基礎(chǔ)架構(gòu)可能就很大的問(wèn)題(叫做1:1 NAT和DNS ALG，NAT鏈，和更多的痛點(diǎn))。如果大部分流量負(fù)載工作機(jī)制很好，為什么非要為少部分“不法之徒(miscreants)”而去改變呢?
NAT更簡(jiǎn)單?
另外一個(gè)問(wèn)題來(lái)自NAT。如果我對(duì)全部負(fù)載都打包，我需要在服務(wù)末端提供NAT功能，但是NAT有一些問(wèn)題：一個(gè)就是 NAT太面向狀態(tài)。所有NAT實(shí)現(xiàn)中，必須為每一個(gè)鏈接或者流經(jīng)NAT設(shè)備的流維護(hù)一個(gè)狀態(tài)表。如果設(shè)備宕機(jī)，所有鏈接就會(huì)斷掉。如果無(wú)法接受這種情況，就需要在多個(gè)NAT節(jié)點(diǎn)之間實(shí)時(shí)復(fù)制狀態(tài)。在一個(gè)大型網(wǎng)絡(luò)中，這回成為一個(gè)嚴(yán)重的問(wèn)題。另外，如果使用NAT，有可能需要欺騙DNS(比如在NAT兩端要對(duì)同一個(gè)域名解析出不同的IP地址)。這就需要維護(hù)一個(gè)多向映射表。要想對(duì)這種環(huán)境進(jìn)行排錯(cuò)，就需要理解在源端和目的端應(yīng)該開(kāi)到什么，然后確認(rèn)確實(shí)看到這些內(nèi)容。這也是為什么在一個(gè)NAT/DNS-ALG云端部署一個(gè)應(yīng)用第一次(有可能第二次，第三次)一般都不會(huì)成功的原因，NAT一點(diǎn)都不簡(jiǎn)單。
一個(gè)工具 (464-XLAT)
因此在Calico中，我們采用了不同的方式。我們采用IETF-464-XLAT標(biāo)準(zhǔn)，IPV6標(biāo)準(zhǔn)信息傳遞機(jī)制。是的，也就是意味著底層必須要是IPv6，但是近十年之內(nèi)的設(shè)備都支持IPv6。另外，因?yàn)楣俜叫糏Pv4地址近乎衰竭，真的需要在可擴(kuò)展性云中激活I(lǐng)Pv6功能(北美ARIN最近就拒絕了一次IPv4的申請(qǐng)，因?yàn)闆](méi)有可用的IPv4地址了)。
現(xiàn)在深呼一口氣，我們一起看看使用IPv6能夠做什么。IPv6地址空間比起IPv4大很多，使得我們可以把整個(gè)IPv4地址空間(大約2百萬(wàn)地址)映射到預(yù)留的IPv6空間。在Calico中，我們給每一個(gè)實(shí)例一塊重復(fù)的多租戶空間，每個(gè)都是2百萬(wàn)地址。每個(gè)實(shí)例有一個(gè)不同的IPV6前綴，來(lái)假裝IPv4的源和目的地址。然后將IPv4轉(zhuǎn)換成IPv6包，轉(zhuǎn)發(fā)出去，在接收端，過(guò)程剛好反過(guò)來(lái)，應(yīng)用感知不到這個(gè)IPv6與IPv4地址的映射。
因?yàn)榭梢园阉蠭Pv4地址都轉(zhuǎn)換成唯一的IPv6地址，因此我們可以做一些算法上的優(yōu)化，而不是只記錄每個(gè)包的狀態(tài)。重復(fù)一遍，如果愿意，Calico可以無(wú)狀態(tài)的支持所有重復(fù)的IPv4，映射工作可能失敗，當(dāng)包彈回來(lái)，流量可以繼續(xù)轉(zhuǎn)發(fā)。無(wú)狀態(tài)，無(wú)狀態(tài)復(fù)制高可用，只是靜態(tài)的地址傳送。另外一個(gè)好處是，如果一旦知道“實(shí)例”如何包裝成IPv6地址，不用查看NAT狀態(tài)表，不用查看隧道映射表，只看IPv6地址，就可以查看任何數(shù)據(jù)包，精確告訴此包的IPv4源地址和目的地址，屬于哪個(gè)實(shí)例。
因此，當(dāng)(因?yàn)?Calico并不把重疊的地址看成固有的負(fù)載，因此更容易操作，維護(hù)，相對(duì)于“全部打包”模式和NAT模式，更容易排錯(cuò)。
接下來(lái)可能會(huì)問(wèn)：“如果需要跟一個(gè)不在實(shí)例地址空間的服務(wù)通訊，怎么辦?”，那么解答如下。
如果此服務(wù)被網(wǎng)(fabric)提供，強(qiáng)烈建議這些服務(wù)都采用IPv6。然后，可以使用DC-SIIT模式，這樣IPv4節(jié)點(diǎn)并不知道在跟IPv6節(jié)點(diǎn)通訊。如果不可行，那么有狀態(tài)的464-XLAT可以被用于從一個(gè)重疊的IPv4實(shí)例訪問(wèn)外部IPV4目的地址。
將策略和連接性解耦
最后一個(gè)迷惑也來(lái)自于90年代的，在那個(gè)網(wǎng)絡(luò)暗黑年代，唯一一個(gè)給大型網(wǎng)絡(luò)部署策略的方法就是通過(guò)防火墻，這也是三層模式的緣由。每一層(前端，應(yīng)用，數(shù)據(jù)庫(kù))通過(guò)物理防火墻端口互相隔離，同一層內(nèi)所有節(jié)點(diǎn)都連接到同一個(gè)防火墻端口。這使得監(jiān)控和管理變的容易。至少，當(dāng)我們討論物理節(jié)點(diǎn)是很容易。更進(jìn)一步，這種模型中，把策略和連通性合并了。連通性通過(guò)策略控制點(diǎn)提供。然而，本身他們都是不同的概念。一個(gè)是“我怎么能到那里?”，另外一個(gè)是“我能去哪兒?jiǎn)?本來(lái)不可以被合并的，然而不行的是，在這種模型中，他們被合并了。
很多人仍然認(rèn)為他們的想法是業(yè)界最佳實(shí)踐，有時(shí)被稱為“隔離”或者“服務(wù)接入”。然而我們并不在討論物理設(shè)備。。。。
[page]集中化 SPOFs ( firewalls) 更容易些嗎?
如果我們吧這種模式引入到可擴(kuò)展年代，我們會(huì)看到很有趣的模式。如果我們使用三層模式，那么我們會(huì)有很多應(yīng)用服務(wù)器分布在數(shù)據(jù)中心的所有容器中，可以作為可移動(dòng)負(fù)載飄移。我們也會(huì)有很多web前端具有相似的配置。實(shí)際上，某些 web前端可能跟一些應(yīng)用在同一個(gè)物理節(jié)點(diǎn)上。然而，我們也有虛擬防火墻容器，很可能，在大網(wǎng)里(或者其他一些節(jié)點(diǎn)上)。那么，一個(gè)應(yīng)用服務(wù)如何跟web 前端通訊呢?必須經(jīng)歷 IP→Ethernet→VXLAN→IP打包過(guò)程，最后通過(guò)數(shù)據(jù)中心網(wǎng)絡(luò)發(fā)送到防火墻，在這里逐層解包，最終剩下最里面的IP包信息。防火墻檢查此包，決定是否允許發(fā)送，然后重新打包，發(fā)送到web前端服務(wù)器，在這里數(shù)據(jù)包被再次解包，最內(nèi)部IP信息被web服務(wù)器收取。看起來(lái)效率很低。。
下一個(gè)問(wèn)題是“防火墻”。是的，這是一個(gè)單節(jié)點(diǎn)提供的服務(wù)，因此，是一個(gè)單點(diǎn)故障。可以有多個(gè)防火墻，但是每個(gè)防火墻保持同步。防火墻高可用是一個(gè)有趣的問(wèn)題，會(huì)帶來(lái)很多麻煩。。。。
因此，這樣一個(gè)大規(guī)模可擴(kuò)展的，彈性的三層應(yīng)用模式，所有內(nèi)部流量負(fù)載都記過(guò)一個(gè)單點(diǎn)故障或者脆弱HA能力的防火墻。我覺(jué)得沒(méi)必要再說(shuō)下去了，而且在如今大型數(shù)據(jù)中心中也會(huì)發(fā)現(xiàn)這種架構(gòu)。
三層架構(gòu)可能會(huì)慢慢被拋棄。當(dāng)應(yīng)用之間各自獨(dú)立，不需要互相合作(互相只對(duì)應(yīng)用本身而不是對(duì)方的數(shù)據(jù)感興趣)。今天應(yīng)用棧更面向互連(更多東西向而不是南北向)。這種模式下，三層模式會(huì)對(duì)開(kāi)發(fā)帶來(lái)災(zāi)難。也許到了拋棄這種模式的時(shí)候。
Scale out應(yīng)該是一種橫向的，平面化的模式
好了，現(xiàn)在我們清楚了基于單點(diǎn)故障的三層模式的問(wèn)題，這也是Calico產(chǎn)生的原因。三層結(jié)構(gòu)得以推廣很重要一點(diǎn)是因?yàn)榘寻踩植嫉蕉鄠€(gè)服務(wù)點(diǎn)會(huì)很痛苦。對(duì)于一小部分公司而言，自動(dòng)化網(wǎng)絡(luò)配置會(huì)同構(gòu)郵件發(fā)送到維護(hù)人員。這樣，防火墻提供商就可以獨(dú)立出來(lái)，提供一個(gè)獨(dú)自的地方配置安全策略。
從那開(kāi)始，可擴(kuò)展式環(huán)境出現(xiàn)了很多自動(dòng)化的配置的方式。如果沒(méi)有的話，我們也就不會(huì)有這個(gè)討論，因?yàn)檎麄€(gè)云模式就會(huì)不穩(wěn)定。我們需要一種自動(dòng)部署 “奶牛”的方式，現(xiàn)在我們已經(jīng)有了(比如Ansible,Puppet，Chef，etcd/confd，以及其他)。通過(guò)他們可以一次性將配置推送到上千臺(tái)服務(wù)點(diǎn)。在Calico，我們會(huì)使用每臺(tái)服務(wù)器上的代理對(duì)路由和策略編程，使用BGP和etcd將數(shù)據(jù)推送到所有其他Calico節(jié)點(diǎn)。這種機(jī)制保證 Calico策略的同步。
我們?cè)贑alico網(wǎng)絡(luò)第一跳和最后一跳安裝和管理策略，相對(duì)于中心化的防火墻模式這種模式引起很多關(guān)于安全的爭(zhēng)論。
我們可以簡(jiǎn)化這個(gè)規(guī)則為：每個(gè)Calico節(jié)點(diǎn)只跟連接到這個(gè)節(jié)點(diǎn)上的特殊服務(wù)點(diǎn)合作。但是我們沒(méi)有SPOF問(wèn)題，因?yàn)檫@個(gè)規(guī)則只對(duì)本節(jié)點(diǎn)起作用。一個(gè)節(jié)點(diǎn)失效只影響它容納的服務(wù)點(diǎn)。
最后，我們解耦可連接性和策略。我們使用BGP來(lái)分發(fā)網(wǎng)絡(luò)拓?fù)洌嬖V每個(gè)節(jié)點(diǎn)如何獲得每個(gè)服務(wù)點(diǎn)以便兩個(gè)服務(wù)點(diǎn)進(jìn)行通訊。我們使用策略來(lái)決定這兩個(gè)節(jié)點(diǎn)是否應(yīng)該通訊，如果需要，怎么做?如果策略改變了，兩個(gè)以前不需要通訊的服務(wù)點(diǎn)現(xiàn)在需要通訊，我們需要做的只是更新策略，而鏈接信息不需要改變。如果以后，他們需要拒絕通訊，可以再次更新策略，而連接性仍然不需要修改。應(yīng)用變化和適應(yīng)新世界，這種模式帶來(lái)的靈活性是附帶的福利。
關(guān)于性能的建議
我們也經(jīng)常聽(tīng)說(shuō)linux世界中轉(zhuǎn)發(fā)性能問(wèn)題，我們也需要仔細(xì)想想。假設(shè)你有一個(gè)服務(wù)器，連接到10GE網(wǎng)絡(luò)上，當(dāng)然希望獲得線速(或者至少接近線速)，結(jié)果會(huì)是什么樣呢?如你所愿。那些采用linux系統(tǒng)，只能獲得1-2Gbps的吞吐量的日子已經(jīng)成為過(guò)去了(如果不是的話，為什么人們現(xiàn)在會(huì)把10GE網(wǎng)卡作為標(biāo)配呢?)。實(shí)際上，最近我聽(tīng)一個(gè)朋友說(shuō)他們?cè)趦蓚€(gè)用100GE連接的節(jié)點(diǎn)間獲得了97Gbps的帶寬。知道嗎?所有這些流量都是直接經(jīng)過(guò)linux核心發(fā)送的。可以占滿10GE網(wǎng)口的服務(wù)器一般都是運(yùn)行在Linux Kernel級(jí)別上發(fā)送數(shù)據(jù)。有些同事卡在一個(gè)方向上linux性能不好，而另外一個(gè)方向上卻很好，我感到很困惑，因?yàn)樵谝话闱闆r下，任何從linux服務(wù)器出來(lái)的數(shù)據(jù)包都走的與Calico一樣的轉(zhuǎn)發(fā)路徑。人們?cè)诜?wù)器內(nèi)部愿意買多塊10GE卡，希望達(dá)到25GE，40GE和50GE的帶寬，不僅僅是人們?cè)敢饣ㄥX，更多是因?yàn)檫@樣做確實(shí)可以達(dá)到目標(biāo)。
最后的想法 (恭喜，你讀完了很長(zhǎng)的博客)
我們已經(jīng)走完了21世紀(jì)第二個(gè)十年的一半，應(yīng)該是時(shí)候停下來(lái)用上世紀(jì)90年代企業(yè)架構(gòu)視角來(lái)評(píng)估網(wǎng)絡(luò)，讓90后安靜和平的埋葬他們的網(wǎng)絡(luò)，并且意識(shí)到老一代的模式只可能讓我們?cè)?jīng)拼命脫離的痛苦長(zhǎng)期存在下去。
京公網(wǎng)安備 11010502049343號(hào)