摘要：上周，在舉行的上，發(fā)布，整合和。多虧存儲(chǔ)應(yīng)用程序會(huì)話到數(shù)據(jù)庫(kù)通常來(lái)說(shuō)是下載安裝或者是，我們不需要特定的負(fù)載均衡器，運(yùn)行完全沒(méi)有問(wèn)題。用負(fù)載均衡器描述的展示了浮動(dòng)和私有集群。特別感謝來(lái)自的的支持和在測(cè)試過(guò)程中作出的貢獻(xiàn)。

上周，在Austin舉行的OpenStack Summit上，CoreOS發(fā)布Stackanetes，整合Kubernetes和OpenStack。

一個(gè)月前，CoreOS、Intel和Mirantis宣布合作，目標(biāo)是把OpenStack云管理框架搬上K8S，當(dāng)OpenStack出故障時(shí)，能借助K8S的編排機(jī)制以極快的速度重啟OpenStack組件。此番“珠聯(lián)璧合”，卻有之前“相虐相殺”之說(shuō)的鋪墊。

去年11月東京OpenStack峰會(huì)讓我們嗅到了容器的“騰騰殺機(jī)”：每個(gè)人都在談?wù)撊萜?，以及用各種容器編排器在不久的將來(lái)替代虛擬機(jī)！因?yàn)槿萜鞯妮p量級(jí)、易用、部署快速，迅速成為開發(fā)者最愛(ài)，用以輕松建立、維護(hù)、擴(kuò)容和滾動(dòng)更新他們的應(yīng)用程序。

以下讓我們來(lái)看一篇技術(shù)帖，描述如何基于Kubernetes，在TCP云端創(chuàng)建私有云解決方法，運(yùn)用在生產(chǎn)或是在OpenStack啟動(dòng)的虛擬化。

Kubernetes帶來(lái)一個(gè)嶄新的方法來(lái)管理基于容器的工作負(fù)載，并且為虛擬機(jī)開啟類似于OpenStack的功能。如果你開始使用Kubernetes，你很快會(huì)感受到輕松在AWS、GCE或者Vagrant上部署的快感，但是你的本地邏輯部署怎么樣呢？如何將其整合到你目前的OpenStack或者虛擬基礎(chǔ)設(shè)施上呢？所有的博客帖和手冊(cè)文檔用文件證明用簡(jiǎn)單的網(wǎng)頁(yè)程序跑在虛擬機(jī)上的小集群，但是目前的網(wǎng)絡(luò)設(shè)計(jì)卻沒(méi)有能夠?yàn)槁銠C(jī)或者企業(yè)性能負(fù)載展示真實(shí)場(chǎng)景。設(shè)計(jì)網(wǎng)絡(luò)是架構(gòu)設(shè)計(jì)中最難的部分，就好比使用OpenStack。因此，我們來(lái)定義以下網(wǎng)絡(luò)需求：

多租戶——容器工作負(fù)載是每個(gè)安全策略標(biāo)準(zhǔn)的基礎(chǔ)要求。例如，默認(rèn)的Flannel網(wǎng)絡(luò)只提供平坦的網(wǎng)絡(luò)體系結(jié)構(gòu)。

多云端支持——不是每個(gè)工作負(fù)載都適用于容器的，你仍然需要將像數(shù)據(jù)庫(kù)一個(gè)的重負(fù)載放到虛擬機(jī)或者裸機(jī)里。由于這個(gè)原因，單個(gè)控制面板是最好的選擇

多云端支持——不是每個(gè)工作負(fù)載都適用于容器的，你仍然需要將像數(shù)據(jù)庫(kù)一個(gè)的重負(fù)載放到虛擬機(jī)或者裸機(jī)里。由于這個(gè)原因，單個(gè)控制面板是最好的選擇

分布式路徑引擎——東西和南北流量無(wú)法通過(guò)同一個(gè)中央軟件服務(wù)。網(wǎng)絡(luò)流量不得不在OpenStack計(jì)算節(jié)點(diǎn)和Kubernetes節(jié)點(diǎn)之間走動(dòng)。最優(yōu)方案就是在路由器上面提供路由，而不是專用網(wǎng)關(guān)設(shè)備。

基于這些需求，我們決定首先開始使用OpenContrail SDN，我們的任務(wù)是將OpenStack和Kubernetes整合到一起，然后為實(shí)際負(fù)載測(cè)試找一個(gè)合適的應(yīng)用程式堆棧。

OpenContrail是一個(gè)開源SDN&NFV解決方案，從Havana開始，跟OpenStack有著些許的聯(lián)系。它和Nicira（現(xiàn)在的VMware NSX－VH）是第一個(gè)產(chǎn)品Neutron插件，上一屆峰會(huì)調(diào)查顯示，它也是最常被配置的解決方案，排名僅在OpenVwitch之后，是第一個(gè)基于Vendor的解決方案。

OpenContrail已經(jīng)整合到OpenStack、VMware、Docker和Kubernetes上了。Kubernetes 網(wǎng)絡(luò)插件 kube-network-manager早在去年于溫哥華舉辦的OpenStack峰會(huì)的時(shí)候已經(jīng)在開發(fā)當(dāng)中了，于去年年底首次發(fā)布。

我們從兩個(gè)獨(dú)立的Contrail配置開始測(cè)試，然后安裝BGP聯(lián)盟。聯(lián)盟的原因是kube-network-manager的重點(diǎn)驗(yàn)證。當(dāng)啟用contrail－neutron－plugin開啟的時(shí)候，contrail API啟用keystone驗(yàn)證的時(shí)候，contrail API用keystone驗(yàn)證，這個(gè)功能還沒(méi)有在Kubernetes插件實(shí)施。Contrail聯(lián)盟等下會(huì)詳細(xì)描述。

下面的這個(gè)架構(gòu)是一個(gè)高水平架構(gòu)圖，圖中左邊是OpenStack集群，右邊是Kubernetes集群。OpenStack和OpenContrail被部署在高可得性的最佳實(shí)踐設(shè)計(jì)中，這個(gè)設(shè)計(jì)可以被擴(kuò)容成成百上千個(gè)計(jì)算節(jié)點(diǎn)。

下圖展示了兩個(gè)Contrail集群的聯(lián)盟?？傮w上，這個(gè)功能在不需要物理網(wǎng)關(guān)的情況下可以連接Contrail controllers與多站點(diǎn)數(shù)據(jù)中心的站點(diǎn)。每個(gè)站點(diǎn)的控制節(jié)點(diǎn)和其它使用BGP的站點(diǎn)一樣。有可能的話，可以用這種方法延伸到L2和L3網(wǎng)絡(luò)在多個(gè)數(shù)據(jù)中心上面。

通常，兩個(gè)獨(dú)立的OpenStack云端或者兩個(gè)OpenStack區(qū)域會(huì)用到這個(gè)設(shè)計(jì)。所有的Contrail的組件（包括vRouter）是一樣的。Kube－network－manager和neutron－contrail－plugin為不同的平臺(tái)轉(zhuǎn)換API請(qǐng)求。網(wǎng)絡(luò)解決方案的核心功能還是沒(méi)有改變。這不僅帶來(lái)強(qiáng)大的網(wǎng)絡(luò)引擎，還帶來(lái)了分析。

概述

讓我們來(lái)看看典型的場(chǎng)景。我們的開發(fā)人員給了我們docker compose.yml(點(diǎn)我)，這也是為在筆記本上的開發(fā)和本地測(cè)試所用。這個(gè)方法更加輕松，但是我們的開發(fā)者已經(jīng)了解過(guò)docker和應(yīng)用程序工作負(fù)載。這個(gè)應(yīng)用程序堆棧包括以下組件：

數(shù)據(jù)庫(kù)——PostgreSQL或者M(jìn)ySQL數(shù)據(jù)庫(kù)集群

下載并安裝——為內(nèi)容緩存

Django 應(yīng)用 Leonardo——Django CMS Leonardo被用于應(yīng)用程序堆棧測(cè)試

Nginx——網(wǎng)絡(luò)代理

負(fù)載均衡——容器縮放的HAProxy負(fù)載均衡器

當(dāng)我們想將之運(yùn)用到產(chǎn)品中的時(shí)候，我們可以將所有東西和service一起轉(zhuǎn)移到Kubernetes RC上面，但是就如我們?cè)谝婚_始提到的，不是所有的東西都適用于容器。因此，我們將數(shù)據(jù)庫(kù)集群分開到OpenStack虛擬機(jī)，然后將剩下的部分重寫到Kubernetes密鑰清單。

這個(gè)部分描述了在OpenStack和Kubernetes上的應(yīng)用程序供應(yīng)的工作流程。

OpenStack方面

第一步，我們已經(jīng)在OpenStack上正式推出數(shù)據(jù)庫(kù)堆棧。這就用PostgreSQL和數(shù)據(jù)庫(kù)網(wǎng)絡(luò)創(chuàng)建了3個(gè)虛擬機(jī)。數(shù)據(jù)庫(kù)網(wǎng)絡(luò)是私人租戶隔離網(wǎng)絡(luò)。

Kubernetes方面

在Kubernetes這邊，我們不得不用Leonardo和Nginx services發(fā)布表明。點(diǎn)擊這里查看：點(diǎn)我 為了使之順利在網(wǎng)絡(luò)隔離情況下運(yùn)行，來(lái)看以下部分。

leonardo-rc.yaml－Leonardo應(yīng)用的RC，replicas3，和虛擬網(wǎng)絡(luò)leonardo

leonardo－svc.yaml－leonardo service 用虛擬IP在端口8000從集群網(wǎng)絡(luò)掛載應(yīng)用程序pods。

nginx－rc.yaml－3個(gè)副本的NGINX RC，虛擬網(wǎng)絡(luò)nginx和策略，這三者允許與leonardo－svc 網(wǎng)絡(luò)通信。這個(gè)例子不使用SSL。

nginx－svc.yaml－用集群vip IP和虛擬IP創(chuàng)建service，從網(wǎng)絡(luò)上訪問(wèn)應(yīng)用程序

我們來(lái)調(diào)用kubecl來(lái)運(yùn)行所有的密鑰清單。

在Kubernetes里創(chuàng)建了以下的pods和services。

只有Nginx service有公共IP 185.22.97.188，這是一個(gè)負(fù)載均衡的浮動(dòng)IP。所有的流量現(xiàn)在已經(jīng)在Juniper MX上面被ECMP平衡。為了讓集群完全運(yùn)行起來(lái)，就必須在OpenStack上的數(shù)據(jù)庫(kù)虛擬網(wǎng)絡(luò)和Kubernetes Contrail上的leonardo 虛擬網(wǎng)絡(luò)。進(jìn)入這兩個(gè)Contrail UI，然后為這兩個(gè)網(wǎng)絡(luò)設(shè)置一樣的Route Target。這也可以通過(guò)contrail 資源（heat resource）來(lái)進(jìn)行自動(dòng)化。

下面的這張圖展示了應(yīng)該怎樣查看產(chǎn)品應(yīng)用程序堆棧。在最上面是兩個(gè)有Public VRF的Juniper MXs，就是浮動(dòng)IP傳播的地方。流量通過(guò)ECMP到MPLSoverGRE隧道傳播到3個(gè)nginx pods。Nginx代理請(qǐng)求到Leonardo應(yīng)用程序服務(wù)器，它將會(huì)議和內(nèi)容存儲(chǔ)到運(yùn)行在OpenStack 虛擬機(jī)上的PostgreSQL數(shù)據(jù)庫(kù)集群。

pods和虛擬機(jī)間的連接是直接的，沒(méi)有任何路由中心點(diǎn)的。Juniper MXs只運(yùn)用于外向連接到互聯(lián)網(wǎng)。多虧存儲(chǔ)應(yīng)用程序會(huì)話到數(shù)據(jù)庫(kù)（通常來(lái)說(shuō)是下載安裝或者是redis），我們不需要特定的L7負(fù)載均衡器，ECMP運(yùn)行完全沒(méi)有問(wèn)題。

這個(gè)部分展示的是其它從應(yīng)用堆棧的有趣輸出。用負(fù)載均衡器描述的Nginx service展示了浮動(dòng)IP和私有集群IP。然后是nginx pods的3個(gè)IP地址。流量通過(guò)vRouter ECMP分布。

Nginx路由表展示了pods和route10.254.98.15／32間的內(nèi)部路由，指向leonardo service。

之前的route10.254.98.15／32是leonardo service里面的描述。

Leonardo路由表跟nginx十分相似，除了routes 10.0.100.X／32，他在不同的Contrail里指向OpenStack 虛擬機(jī)。

最近的輸出是從Juniper MXs VRF出來(lái)的，展示了多個(gè)到nginx pods的路徑。

我們已經(jīng)證明，OpenStack、Kubernetes、裸機(jī)和VMware vCenter可以使用單個(gè)SDN解決方案。更重要的一點(diǎn)是，這個(gè)使用案例實(shí)際上可以為生產(chǎn)環(huán)境所用。

如果你對(duì)這個(gè)話題更加感興趣的話，可以為我們的這個(gè)文章投票，點(diǎn)擊鏈接：點(diǎn)我。

目前，我們正處理Kubernetes網(wǎng)絡(luò)堆棧的要求，然后提供不同Kubernetes網(wǎng)絡(luò)插件，比如Weave、Calico、Open VSwitch、Flannel和250個(gè)裸機(jī)服務(wù)器的Contrail等，這幾個(gè)插件間的對(duì)照。
我們也在用Kubernetes備份來(lái)處理OpenStack Magnum，給開發(fā)者帶來(lái)簡(jiǎn)單測(cè)試和開發(fā)的自助服務(wù)門戶。然后他們就能夠在OpenStack虛擬機(jī)里準(zhǔn)備應(yīng)用程序密鑰清單，然后推動(dòng)最終生產(chǎn)定義的修改到git，最后在生產(chǎn)過(guò)程中使用它們。

特別感謝來(lái)自Juniper的Pedro Marques的支持和在測(cè)試過(guò)程中作出的貢獻(xiàn)。

原文鏈接

（如果需要轉(zhuǎn)載，請(qǐng)聯(lián)系我們哦，尊重知識(shí)產(chǎn)權(quán)人人有責(zé)）