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

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

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

阿帕奇梅索斯

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

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

部署策略：自動(dòng)化+手動(dòng)

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

當(dāng)前的策略和工具

EC2 Auto Scaling 組

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

EC2 上的 DCOS 微服務(wù)

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

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

挑戰(zhàn)

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

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

頻繁停機(jī)

頻繁的補(bǔ)丁

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

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

碼頭工人群

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

Kubernetes

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

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

由于 AWS 為 Kubernetes Master 提供了一個(gè)平臺(tái)，我們決定使用 EKS。

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

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

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

從 Mesos 遷移到 Kubernetes

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

云形成

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

諸如 Terraform 之類的選項(xiàng)是開源的，并且支持主要的云平臺(tái)以將基礎(chǔ)設(shè)施設(shè)置為代碼，但我們使用了 CloudFormation，因?yàn)槲覀冊(cè)?AWS 上擁有一切。

EKS 如何提供幫助

使用 EKS 可以減少 AWS 賬單

更少的 EC2 實(shí)例

使用 EKS 進(jìn)行自動(dòng)縮放

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

?新基建

將 EC2 實(shí)例從 15 個(gè)中型減少到 3 個(gè)大型

移除石墨

使用 EKS 自動(dòng)縮放

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

基于 Prometheus + Grafana 的 Alert 配置

數(shù)據(jù)狗

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

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

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

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

遷移后最佳實(shí)踐

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

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

立即行動(dòng)

事故報(bào)告

根本原因分析

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

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

手動(dòng)

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

觀察到意外行為時(shí)進(jìn)行調(diào)試

按照 Runbook 的定義步驟

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

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

自動(dòng)化實(shí)用程序

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

增強(qiáng) Python 腳本的驗(yàn)證步驟覆蓋率

Slack 頻道的通知

傳呼義務(wù)

行動(dòng)

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

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

如果沒有解決，升級(jí)到 5 級(jí)

啟動(dòng)并運(yùn)行環(huán)境

最佳實(shí)踐

觀察環(huán)境幾個(gè)小時(shí)

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

獲得開發(fā)團(tuán)隊(duì)確定的根本原因分析的批準(zhǔn)

從開發(fā)團(tuán)隊(duì)收集分辨率信息

如果將來觀察到相同的 RCA，請(qǐng)立即采取行動(dòng)以最大程度地減少停機(jī)時(shí)間

更新運(yùn)行手冊(cè)以供將來參考

好處和應(yīng)用

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

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

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

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

結(jié)論

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

審核編輯：郭婷