紅藍出 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 排版