部署工具見解之Kubernetes

認真的說，你應該在Kubernetes上構建你的系統。

對我來說，對Kubernetes理解的很大轉變來自於我開始思考它能提供什麼，比如副本控制器、服務、pod等等。當然，你可以寫一些yaml 文件來部署一些風格多樣的東西。但是，有時候它可以更有用的在更高的層次上溝通事情。

通常情況下，考慮部署一個應用到一個PaaS平台。對Heroku來說，你運行git push；對Google App Engine來說，你運行appcfg.py update。平台會處理創建和配置自己的一系列資源來運行你的應用。你不需要去考慮「我需要一個副本控制器，一個服務，等等」。你只需要簡單的一步來部署你的代碼。在PaaS中，你不再擔憂運行你的應用所需要的資源。

我感覺在Kubernetes 上構建這種類型的工作流是一個連接開發和DevOps 之間差異的臨界點。開發者通常過於關注平台怎麼處理應用的部署。他們寫代碼，然後需要一種方式來表示「這些準備部署」。DevOps 應該做這些。

Kubernetes 提供給我們工具來構建PaaS。事實上，這是一個好主意。Deis現在重新在Kubernetes 上構建了Deis v2。雖然你能明確定義部署你的應用所需要的各種Kubernetes 資源，但是你不需要這樣做。事實上，它可能是一種被反對的形式。

我決定去看看在Kubernetes上創建一個工具來提供一個『最低限度』的PaaS工作流有多困難。一個『最低限度』的PaaS需要提供：

1. 零配置部署：部署代碼唯一需要的只有Dockfile文件。

2. 多個應用／微服務：PaaS 應該能夠容納任意數量的應用／微服務，它們之間能夠互相通信。

3. 擴容：集群管理員應該能夠簡單的手動擴容或縮減應用。

4. 配置管理：提供獨立於代碼的方式來設置配置值，就像12 factor app中說的那樣。

創建這個工具時，我決定試著在Dokku和Deis中選擇一個。它們都提供了一個偉大的、簡單的開發者體驗。我決定提供兩種應用開發的流程：

1. 本地構建：你能在一個包含Dockfile的目錄下運行noel build-and-deploy，來構建部署一個應用。這是和Google App Engine最相似的工作方式。

2. 遠程構建：你能添加一個具體的遠程服務區，然後運行git push noel master讓遠端構建並部署一個應用。

這些當前都對開發者提供了一種比直接跟Kubernetes 集群溝通更簡單的工作流程。

Noel當前發布在GitHub上。這裡有一個使用遠程構建流程來部署一個簡單應用的示例。一旦部署完成，你能看到應用僅需幾秒鐘的時間來啟動並提供服務。

Noel使用以下的幾種Kubernetes 資源來將應用部署到集群中：

1. 副本控制器：Noel 為部署的應用的每一個版本創建一個唯一的副本控制器。以後，Kubernetes 的部署API 能夠用來回滾更新來避免停機。

2. 密鑰：每一個應用有一個密鑰用來存儲應用配置。Noel 配置應用的副本控制器來在pod中掛載密鑰。

3. 服務：每一個應用有一個服務來控制集群內部的流量到自己的pod 里。這允許應用／微服務在集群內部能直接互相通信。

Noel自己在集群中運行兩個服務：

1. 遠程構建：處理git push請求，並運行noel build-and-deploy來構建和部署應用。

2. 前端Nginx：處理代理的來自app.example.com的外部請求，到適當的應用的服務。

混合模式的集群

Noel，使用Nodel部署的應用，也能夠和其他部署在集群中的任何應用一起。這是Kubnertes 中很重要的一個方面。考慮有一個應用由三個微服務組成，並且需要Redis和PostgreSQL。這個微服務是無狀態的，能夠簡單通過比如Noel 或者Deis v2 來部署。Redis和PostgreSQL資源能夠直接由集群管理者提供，或者是通過比如helm這樣的東西。你能使用Kubernetes DNS服務和密鑰來將它們連接在一起。

長話短說，你不需要和Kubernetes的部署方式耦合在一起。你應該為每個你需要部署的子集選擇正確的構建工具。Noel是一個很小的工具，並且被明確驗證的它能夠去構建你自己的工具去處理基於Kubernetes的工作流。