Kubernetes和OpenStack的多雲端網絡

上週，在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概述

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的支持和在測試過程當中做出的貢獻。

原文連接

（若是須要轉載，請聯繫咱們哦，尊重知識產權人人有責）