紅藍出 CP，OpenStack 和 Kubernetes 在一起會怎樣？
背景
從去年開始就想深入地學習 Kubernetes，首先想到是在 OpenStack 上能比較輕松地玩轉，所以去 嘗試了 Magnum ，但是結果令人失望。
不過隨着我搜索到更多的內容，發現一個有趣的事情：
那就是相較於在 OpenStack 之上部署 Kubernetes，通過 Kubernetes 去部署 OpenStack 似乎更流行。
特別當我去研究最近比較熱門的邊緣計算，發現 OpenStack 社區的兩個相關項目，一個是 StarlingX，一個是 Airship，它們都是這樣做的：先搭建 Kubernetes 集群，然后通過 OpenStack-Helm 部署容器化的 OpenStack。
但是這兩個項目都還挺復雜，直接去部署它們遇到了不少坑，做了很多的前置操作，涉及到很多腳本代碼，結果到搭建 K8s 步驟上還是卡住了。
於是我決定暫時先不管它們，直接跳到 OpenStack-Helm，至少讓我先體驗一下基於 Kubernetes 的 OpenStack 到底是啥樣。
這樣就又回到了起點：我得先有一套 Kubernetes 多節點集群，但是現在只有一套 OpenStack 環境，所以我仍然得先解決在 OpenStack 上搭建 Kubernetes 的問題。
經過了一番摸索，踩了不少坑，最后終於完成了這次嘗試。
下面簡單地分享下最終的效果，其中的過程涉及較多，后續再擇機分享。
整個環境概況
最上層：一個普通的 OpenStack 環境
在上面的 OpenStack 中用 cirros 鏡像創建了一個虛機：
細心的你可能已經發現這里的端口號不是默認的 80，而是比較奇怪的 32557，這是因為這個 openstack 環境是搭建在 Kubernetes 集群上，而且通過 NodePort 暴露的服務。
在頁面上查看 openstack 的系統信息：
各個服務的 endpoints URL 都是以 *.openstack.svc.cluster.local 域名的形式，熟悉 Kubernetes 的應該看上去有點眼熟。
OpenStack 在 Kubernetes 中的細節
下面詳細地看看 OpenStack 在集群中是怎么一回事：
Helm
全部使用 Helm 部署：
Ingress
Public 接口是通過 Ingress 暴露的：
Service
更多的內部接口則可以在 service 中看到：
注意 horizon-int 對應的就是 Dashboard 服務，它的類型是 NodePort 而且映射的端口號是 32557
DaemonSet
各種 agent 包括計算節點、OVS、Libvirt 等，都是通過 DaemonSet :
StatefulSet
帶狀態的數據庫和消息隊列，以 StatefulSet 的形式：
Job
還有部署過程中的各種任務，包括初始化數據庫，注冊 endpoint 等，都是以 job 方式執行的：
Pod
最終所有這些 pod 構成了這個 openstack 環境：
PV 和 PVC
當然還要用到持久化的卷存儲，即 PersistentVolumeClaim 和 PersistentVolume ：
Ceph
持久化存儲由 ceph 提供，它們同樣部署在當前集群中 ：
中間層：Kubernetes on OpenStack
這個 Kubernetes 集群有 4 個節點，1 個 master 節點，3 個 worker 節點：
4 個節點都是底層 OpenStack 環境提供的虛機：
在 openstack 中部署 Kubernetes 的方案很多，在嘗試了其中的一些（包括 magnum）之后，最終使用基於 Ansible 的 Kubespray 部署。為了簡化操作，這套 Kubernetes 集群也並沒有對接底層的 OpenStack。
手動創建了虛機之后，完成這樣一套集群大概需要 20 分鍾：
這里最初的 node-4 不幸被折騰掛了，所以上面顯示的是后面新增的 node-5
最下層：基於 Kolla 的 OpenStack
最底層的 openstack 是搭建在一台物理服務器上的 All-In-One 環境，使用 Kolla 作為部署工具。
Kolla 使用容器來部署 OpenStack，所以可以通過 docker ps 查看服務：
總結和思考
OpenStack 和 Kubernetes 的關系
一直以來 OpenStack 作為 IaaS 層，用來管理底層計算資源，而 Kubernetes 則被視作 PaaS 層，來管理應用和容器。在通常的架構圖中，OpenStack 都是處在 Kubernetes 的下層，作為雲計算平台提供諸如持久卷、負載均衡等資源。
事實上，OpenStack 系統本身就是一個微服務的架構，使用容器化部署，進而使用 Kubernetes 來管理已經是大勢所趨。通過 Kubernetes 強大的容器編排能力，長久以來被詬病的 OpenStack 的部署難，升級難等問題可以得到有效解決。 在這次測試中，當中途遇到錯誤時，處理方式非常「簡單粗暴」，直接刪掉重來。管理面要求高可用？直接改 replicas 就行。Kubernetes 和 Helm 的強大功能令人印象深刻。
同時現在可以無縫引入雲原生社區強大生態，例如 Prometheus，ELK 等，想用的話基本就是一鍵部署和接入。
由於 Kubernetes 基於雲的設計，在私有雲場景下，OpenStack 仍然是 Cloud Provider 的不二選擇。不僅可以提供可用於部署集群的 Node 實例（虛機或裸金屬），也能補充底層網絡/存儲資源的管理能力。
關於實際應用的思考
因為環境所限，這里最上層 OpenStack 已經是二次虛擬化了，顯然沒有實用價值，實際應用中需要有所變化。
我能想到的可行方案：
-
以虛擬機為主要工作負載的，容器作為補充的，可以考慮保留下面兩層，通過 OpenStack 提供基於虛機的 Kubernetes 集群和容器服務。 -
以容器為主要工作負載的，可以考慮僅使用上面兩層，在裸機上部署 Kubernetes。這樣部署在上層的 OpenStack 就是一個用來供給虛機的服務，本質和部署一個網站沒啥區別。 -
結合我們前面介紹的裸金屬技術，保留所有三層，底層的 OpenStack 只負責提供裸金屬實例，這樣上面兩層的作用和上一個方案類似。
當然，顯而易見的，這樣一套架構最大的問題就是太過於復雜。同時引入兩套技術棧，對團隊的要求較高。如果非要二選一，大多數的小公司會作何選擇不言而喻。
你對 Kubernetes 和 OpenStack 之間關系有何想法，歡迎在評論區討論。
感謝你的閱讀，請繼續關注「雲計算實驗室」
本文使用 mdnice 排版