聊聊 Kubernetes 在企業(yè)落地過程中遇到的問題

原文鏈接：

https://increment.com/containers/containerization-at-scale/

Increment 采訪了 Datadog、Braze 和 BetterUp 的工程負責人，討論了容器工具、測試和監(jiān)控，以及他們?nèi)绾翁幚砣萜鬟w移的問題。

DataDog 高級工程師勞倫：主要容器技術(shù)有 Kubernetes、containerd 和 Cilium。我們在多個云供應(yīng)商上運行了數(shù)十個不同規(guī)模的 Kubernetes 集群：我們最大的集群每個都有 4000 多個節(jié)點，而且我們依賴內(nèi)部開發(fā)的工具來管理和編排多個集群的部署。

Braze 工程總監(jiān)克里斯：我們在 AWS 和 Azure 中使用 Kubernetes，運行 Ruby on Rails、Java、Go 和 Python 中的 dockerized 應(yīng)用程序。Kubernetes 會將度量報告給 Datadog，將日志報告給 Papertrail，而應(yīng)用程序的錯誤會轉(zhuǎn)到 Sentry。通過使用 Terraform 定義 Kubernetes 在不同云中部署的基礎(chǔ)設(shè)施，我們使用 Sops 進行 Secret 配置。

BetterUp 工程經(jīng)理布萊恩: 我們使用 Heroku，它采用了稱為 dynos 的輕量級容器，用于我們的網(wǎng)絡(luò)服務(wù)器、后臺作業(yè)以及機器學習微服務(wù)的一個子集。其他機器學習微服務(wù)使用 Kubeflow。利用 Docker，我們可以將開發(fā)和測試環(huán)境與生產(chǎn)環(huán)境保持一致。我們使用 SolarWinds Papertrail 和 Sumo Logic。對于客戶端和應(yīng)用程序的錯誤報告，我們使用 Sentry。最后，在性能監(jiān)控方面，我們使用了 Scout 和 Calibre。

DataDog 高級工程師勞倫：從 2018 年初開始，Datadog 遷移到 Kubernetes，大約 6 個月之后，DataDog 的第一個版本就完全在 Kubernetes 上運行和生產(chǎn)了。其中包括無狀態(tài)網(wǎng)絡(luò)應(yīng)用和有狀態(tài)數(shù)據(jù)服務(wù)，如 Cassandra 和 Kafka。我們從用 Chef 管理的虛擬機中運行的應(yīng)用程序遷移過來，因此這一過渡要求對開發(fā)流程進行很多更改。舉例來說，我們必須將每個應(yīng)用程序容器化，并提供一種可以部署到 Kubernetes 集群的解決方案，該方案最初依賴于 Spinnaker 和 Helm 圖表。遷移是一個挑戰(zhàn)。這個截止日期很有挑戰(zhàn)性，我們將從一個沒有容器、也沒有工具來部署容器的環(huán)境開始。但是這樣做也很有意義，因為它為我們提供了統(tǒng)一的打包和部署解決方案，使我們能夠部署到新的云供應(yīng)商和地區(qū)。

Braze 工程總監(jiān)克里斯：大約兩年前，我們開始在多云環(huán)境中使用容器。經(jīng)過近一年的初步探索，最初，容器會增加一些復雜性，尤其是在配置方面，但是，當我們構(gòu)建工具時，某些方面會變得更加簡單。舉例來說，Chef 要求更嚴格的權(quán)限才能對配置進行修改。把 Chef 數(shù)據(jù)包的配置改成 Sops，我們給開發(fā)者帶來了更簡單的自助式更改。

BetterUp 工程經(jīng)理布萊恩：2015 年以前，我們使用基于虛擬機的開發(fā)環(huán)境，后來由于本地編譯的原生依賴性帶來的挑戰(zhàn)，常常導致升級失敗，從而改用容器。轉(zhuǎn)換為容器之后，我們就可以做到無縫地遷移，而不會對開發(fā)工作流程造成負面影響。這也使我們的開發(fā)環(huán)境更加現(xiàn)代化，更接近于生產(chǎn)環(huán)境，并且降低了資源的密度。

DataDog 高級工程師勞倫：我們大多數(shù)應(yīng)用程序都是用 Go、Python 和 Java 編寫的，因此在容器中運行它們并不困難。問題當然是在細節(jié)上，我們面臨著一些挑戰(zhàn)，包括在容器中管理 JVM 占用的內(nèi)存。大部分應(yīng)用程序都認為它們只在虛擬機上運行，這就給它們自己提出了挑戰(zhàn)：尤其是 IO 操作（磁盤和網(wǎng)絡(luò)訪問），因為 Kubernetes 在共享 CPU 時間和內(nèi)存方面效率很高。Kubernetes 提供了更少的控制來限制和隔離資源消耗，IO 方面則更為復雜。在將應(yīng)用程序遷移到 Kubernetes 之后，我們注意到需要兩倍的主機數(shù)量。在剖析了應(yīng)用程序并分析了開銷之后，我們就對 pod 配置進行了優(yōu)化，從而大大減少了需要的額外主機數(shù)。

Braze 工程總監(jiān)克里斯：實際上，我們已將所有遺留應(yīng)用程序遷移到容器。將應(yīng)用程序 Docker 化是相對直接的，在大多數(shù)情況下，可以更輕松地打包依賴項和部署。在此之前，DevOps 管理 EC2 實例，將應(yīng)用程序復制到 Chef 并通過 Chef 運行它。應(yīng)用工程師把應(yīng)用程序轉(zhuǎn)換成容器后，就可以更直接地控制應(yīng)用程序在什么環(huán)境中運行，可以使用什么工具和庫，以及如何分配資源。

困難在于將部署管道的職責從 DevOps 轉(zhuǎn)移到應(yīng)用工程團隊，以及了解如何在 Kubernetes 而非 EC2 實例上調(diào)試應(yīng)用程序。但是，所有這些都有顯著的長期好處，消除了反復修改的需求，并使代碼與運行環(huán)境更緊密地結(jié)合在一起。

BetterUp 工程經(jīng)理布萊恩：利用容器進行機器學習微服務(wù)的實驗。在主要應(yīng)用中，我們提取了一小部分，并通過更適合的技術(shù)?？焖賳有路?wù)。這樣就可以快速迭代和實驗。舉例來說，我們可以用 Python 中的神經(jīng)網(wǎng)絡(luò)無縫替換 R 中的貝葉斯方法訓練的模型。

當我們將服務(wù)從單體上剝離時，我們面臨的一個挑戰(zhàn)是，這些服務(wù)不再能直接訪問實時應(yīng)用數(shù)據(jù)。我們必須決定微服務(wù)將保留對那些數(shù)據(jù)的訪問，并且知道越是接近實時的服務(wù)，就越需要訪問上下文數(shù)據(jù)。

DataDog 高級工程師勞倫：我們依賴 DataDog 來監(jiān)控。每一個應(yīng)用都負責對其監(jiān)控進行配置，但是有一些關(guān)鍵的指標隨處可見：容器的 CPU 和內(nèi)存使用情況，容器狀態(tài)和重啟次數(shù)，以及底層節(jié)點的健康狀況。起初，我們使用 Spinnaker 來部署容器化應(yīng)用程序，這在早期提供了一個強大的基礎(chǔ)，但是隨著集群數(shù)量的增長和工作流程的復雜性，我們對此有所改進。當前，我們正在開發(fā)利用 Helm 和云原生應(yīng)用包并由 Temporal 支持的多集群部署的內(nèi)部解決方案。

Braze 工程總監(jiān)克里斯：我們主要看內(nèi)存和 CPU，標準的 Kubernetes 監(jiān)控，以及特定的應(yīng)用指標，比如內(nèi)部隊列大小和錯誤率。應(yīng)用程序用 Helm 部署，當配置（GitHub repo 中的 YAML）發(fā)生變化時，使用內(nèi)部工具通過 Jenkins 將部署配置提供給 Helm CLI。

BetterUp 工程經(jīng)理布萊恩：當構(gòu)建在主分支中通過時，我們使用 Heroku 不斷地部署應(yīng)用程序。通過使用 Heroku，我們還添加了日志服務(wù)——Pingdom 和 New Relic，結(jié)合了 PagerDuty 的警報，這使得我們可以調(diào)查生產(chǎn)系統(tǒng)中的問題，并在發(fā)現(xiàn)問題時通知我們的團隊。同時，我們也使用合成和真實用戶監(jiān)測來發(fā)現(xiàn)嚴重的錯誤和性能問題。我們這個團隊使用 KPI 來跟蹤基礎(chǔ)設(shè)施的趨勢。服務(wù)器的正常運行時間是關(guān)鍵的健康指標，在 2020 年這一指標為 99.999%。

DataDog 高級工程師勞倫：我們沒有對容器進行系統(tǒng)性測試。取而代之的是，我們在 CI 中測試應(yīng)用程序，并在 staging 和 canary（金絲雀）中驗證新容器版本。如果我們懷疑容器化對它有影響，我們還會臨時測試容器，尤其是那些無法用代碼庫更改來解釋的性能下降。

Braze 工程總監(jiān)克里斯：通過 Docker Compose 運行，我們的許多應(yīng)用程序都在本地開發(fā)和測試。在運行容器化應(yīng)用部署的開發(fā)和 staging 環(huán)境中，我們每天也會數(shù)次運行端到端測試。我們使用 Buildkit，CI 還在 Docker 中運行測試，當應(yīng)用程序代碼改變時，測試會自動運行。

BetterUp 工程經(jīng)理布萊恩：測試容器已進行了配置，以與生產(chǎn)環(huán)境匹配。沒有直接測試容器本身，但是我們的連續(xù)測試過程可以確保應(yīng)用程序在各個分支中的行為一致。

DataDog 高級工程師勞倫：由于我們大規(guī)模使用 Kubernetes，并且面對著生態(tài)系統(tǒng)剛剛開始應(yīng)對的挑戰(zhàn)，所以我們更傾向于在早期測試新技術(shù)，并在測試成功之后再加以采用。比如，當 containerd 具有容器運行時接口時，我們將其標準化，并且當 kube-proxy 在測試版中可用時，我們就將其用于 IPVS 模式，這是處于擴展性的考慮。我們最近對 pod 網(wǎng)絡(luò)、服務(wù)負載平衡和網(wǎng)絡(luò)策略的 Cilium 進行了標準化。

Braze 工程總監(jiān)克里斯：我們工程師非常關(guān)心整個行業(yè)的變化。為了嘗試新的方法，他們嘗嘗鼓足勇氣做出改變，包括在我們的內(nèi)部“黑客日”進行概念驗證演示，以探索和衡量其他人的興趣。他們關(guān)注 AWS 的公告，Kubernetes 的公告，以及關(guān)于新選項的技術(shù)新聞來源。遇到問題的時候，他們會尋找解決辦法，想象出一個“更好的”樣子。舉例來說，我們已經(jīng)做了很多研究，通過使用 spot 實例自動提供實例來節(jié)省成本。

BetterUp 工程經(jīng)理布萊恩：我們依賴工程師來發(fā)現(xiàn)改進我們使用容器方法的機會，并且我們權(quán)衡了潛在價值和需求。舉例來說，最近我們的前端和全棧工程師在使用 Docker for Mac 時遇到了文件系統(tǒng)性能的問題。我們的一位工程師研究了改進 Docker 的 IO 的技術(shù)，并對 Mutagen、NFS，以及本地系統(tǒng)和 Docker 之間共享文件進行了實驗。最后，我們將 Mutagen 引入了整個團隊，極大地改善了開發(fā)人員的體驗。前端容器的構(gòu)建時間不再會影響開發(fā)者的生產(chǎn)力。

DataDog 高級工程師勞倫：從控制平面上的可擴展性問題到低層的運行時問題和網(wǎng)絡(luò)問題，我們都遇到過許多令人吃驚的挑戰(zhàn)?？傮w而言，在采用容器方面最大的成功在于，它允許我們使用通用抽象在多個云供應(yīng)商之間進行擴展和部署。

Braze 工程總監(jiān)克里斯：構(gòu)建用于 localdev 的容器需要其他額外的調(diào)試工具，這在生產(chǎn)環(huán)境中是不可取的。與本地調(diào)試相比，在生產(chǎn)環(huán)境中進行調(diào)試更困難，尤其是在托管容器的服務(wù)器上，它有一個細粒度的訪問控制列表。將面向服務(wù)的架構(gòu)精確地復制到容器中會讓筆記本的 CPU 和內(nèi)存負擔過重，這會導致仍然缺少一些可靠的捷徑，例如不運行“真正的” Kubernetes 集群或者相同的配置。與本地構(gòu)建不同，CI 構(gòu)建容器可以輕松地包含本地不存在的內(nèi)容，這可能會導致難以調(diào)試或識別。

BetterUp 工程經(jīng)理布萊恩：容器使我們能夠在一個云供應(yīng)商上訓練新的機器學習模型，并且當我們準備將它們與我們的主要應(yīng)用集成時，可以輕松地遷移到另一個云供應(yīng)商上。令人驚訝的是，我們幾乎沒有遇到任何與容器本身相關(guān)的問題。一般情況下，任何問題都存在于比容器級別更高的抽象層次；例如，我們在部署應(yīng)用程序時發(fā)現(xiàn)了一些錯誤，但這些錯誤并不特定于容器的使用。

- END -
 推薦閱讀 

Kubernetes實戰(zhàn)指南：從零到架構(gòu)師的進階之路 
Kubernetes 中網(wǎng)站無法訪問，深入排查實戰(zhàn)
Nginx 常用配置清單
Prometheus + Thanos 多集群架構(gòu)監(jiān)控
Jenkins 流水線自動化部署 Go 項目
最強整理！常用正則表達式速查手冊
運維的工作邊界，這次真的搞明白了！
Linux 這些工具堪稱神器！
Prometheus + Granafa 構(gòu)建高大上的MySQL監(jiān)控平臺
搭建一套完整的企業(yè)級 K8s 集群（v1.20，kubeadm方式）
12年資深運維老司機的成長感悟


點亮，服務(wù)器三年不宕機