對于一些微服務，數據傳輸和穩定性會導致問題，特別是在用戶嘗試長時間獲取更大數據的情況下。設備能夠將數據推送到數據庫，但數據加載和顯示導致數據丟失或服務失敗。由于微服務的 I/O 更高，CPU 和內存的更高使用率啟用了負載均衡器，并最終導致更高的計費。

我們決定重新設計編排并找到 Apache Mesos 的替代方案。Docker Swarm 和Kubernetes是領先且高度使用的容器編排工具，用于 DevOps 基礎設施管理工具。

在我們探索 Docker Swarm 和 Kubernetes 之前，我們定義了我們如何使用 Mesos。

阿帕奇梅索斯

它提供了以分布式方式運行容器化和非容器化服務的能力。Mesos 采用分布式內核設計，因此 API 編程可以直接針對數據中心進行設計。在我們的案例中，配置為主/從的 MESOS DCOS 是基于數據庫請求并進行管理的。在服務失敗時，Mesos master 永遠不會自動重啟服務，這增加了應用程序的停機時間。

Mesos 面臨的挑戰

現有基礎設施經常出現服務故障，導致最終用戶無法使用基礎設施、數據丟失和更高的 AWS 賬單。

現有基礎架構和編排

云：AWS

CI/CD：詹金斯

編程語言：Python、JAVA、C、C++等。

源代碼：Github

部署策略：自動化+手動

基礎設施監控：自動化 + 手動（定期執行驗證步驟）

當前的策略和工具

EC2 Auto Scaling 組

根據 CPU 使用率進行縮放

EC2 上的 DCOS 微服務

Slack 和通過電話/電子郵件通知

其他工具/服務：Splunk、Looker、HA Proxy、S3、Graphite、Grafana

挑戰

CPU 使用率會根據客戶和產品使用情況而波動

彈性伸縮后服務頻繁失敗

頻繁停機

頻繁的補丁

最終客戶因穩定性和可用性而擔心數據丟失

由于多個 EC2 實例導致的高 AWS 賬單

碼頭工人群

Docker swarm 使用 Docker API 和網絡概念，因此我們可以輕松配置和使用它。它的架構可以強有力地管理故障。在 Docker swarm 中，新節點可以作為工作節點或主節點加入現有集群。Docker Swarm 不允許集成第三方日志工具。與 Kubernetes 相比，Docker Swarm 在 AWS、Azure 和 Google Cloud 等不同云服務提供商上的輕松集成是不可用的。

Kubernetes

Kubernetes 易于配置且體積輕巧。在服務失敗的情況下，Kubernetes 會執行自動縮放并保持服務可用。Kubernetes 用途廣泛且應用廣泛。主要云服務為 Kubernetes 提供自定義 master 支持。

另請閱讀：關于 EKS（彈性 Kubernetes 服務）部署的分步指南

由于 AWS 為 Kubernetes Master 提供了一個平臺，我們決定使用 EKS。

Amazon EKS 定價模型要求用戶為每個 EKS 集群承擔 0.20 美元/小時的額外費用。這讓我們思考，但是當我們比較收益時，它不應該像聽起來那么糟糕。作為用戶，我們在單個集群上設計和部署了多個具有不同命名空間和 VPC 范圍的應用程序。

我們為一個集群啟動了該流程，遷移了一項服務，并在 Docker Swarm 和 Amazon EKS 上驗證了穩定性。其他基礎設施已經在 AWS 上，我們發現 Docker Swarm 配置會非常耗時，并且需要付出很多努力來監控和管理。

借助 EKS，我們得到了亞馬遜的支持和指導，以設計和部署服務以及如何降低成本，因此我們決定使用 EKS。

從 Mesos 遷移到 Kubernetes

對于 EKS 上的環境創建、映射和部署，我們使用了 CloudFormation （YAML） 模板。

云形成

AWS CloudFormation 提供了一個基于 YAML 的自定義圖形界面來創建、管理和修改大量 AWS 資源，并映射它們的依賴關系。由于 CloudFormation 是 AWS 的一項服務，因此任何新服務都可以使用。

諸如 Terraform 之類的選項是開源的，并且支持主要的云平臺以將基礎設施設置為代碼，但我們使用了 CloudFormation，因為我們在 AWS 上擁有一切。

EKS 如何提供幫助

使用 EKS 可以減少 AWS 賬單

更少的 EC2 實例

使用 EKS 進行自動縮放

EKS 監控服務和警報服務

?新基建

將 EC2 實例從 15 個中型減少到 3 個大型

移除石墨

使用 EKS 自動縮放

減少 Datadog 和 Pager 任務 警報配置成本和復雜性

基于 Prometheus + Grafana 的 Alert 配置

數據狗

我們為 Datadog 配置了 CloudWatch 的擴展，用于監控 EC2 實例和連接的 AWS 服務。我們在實例上安裝了 Datadog 代理，可以在 15 秒內收集內存、CPU、存儲、磁盤 I/O、網絡等的系統級指標。

為了對 Kubernetes 集群進行額外的警報和監控，我們配置了 Prometheus + Grafana。

Prometheus 幫助捕獲和保留 POD、容器、systemd 服務等數據。我們可以使用這些數據來分析應用程序和環境的穩定性和行為。

GRAFANA 使用 Prometheus 存儲的數據，并提供統計數據和警報配置的圖形表示，以便于評估。

遷移后最佳實踐

維持 MTTR（平均響應/解決時間）

列出關鍵情況并報告

立即行動

事故報告

根本原因分析

定義流程的持續改進

實現戰略

手動

定期執行驗證步驟

觀察到意外行為時進行調試

按照 Runbook 的定義步驟

如果未在規定時間內解決，請致電或發送電子郵件給開發支持團隊

記錄現有故障后，如果需要，重新啟動服務

自動化實用程序

使用 Jenkins + Selenium/Dynatrace 持續執行定義驗證工具

增強 Python 腳本的驗證步驟覆蓋率

Slack 頻道的通知

傳呼義務

行動

15 分鐘內未解決的電子郵件

如果在一小時內未解決，則升級至 4 級

如果沒有解決，升級到 5 級

啟動并運行環境

最佳實踐

觀察環境幾個小時

創建根本原因分析文檔

獲得開發團隊確定的根本原因分析的批準

從開發團隊收集分辨率信息

如果將來觀察到相同的 RCA，請立即采取行動以最大程度地減少停機時間

更新運行手冊以供將來參考

好處和應用

在我們的案例中，AWS 賬單減少了約 40%，因為 EC2 數量從 15 個減少到 3 個

基于擴展配置的自動服務重啟有助于提高應用程序的可用性

數據丟失和最終客戶升級減少

更高級的監控方式，幫助 DevOps 工程師快速識別根本原因

結論

當我們談論關于我們案例的結論時，我們發現 EKS 更有幫助，因為我們發現在編排更改后我們的應用程序更加穩定。借助 EKS，我們觀察到了服務穩定性、自動擴展和負載平衡——這有助于我們保持產品可用性。同樣，Kubernetes 和 Mesos 都提供了將應用程序部署為云上容器的設施。根據不同的應用需求，解決方案可能會有所不同。

審核編輯：郭婷