這篇文章主要介紹Tungsten Fabric安裝的示例分析，文中介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們一定要看完！
創(chuàng)新互聯(lián)建站專(zhuān)業(yè)為企業(yè)提供柳南網(wǎng)站建設(shè)、柳南做網(wǎng)站、柳南網(wǎng)站設(shè)計(jì)、柳南網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁(yè)設(shè)計(jì)與制作、柳南企業(yè)網(wǎng)站模板建站服務(wù)，十多年柳南做網(wǎng)站經(jīng)驗(yàn)，不只是建網(wǎng)站，更提供有價(jià)值的思路和整體網(wǎng)絡(luò)服務(wù)。
如果計(jì)劃設(shè)置用于關(guān)鍵流量，則始終需要使用HA。
Tungsten Fabric擁有不錯(cuò)的HA實(shí)施，已經(jīng)以下的文檔中有相關(guān)信息。
http://www.opencontrail.org/opencontrail-architecture-documentation/#section2_7
這里我想多說(shuō)的一件事，cassandra的keyspace在configdb和analyticsdb之間具有不同的replication-factor。
configdb:
https://github.com/Juniper/contrail-controller/blob/master/src/config/common/vnc_cassandra.py#L609
analytics:
https://github.com/Juniper/contrail-analytics/blob/master/contrail-collector/db_handler.cc#L524
由于configdb的數(shù)據(jù)已復(fù)制到所有的cassandras，因此即使某些節(jié)點(diǎn)的磁盤(pán)崩潰并需要抹掉，也不太可能丟失數(shù)據(jù)。另一方面，由于analyticsdb的replication-factor始終設(shè)置為2，因此如果兩個(gè)節(jié)點(diǎn)同時(shí)丟失數(shù)據(jù)，那么數(shù)據(jù)就可能會(huì)丟失。
在安裝Tungsten Fabric時(shí)，許多情況下都需要進(jìn)行多NIC安裝，例如用于管理平面和控制/數(shù)據(jù)平面的，都是單獨(dú)的NIC。
綁定（bonding）不在此討論中，因?yàn)閎ond0可以直接由VROUTER_GATEWAY參數(shù)指定
我需要明確一下在此設(shè)置中vRouter的有趣的行為。
對(duì)于controller/analytics來(lái)說(shuō)，與典型的Linux安裝并沒(méi)有太大區(qū)別，這是因?yàn)長(zhǎng)inux可以與多個(gè)NIC和其自己的路由表（包括使用靜態(tài)路由）很好地協(xié)同工作。
另一方面，在vRouter節(jié)點(diǎn)中您需要注意的是，vRouter在發(fā)送報(bào)文時(shí)不會(huì)使用Linux路由表，而是始終將報(bào)文發(fā)送到網(wǎng)關(guān)IP。
這可以使用concert-vrouter-agent.conf中的網(wǎng)關(guān)參數(shù)和vrouter-agent容器的環(huán)境變量中的VROUTER_GATEWAY進(jìn)行設(shè)置
因此，在設(shè)置多NIC安裝時(shí)，如果需要指定VROUTER_GATEWAY，那么您需要小心一點(diǎn)。
如果沒(méi)有指明，并且Internet訪問(wèn)的路由（0.0.0.0/0）是由管理NIC而不是數(shù)據(jù)平面NIC所覆蓋，那么vrouter-agent容器將選擇保存該節(jié)點(diǎn)默認(rèn)路由的NIC，盡管那不會(huì)是正確的NIC。
在這種情況下，您需要顯式指定VROUTER_GATEWAY參數(shù)。
由于這些行為的存在，當(dāng)您要將報(bào)文從虛擬機(jī)或容器發(fā)送到NIC（除了vRouter使用的NIC之外的其它NIC）時(shí)，仍然需要謹(jǐn)慎一些，因?yàn)樗瑯硬粫?huì)檢查L(zhǎng)inux路由表，并且它始終使用與其它vRouter通信相同的NIC。
據(jù)我所知，來(lái)自本地鏈接服務(wù)或無(wú)網(wǎng)關(guān)的報(bào)文也顯示出類(lèi)似的行為
在這種情況下，您可能需要使用簡(jiǎn)單網(wǎng)關(guān)（simple-gateway）或SR-IOV。
https://github.com/Juniper/contrail-controller/wiki/Simple-Gateway
對(duì)于Tungsten Fabric集群的一般規(guī)格（sizing），您可以使用下面的表。
https://github.com/hartmutschroeder/contrailandrhosp10#21sizing-the-controller-nodes-and-vms
如果集群規(guī)模很大，則需要大量資源來(lái)保障控制平面的穩(wěn)定。
請(qǐng)注意，從5.1版本開(kāi)始，analytics數(shù)據(jù)庫(kù)（以及analytics的某些組件）成為了可選項(xiàng)。因此，如果您只想使用Tungsten Fabric中的控制平面，我建議使用5.1版本。
https://github.com/Juniper/contrail-analytics/blob/master/specs/analytics_optional_components.md
盡管沒(méi)有一個(gè)方便的答案，但集群的大小也是很重要的，因?yàn)樗Q于很多因素。
我曾經(jīng)嘗試用一個(gè)K8s集群（ https://kubernetes.io/docs/setup/cluster-large/）部署了近5,000個(gè)節(jié)點(diǎn)。在它與一個(gè)具有64個(gè)vCPU和58GB內(nèi)存的控制器節(jié)點(diǎn)配合使用時(shí)效果很不錯(cuò)，盡管當(dāng)時(shí)我并沒(méi)有創(chuàng)建太多的端口、策略和邏輯路由器等。
這個(gè)Wiki也描述了一些有關(guān)海量規(guī)模集群的真實(shí)經(jīng)驗(yàn)：
https://wiki.tungsten.io/display/TUN/KubeCon+NA+in+Seattle+2018
由于可以隨時(shí)從云中獲取大量資源，因此最好的選擇應(yīng)該是按照實(shí)際需求的大小和流量來(lái)模擬集群，并查看其是否正常運(yùn)行，以及瓶頸是什么。
Tungsten Fabric在應(yīng)對(duì)海量規(guī)模方面擁有一些很好的功能，例如，基于集群之間的MP-BGP的多集群設(shè)置，以及基于3層虛擬網(wǎng)絡(luò)的BUM丟棄功能，這大概就是其具備可擴(kuò)展性和穩(wěn)定性虛擬網(wǎng)絡(luò)的關(guān)鍵。
https://bugs.launchpad.net/juniperopenstack/+bug/1471637
為了說(shuō)明控件的橫向擴(kuò)展行為，我在AWS中創(chuàng)建了一個(gè)包含980個(gè)vRouter和15個(gè)控件的集群。
所有控制節(jié)點(diǎn)均具有4個(gè)vCPU和16GB內(nèi)存
當(dāng)控制節(jié)點(diǎn)的數(shù)量為15時(shí)，XMPP的連接數(shù)最多只有113，因此CPU使用率不是很高（最高只有5.4％）。
但是，當(dāng)其中12個(gè)控制節(jié)點(diǎn)停止工作時(shí)，剩余的每個(gè)控制節(jié)點(diǎn)的XMPP連接數(shù)將高達(dá)708，因此CPU使用率變得很高（21.6％）。
因此，如果您需要部署大量的節(jié)點(diǎn)，那么可能需要仔細(xì)規(guī)劃控制節(jié)點(diǎn)的數(shù)量。
在撰寫(xiě)本文檔時(shí)，ansible-deployer尚未支持K8s master HA。
https://bugs.launchpad.net/juniperopenstack/+bug/1761137
由于kubeadm已經(jīng)支持K8s master HA，因此我將介紹集成基于kubeadm的k8s安裝和基于YAML的Tungsten Fabric安裝的方法。
https://kubernetes.io/docs/setup/independent/high-availability/
https://github.com/Juniper/contrail-ansible-deployer/wiki/Provision-Contrail-Kubernetes-Cluster-in-Non-nested-Mode
與其它CNI一樣，也可以通過(guò)“kubectl apply”命令直接安裝Tungsten Fabric。但要實(shí)現(xiàn)此目的，需要手動(dòng)配置一些參數(shù)，例如控制器節(jié)點(diǎn)的IP地址。
對(duì)于此示例的設(shè)置，我使用了5個(gè)EC2實(shí)例（AMI也一樣，ami-3185744e），每個(gè)實(shí)例具有2個(gè)vCPU、8 GB內(nèi)存、20 GB磁盤(pán)空間。VPC的CIDR為172.31.0.0/16。
我將附上一些原始和修改的yaml文件以供進(jìn)一步參考。
https://github.com/tnaganawa/tungstenfabric-docs/blob/master/cni-tungsten-fabric.yaml.orig
https://github.com/tnaganawa/tungstenfabric-docs/blob/master/cni-tungsten-fabric.yaml
然后，您終于有了（多數(shù)情況下）已經(jīng)啟動(dòng)了的具有Tungsten Fabric CNI的kubernetes HA環(huán)境。
注意：CoreDNS在此輸出中未處于活動(dòng)狀態(tài)，我將在本節(jié)稍后的部分對(duì)此進(jìn)行修復(fù)。
在創(chuàng)建cirros部署后，就像“啟動(dòng)并運(yùn)行”部分所描述的一樣，兩個(gè)vRouter節(jié)點(diǎn)之間已經(jīng)可以ping通了。
輸出是相同的，但現(xiàn)在在兩個(gè)vRouter之間使用的是MPLS封裝！
注意：要使coredns處于活動(dòng)狀態(tài)，需要進(jìn)行兩項(xiàng)更改。
終于，coredns也處于活動(dòng)狀態(tài)，集群已完全啟動(dòng)！
以上是“Tungsten Fabric安裝的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對(duì)大家有幫助，更多相關(guān)知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！
重慶分公司
重慶分公司
