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

170次閱讀

共計 3110 個字符，預計需要花費 8 分鐘才能閱讀完成。

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

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 運行完全沒有問題。