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

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

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

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

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

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

多租戶——容器工作負載是每個安全策略標準的基礎要求。例如，默認的Flannel網絡只提供平坦的網絡體系結構。

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

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

分布式路徑引擎——東西和南北流量無法通過同一個中央軟件服務。網絡流量不得不在OpenStack計算節點和Kubernetes節點之間走動。最優方案就是在路由器上面提供路由，而不是專用網關設備。

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

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

OpenContrail已經整合到OpenStack、VMware、Docker和Kubernetes上了。Kubernetes 網絡插件 kube-network-manager早在去年于溫哥華舉辦的OpenStack峰會的時候已經在開發當中了，于去年年底首次發布。

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

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

下圖展示了兩個Contrail集群的聯盟。總體上，這個功能在不需要物理網關的情況下可以連接Contrail controllers與多站點數據中心的站點。每個站點的控制節點和其它使用BGP的站點一樣。有可能的話，可以用這種方法延伸到L2和L3網絡在多個數據中心上面。

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

概述

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

數據庫——PostgreSQL或者MySQL數據庫集群

下載并安裝——為內容緩存

Django 應用 Leonardo——Django CMS Leonardo被用于應用程序堆棧測試

Nginx——網絡代理

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

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

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

OpenStack方面

第一步，我們已經在OpenStack上正式推出數據庫堆棧。這就用PostgreSQL和數據庫網絡創建了3個虛擬機。數據庫網絡是私人租戶隔離網絡。

Kubernetes方面

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

leonardo-rc.yaml－Leonardo應用的RC，replicas3，和虛擬網絡leonardo

leonardo－svc.yaml－leonardo service 用虛擬IP在端口8000從集群網絡掛載應用程序pods。

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

nginx－svc.yaml－用集群vip IP和虛擬IP創建service，從網絡上訪問應用程序

我們來調用kubecl來運行所有的密鑰清單。

在Kubernetes里創建了以下的pods和services。

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

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

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

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

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

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

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

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

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

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

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

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

原文鏈接

（如果需要轉載，請聯系我們哦，尊重知識產權人人有責）