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

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

在我們探索 Docker Swarm 和 Kubernetes 之前，我們定義了我們?nèi)绾问褂?Mesos。

阿帕奇梅索斯

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

Mesos 面臨的挑戰(zhàn)

現(xiàn)有基礎(chǔ)設(shè)施經(jīng)常出現(xiàn)服務(wù)故障，導(dǎo)致最終用戶無法使用基礎(chǔ)設(shè)施、數(shù)據(jù)丟失和更高的 AWS 賬單。

現(xiàn)有基礎(chǔ)架構(gòu)和編排

云：AWS

CI/CD：詹金斯

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

源代碼：Github

部署策略：自動化+手動

基礎(chǔ)設(shè)施監(jiān)控：自動化 + 手動（定期執(zhí)行驗證步驟）

當前的策略和工具

EC2 Auto Scaling 組

根據(jù) CPU 使用率進行縮放

EC2 上的 DCOS 微服務(wù)

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

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

挑戰(zhàn)

CPU 使用率會根據(jù)客戶和產(chǎn)品使用情況而波動

彈性伸縮后服務(wù)頻繁失敗

頻繁停機

頻繁的補丁

最終客戶因穩(wěn)定性和可用性而擔(dān)心數(shù)據(jù)丟失

由于多個 EC2 實例導(dǎo)致的高 AWS 賬單

碼頭工人群

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

Kubernetes

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

另請閱讀：關(guān)于 EKS（彈性 Kubernetes 服務(wù)）部署的分步指南

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

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

我們?yōu)橐粋€集群啟動了該流程，遷移了一項服務(wù)，并在 Docker Swarm 和 Amazon EKS 上驗證了穩(wěn)定性。其他基礎(chǔ)設(shè)施已經(jīng)在 AWS 上，我們發(fā)現(xiàn) Docker Swarm 配置會非常耗時，并且需要付出很多努力來監(jiān)控和管理。

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

從 Mesos 遷移到 Kubernetes

對于 EKS 上的環(huán)境創(chuàng)建、映射和部署，我們使用了 CloudFormation （YAML） 模板。

云形成

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

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

EKS 如何提供幫助

使用 EKS 可以減少 AWS 賬單

更少的 EC2 實例

使用 EKS 進行自動縮放

EKS 監(jiān)控服務(wù)和警報服務(wù)

?新基建

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

移除石墨

使用 EKS 自動縮放

減少 Datadog 和 Pager 任務(wù) 警報配置成本和復(fù)雜性

基于 Prometheus + Grafana 的 Alert 配置

數(shù)據(jù)狗

我們?yōu)?Datadog 配置了 CloudWatch 的擴展，用于監(jiān)控 EC2 實例和連接的 AWS 服務(wù)。我們在實例上安裝了 Datadog 代理，可以在 15 秒內(nèi)收集內(nèi)存、CPU、存儲、磁盤 I/O、網(wǎng)絡(luò)等的系統(tǒng)級指標。

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

Prometheus 幫助捕獲和保留 POD、容器、systemd 服務(wù)等數(shù)據(jù)。我們可以使用這些數(shù)據(jù)來分析應(yīng)用程序和環(huán)境的穩(wěn)定性和行為。

GRAFANA 使用 Prometheus 存儲的數(shù)據(jù)，并提供統(tǒng)計數(shù)據(jù)和警報配置的圖形表示，以便于評估。

遷移后最佳實踐

維持 MTTR（平均響應(yīng)/解決時間）

列出關(guān)鍵情況并報告

立即行動

事故報告

根本原因分析

定義流程的持續(xù)改進

實現(xiàn)戰(zhàn)略

手動

定期執(zhí)行驗證步驟

觀察到意外行為時進行調(diào)試

按照 Runbook 的定義步驟

如果未在規(guī)定時間內(nèi)解決，請致電或發(fā)送電子郵件給開發(fā)支持團隊

記錄現(xiàn)有故障后，如果需要，重新啟動服務(wù)

自動化實用程序

使用 Jenkins + Selenium/Dynatrace 持續(xù)執(zhí)行定義驗證工具

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

Slack 頻道的通知

傳呼義務(wù)

行動

15 分鐘內(nèi)未解決的電子郵件

如果在一小時內(nèi)未解決，則升級至 4 級

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

啟動并運行環(huán)境

最佳實踐

觀察環(huán)境幾個小時

創(chuàng)建根本原因分析文檔

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

從開發(fā)團隊收集分辨率信息

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

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

好處和應(yīng)用

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

基于擴展配置的自動服務(wù)重啟有助于提高應(yīng)用程序的可用性

數(shù)據(jù)丟失和最終客戶升級減少

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

結(jié)論

當我們談?wù)撽P(guān)于我們案例的結(jié)論時，我們發(fā)現(xiàn) EKS 更有幫助，因為我們發(fā)現(xiàn)在編排更改后我們的應(yīng)用程序更加穩(wěn)定。借助 EKS，我們觀察到了服務(wù)穩(wěn)定性、自動擴展和負載平衡——這有助于我們保持產(chǎn)品可用性。同樣，Kubernetes 和 Mesos 都提供了將應(yīng)用程序部署為云上容器的設(shè)施。根據(jù)不同的應(yīng)用需求，解決方案可能會有所不同。

審核編輯：郭婷