Kubernetes 是在叢集生產環境中執行 Docker 容器的絕佳工具。 然而，也有一些問題是 Kubernetes 無法解決的。 對於頻繁的生產部署，我們需要完全自動化的藍/綠部署以避免流程中的停機，這也需要處理外部 HTTP 請求並執行 SSL 卸載。 這需要與負載平衡器（例如 ha-proxy）整合。 另一個挑戰是在雲端環境中運行時 Kubernetes 叢集本身的半自動擴展，例如在夜間部分縮小叢集。
雖然 Kubernetes 不具備這些開箱即用的功能，但它確實提供了一個可用於解決類似問題的 API。 用於自動藍/綠部署和擴展 Kubernetes 叢集的工具是作為 Cloud RTI 專案的一部分開發的，該專案是基於開源創建的。
本文是一個影片腳本，向您展示如何設定 Kubernetes 以及其他開源元件，以建立一個生產就緒環境，該環境接受來自 git 提交的程式碼，而無需在生產中停機。
因此，一旦您可以從外部世界訪問您的應用程序，您就可以開始完全設定自動化，也就是說，將其帶到可以執行 git 提交並確保此 git 提交最終進入生產的階段。 當然，在實施這些步驟、實施部署時，我們不希望遇到停機。 因此，Kubernetes 中的任何自動化都是從 API 開始的。
Kubernetes 並不是一個可以立即有效使用的工具。 當然，你可以這樣做，使用 kubectl 等，但 API 仍然是這個平台最有趣和有用的東西。 透過使用 API 作為一組函數，您幾乎可以在 Kubernetes 中存取您想要執行的任何操作。 kubectl 本身也使用 REST API。
這是 REST，因此您可以使用任何語言或工具來使用此 API，但自訂程式庫將使您的生活變得更加輕鬆。 我的團隊編寫了 2 個這樣的函式庫：一個用於 Java/OSGi，一個用於 Go。 第二個不常使用，但無論如何你都可以使用這些有用的東西。 它們是一個部分許可的開源專案。 對於不同的語言有很多這樣的庫，因此您可以選擇最適合您的庫。
因此，在開始自動化部署之前，您需要確保流程不會出現任何停機時間。 例如，我們的團隊在中午進行生產部署，此時人們最常使用應用程序，因此避免此過程中的延遲非常重要。 為了避免停機，使用了兩種方法：藍/綠部署或滾動更新。 在後一種情況下，如果您有 2 個正在運行的應用程式副本，它們將依次按順序更新。 此方法效果很好，但如果在部署過程中同時運行不同版本的應用程序，則不適合。 在這種情況下，您可以在後端運行舊版本時更新使用者介面，應用程式將停止運作。 因此，從程式設計的角度來看，在這樣的條件下工作是相當困難的。
這就是我們更喜歡使用藍/綠部署來自動化應用程式部署的原因之一。 使用此方法，您必須確保一次只有一個版本的應用程式處於活動狀態。
藍/綠部署機制如下圖所示。 我們透過 ha-proxy 接收應用程式的流量，該流量將其轉發到相同版本應用程式的正在運行的副本。
當進行新的部署時，我們使用 Deployer，它會獲得新元件並部署新版本。 部署應用程式的新版本意味著「引發」一組新的副本，之後這些新版本的副本將在單獨的新 Pod 中啟動。 然而，ha-proxy 對它們一無所知，也不會向它們路由任何工作負載。
因此，首先需要對新版本的健康檢查進行效能檢查，以確保副本已準備好為負載提供服務。
所有部署元件都必須支援某種形式的運行狀況檢查。 這可以是非常簡單的 HTTP 呼叫檢查（當您收到狀態 200 的程式碼時），也可以是更深入的檢查（檢查副本與資料庫和其他服務的連接、動態環境連接的穩定性） ，以及一切是否正常啟動和工作。 這個過程可能相當複雜。
系統驗證所有更新的副本都正常運作後，Deployer將更新配置並傳遞正確的confd，這將重新配置ha-proxy。
只有在此之後，流量才會被定向到具有新版本副本的 Pod，並且舊 Pod 將會消失。
這種機制不是 Kubernetes 的特性。 藍/綠部署的概念已經存在了相當長的時間，並且它始終使用負載平衡器。 首先，您將所有流量引導到舊版本的應用程序，更新後，您將其完全轉移到新版本。 這個原則不僅用在 Kubernetes 中。
現在我將向您介紹一個新的部署元件—Deployer，它執行健康檢查、重新配置代理程式等。 這是一個不適用於外界的概念，存在於 Kubernetes 內部。 我將向您展示如何使用開源工具建立您自己的部署程式概念。
因此，Deployer 做的第一件事就是使用 Kubernetes API 建立一個 RC 複製控制器。 該 API 會建立 pod 和服務以供進一步部署，即為我們的應用程式建立一個全新的叢集。 一旦 RC 確信副本已啟動，它將對其功能執行運行狀況檢查。 為此，Deployer 使用 GET /health 指令。 它運行適當的掃描組件並檢查支援叢集操作的所有元素。
在所有 pod 報告其運行狀況後，Deployer 會建立一個新的配置元素 - etcd 分散式存儲，該元素由 Kubernetes 內部使用，包括儲存負載平衡器配置。 我們將資料寫入 etcd，然後一個名為 confd 的小工具監視 etcd 是否有新資料。
如果它偵測到初始配置有任何更改，它會產生一個新的設定檔並將其傳輸到 ha-proxy。 在這種情況下，ha-proxy 會在不遺失任何連線的情況下重新啟動，並將負載指派給新服務，使新版本的應用程式能夠正常運作。
正如您所看到的，儘管組件豐富，但這裡並不復雜。 你只需要多關注 API 和 etcd 即可。 我想向您介紹我們自己使用的開源部署器 - Amdatu Kubernetes Deployer。
它是編排 Kubernetes 部署的工具，具有以下功能：
- 藍/綠部署；
- 設定外部負載平衡器；
- 部署描述符管理；
- 管理實際部署；
- 在部署期間檢查健康檢查的功能；
- 將環境變數實施到 pod 中。
此部署程式建置在 Kubernetes API 之上，並提供用於管理句柄和部署的 REST API，以及用於在部署過程中串流日誌的 Websocket API。
它將負載平衡器設定資料放入 etcd 中，因此您不必使用具有開箱即用支援的 ha-proxy，而是輕鬆使用您自己的負載平衡器設定檔。 Amdatu Deployer 是用 Go 寫的，就像 Kubernetes 本身一樣，並由 Apache 授權。
在開始使用此版本的部署程序之前，我使用了以下部署描述符，它指定了我需要的參數。
此程式碼的重要參數之一是啟用“useHealthCheck”標誌。 我們需要指定在部署過程中必須執行健全性檢查。 當部署使用不需要驗證的第三方容器時，可以停用此設定。 該描述符還指示 ha-proxy 所需的副本數量和前端 URL。 最後是pod規範標誌“podspec”，它呼叫Kubernetes取得連接埠配置、鏡像等資訊。 這是一個相當簡單的 JSON 描述符。
開源 Amdatu 專案的另一個工具是 Deploymentctl。 它有一個用於配置部署的 UI，儲存部署歷史記錄，並包含用於第三方使用者和開發人員回呼的 Webhook。 您可能不會使用 UI，因為 Amdatu Deployer 本身就是 REST API，但此介面可以讓您的部署更輕鬆，而無需涉及任何 API。 Deploymentctl 是使用 Angular 2 在 OSGi/Vertx 中編寫的。
我現在將使用預先錄製的錄音在螢幕上示範上述內容，這樣您就不必等待。 我們將部署一個簡單的 Go 應用程式。 如果您以前沒有嘗試過 Go，請不要擔心，這是一個非常簡單的應用程序，因此您應該能夠弄清楚。
在這裡，我們創建一個僅響應 /health 的 HTTP 伺服器，因此該應用程式僅測試運行狀況檢查，而不測試其他任何內容。 如果檢查通過，則使用下面所示的 JSON 結構。 它包含部署者將部署的應用程式的版本、您在文件頂部看到的訊息以及布林資料類型 - 我們的應用程式是否正在運行。
我在最後一行做了一些作弊，因為我在文件頂部放置了一個固定的布林值，這在將來將幫助我部署甚至是「不健康」的應用程式。 我們稍後會處理這個問題。
那麼就讓我們開始吧。 首先，我們使用指令 ~ kubectl get pods 檢查是否有任何正在執行的 pod，並且根據前端 URL 沒有回應，我們確保目前沒有進行任何部署。
接下來畫面你可以看到我提到的Deploymentctl介面，其中設定了部署參數：命名空間、應用程式名稱、部署版本、副本數量、前端URL、容器名稱、鏡像、資源限制、健康檢查連接埠號碼、等等。 資源限制非常重要，因為它們允許您使用盡可能多的硬體。 在這裡您也可以查看部署日誌。
如果現在重複命令 ~ kubectl get pods，您可以看到系統「凍結」了 20 秒，在此期間 ha-proxy 被重新配置。 之後，pod 啟動，我們的副本可以在部署日誌中看到。
我從影片中刪除了 20 秒的等待，現在您可以在螢幕上看到該應用程式的第一個版本已經部署。 所有這一切都是僅使用 UI 完成的。
現在讓我們試試第二個版本。 為此，我將應用程式的消息從“Hello, Kubernetes!”更改為“Hello, Kubernetes!” 在「Hello, Deployer!」中，系統會建立此映像並將其放置在 Docker 註冊表中，之後我們只需在 Deploymentctl 視窗中再次按一下「Deploy」按鈕即可。 在這種情況下，部署日誌將以與部署應用程式的第一個版本相同的方式自動啟動。
命令 ~ kubectl get pods 顯示目前有 2 個版本的應用程式正在運行，但前端顯示我們仍在運行版本 1。
負載平衡器等待運行狀況檢查完成，然後再將流量重新導向到新版本。 20 秒後，我們切換到curl，看到我們現在已經部署了應用程式的版本2，並且第一個版本已被刪除。
這是“健康”應用程式的部署。 讓我們看看，如果對於新版本的應用程序，我將 Healthy 參數從 true 更改為 false，也就是說，我嘗試部署一個未通過健康檢查的不健康應用程序，會發生什麼情況。 如果應用程式在開發階段出現一些配置錯誤，並以這種形式投入生產，則可能會發生這種情況。
如您所見，部署執行了上述所有步驟，並且 ~kubectl get pods 顯示兩個 pod 都在運行。 但與先前的部署不同的是，日誌顯示的是逾時狀態。 即由於健康檢查失敗，導致新版本的應用程式無法部署。 結果，您看到系統已恢復使用舊版本的應用程序，而新版本只是被卸載。
這樣做的好處是，即使您有大量同時請求進入應用程序，他們甚至不會注意到實施部署過程時的停機時間。 如果您使用 Gattle 框架測試此應用程序，該框架會向其發送盡可能多的請求，那麼這些請求都不會被丟棄。 這意味著我們的用戶甚至不會即時注意到版本更新。 如果失敗，將繼續使用舊版本；如果成功，使用者將切換到新版本。
只有一件事可能會失敗 - 如果健康檢查成功，但應用程式一施加工作負載就失敗，即只有在部署完成後才會發生崩潰。 在這種情況下，您將必須手動回滾到舊版本。 因此，我們研究瞭如何將 Kubernetes 與為其設計的開源工具結合使用。 如果您將這些工具建置到建置/部署管道中，部署過程將會變得更加容易。 同時，要開始部署，您可以使用使用者介面或使用提交到 master 等方式完全自動化此流程。
我們的建置伺服器將建立一個 Docker 映像，將其推送到 Docker Hub 或您使用的任何註冊表中。 Docker Hub支援webhook，因此我們可以按照如上所示的方式透過Deployer觸發遠端部署。 透過這種方式，您可以完全自動化地將應用程式部署到潛在的生產中。
讓我們繼續下一個主題 - 擴展 Kubernetes 叢集。 請注意，kubectl 指令是一個縮放指令。 有了更多幫助，我們可以輕鬆增加現有集群中的副本數量。 然而，在實踐中，我們通常希望增加節點數量而不是 Pod 數量。
同時，在工作時間你可能需要增加，而在晚上，為了降低亞馬遜服務的成本，你可能需要減少正在運行的應用程式實例的數量。 這並不意味著僅擴展 Pod 數量就足夠了，因為即使其中一個節點閒置，您仍然需要向 Amazon 付費。 也就是說，除了擴充 Pod 之外，您還需要擴展所使用的機器數量。
這可能具有挑戰性，因為無論我們使用 Amazon 還是其他雲端服務，Kubernetes 對正在使用的機器數量一無所知。 它缺少一個允許您在節點層級擴展系統的工具。
所以我們必須同時照顧節點和 Pod。 我們可以使用AWS API和Scaling組機器輕鬆擴充新節點的啟動，以設定Kubernetes工作節點的數量。 您也可以使用 cloud-init 或類似的腳本來註冊 Kubernetes 叢集中的節點。
新機器在 Scaling 群組中啟動，將自身初始化為節點，在主伺服器登錄中註冊並開始工作。 之後，您可以增加在生成的節點上使用的副本數量。 縮小規模需要付出更多努力，因為您需要確保這樣的步驟不會導致在關閉「不必要的」機器後破壞已經運行的應用程式。 為了防止這種情況發生，需要將節點設定為「不可調度」狀態。 這意味著預設調度程序在調度 DaemonSet Pod 時將忽略這些節點。 調度程序不會從這些伺服器中刪除任何內容，但也不會在那裡啟動新的容器。 下一步是驅逐 Drain 節點，即將正在運行的 Pod 從該節點轉移到另一台機器或其他有足夠容量的節點。 一旦確保這些節點上不再有任何容器，您就可以將它們從 Kubernetes 中刪除。 此後，它們對於 Kubernetes 來說將不再存在。 接下來，您需要使用 AWS API 停用不必要的節點或機器。
您可以使用 Amdatu Scalerd，這是另一個類似 AWS API 的開源擴充工具。 它提供了一個 CLI 來新增或刪除叢集中的節點。 它有趣的功能是能夠使用以下 json 檔案配置調度程序。
顯示的程式碼在夜間將叢集容量減少一半。 它配置 Amazon 叢集的可用副本數量和所需容量。 使用這個調度程序將在晚上自動減少節點數量並在早上增加節點數量，從而節省使用亞馬遜等雲端服務節點的成本。 此功能未內建於 Kubernetes 中，但使用 Scalerd 將允許您根據需要擴展該平台。
我想指出的是，很多人告訴我，“這一切都很好，但是我的資料庫呢，通常是靜態的？” 如何在像 Kubernetes 這樣的動態環境中運行這樣的東西？ 在我看來，你不應該這樣做，你不應該嘗試在 Kubernetes 中運行資料倉儲。 這在技術上是可行的，並且互聯網上有關於此主題的教程，但它會使您的生活嚴重複雜化。
是的，Kubernetes 中有持久存儲的概念，您可以嘗試運行 Mongo 或 MySQL 等資料存儲，但這是一項相當耗費人力的任務。 這是因為資料倉儲不完全支援與動態環境的互動。 大多數資料庫需要大量配置，包括手動配置集群，不喜歡自動縮放和其他類似的東西。
因此，您不應該因為嘗試在 Kubernetes 中運行資料倉儲而使您的生活變得複雜。 使用熟悉的服務以傳統方式組織他們的工作，並簡單地向 Kubernetes 提供使用它們的能力。
最後，我想向大家介紹我的團隊正在開發的基於 Kubernetes 的 Cloud RTI 平台。 它提供集中日誌記錄、應用程式和叢集監控以及許多其他有用的功能，這些功能將派上用場。 它使用Grafana等各種開源工具來顯示監控。
有人問為什麼要在 Kubernetes 中使用 ha-proxy 負載平衡器。 好問題，因為目前有 2 個等級的負載平衡。 Kubernetes 服務仍駐留在虛擬 IP 位址上。 您不能將它們用於外部主機上的端口，因為如果 Amazon 使其雲端主機過載，位址就會發生變化。 這就是為什麼我們將 ha-proxy 放在服務前面 - 為流量創建一個更靜態的結構，以便與 Kubernetes 無縫通訊。
另一個好問題是在進行藍/綠部署時如何處理資料庫架構變更？ 事實是，無論使用 Kubernetes，更改資料庫架構都是一項艱鉅的任務。 您需要確保新舊模式相容，然後您可以更新資料庫，然後更新應用程式本身。 您可以熱插拔資料庫，然後更新應用程式。 我知道有人用新模式啟動了一個全新的資料庫集群，如果您有像 Mongo 這樣的無模式資料庫，這是一個選擇，但無論如何這都不是一件容易的事。 如果您沒有其他問題，感謝您的關注！
一些廣告🙂
感謝您與我們在一起。 你喜歡我們的文章嗎？ 想看更多有趣的內容？ 通過下訂單或推薦給朋友來支持我們， , 我們為您發明的入門級服務器的獨特模擬： （適用於 RAID1 和 RAID10，最多 24 個內核和最多 40GB DDR4）。
Dell R730xd 在阿姆斯特丹的 Equinix Tier IV 數據中心便宜 2 倍？ 只有這裡 在荷蘭！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 美元起！ 閱讀
來源： www.habr.com