如何實現Kubernetes和OpenStack的多云端網絡

這篇文章將為大家詳細講解有關如何實現Kubernetes和OpenStack的多云端網絡，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

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(https://github.com/django-leonardo/django-leonardo/blob/master/contrib/haproxy/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發布表明。點擊這里查看：https://github.com/pupapaik/scripts/tree/master/kubernetes/leonardo

為了使之順利在網絡隔離情況下運行，來看以下部分。

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 replication controller with 3 replicas and virtual networknginx and policy allowing traffic to leonardo-svc network. This sample does notuse SSL.）

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

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

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

只有Nginx service有Public 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的路徑。

關于“如何實現Kubernetes和OpenStack的多云端網絡”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。