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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

概述

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

數(shù)據(jù)庫——PostgreSQL或者MySQL數(shù)據(jù)庫集群

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

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

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

負載均衡——容器縮放的HAProxy負載均衡器

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

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

OpenStack方面

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

Kubernetes方面

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

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個副本的NGINX RC，虛擬網(wǎng)絡(luò)nginx和策略，這三者允許與leonardo－svc 網(wǎng)絡(luò)通信。這個例子不使用SSL。

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

我們來調(diào)用kubecl來運行所有的密鑰清單。

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

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

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

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

這個部分展示的是其它從應(yīng)用堆棧的有趣輸出。用負載均衡器描述的Nginx service展示了浮動IP和私有集群IP。然后是nginx pods的3個IP地址。流量通過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 虛擬機。

最近的輸出是從Juniper MXs VRF出來的，展示了多個到nginx pods的路徑。

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

如果你對這個話題更加感興趣的話，可以為我們的這個文章投票，點擊鏈接：點我。

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

特別感謝來自Juniper的Pedro Marques的支持和在測試過程中作出的貢獻。

原文鏈接

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