別了Swarm：往Kubernetes之路

客座文章做者：Kevin Crawley，Containous開發者倡導者

爲了講述這個故事，咱們得回到三年前，當時我做爲投資人加入了Single，爲他們搭建了一個平臺，並在整個過程當中爲他們提供技術方面的建議。儘管圍繞微服務架構和複雜性存在分歧，但這其實是一個成功的故事，講述的是一個由專一的工匠組成的很是小的團隊如何在雲原生生態系統上創建起一個蓬勃發展的初創公司。

簡單介紹一下我本身，我是Kevin Crawley，是Containous公司的開發者，該公司建立了Traefik和Maesh。我在Containous和Single的目標，是教育和使技術人員可以參與開發他們的產品與現代DevOps工具和實踐。和我一塊兒踏上咱們的旅程，瞭解包括Kubernetes和Traefik在內的整個雲原生生態系統，是如何幫助像Travis Scott、Harry Styles、Lil Peep和TOOL這樣的音樂家，經過他們的音樂和藝術做品接觸數百萬粉絲的。

開始

2016年，Single仍是一個單體原型，這個想法是由一輩子的朋友Tommy和Taylor造成的。Single背後的理念是讓藝術家可以在網上銷售本身的音樂，讓他們的銷售獲得諸如Nielsen這樣的主要報告系統的承認，並讓他們的收入直接進入本身的口袋。我以前曾與Taylor合做過一個大型項目，經過實施咱們如今仍然稱之爲12要素應用的東西來「數字化改造」一家抵押貸款公司，那是在「雲原生化」成爲現代應用設計原則事實上的流行詞以前。

當我在2017年4月加入Single，目標很簡單：構建並實施所需的工具，以便負責該產品的開發者可以徹底不依賴於我（或與此有關的任何其餘人）來發布和管理其應用程序。在過去的一年中，Taylor和我都一直在使用SwarmKit並對此感到滿意，所以最終成爲了咱們將來三年的編排器。

咱們當時考慮過Kubernetes，但當時甚至尚未一家通過認證的託管雲提供商。CNCF直到2017年末纔給GKE認證，而亞馬遜的EKS在2017年re:Invent大會上匆忙宣佈，並在2018年晚些時候發佈了GA，但人們對此褒貶不一。在過去的兩年裏，AWS一直在努力支持K8s，確保平臺能力和用戶體驗與競爭對手不相上下。做爲一個團隊，咱們並不後悔咱們所作的決定，最終，由於這個決定，（劇透警告），遷移到Kubernetes多是我所作過的最簡單的平臺遷移。

別了Swarm

在我解釋遷移的細節以前，我可能應該解釋一下咱們決定遷移的緣由。在將近4年的時間裏，咱們共同創建了許多定製的工具和流程來管理咱們的部署和本地開發環境。這些工具是基於CLI和GUI的組合，提供了各類功能，包括用於在咱們的環境中可視化和提高服務，創建本地開發環境以及管理這兩個環境中的共同任務的管理門戶--這甚至不盡相同--生產集羣使用SwarmKit，而開發者僅在POD（純舊Docker）中運行其服務。咱們擁有適當的工具來審覈並確保Swarm中的網絡平面運行情況良好，而且還執行了一些其餘特定於部署基於撰寫項目的任務（將值解析/注入到模板等）。

除了修補工具以外，咱們很快就到達了一個點，咱們可能須要擴展咱們的關鍵基礎設施組件，如Redis和RabbitMQ，雖然Swarm很適合擴展無狀態應用程序，但它不太適合管理狀態的應用程序。隨着操做器（Operators）的引入和Kubernetes的成熟，有狀態集羣應用程序正在迅速接近在生產中能夠依賴它們的程度。

膽大妄爲

自動化的快速破壞咱們的集羣和重建並不存在。結果，個人運行手冊中填充了幾頁手工步驟，這些步驟須要配置實例、將它們加入集羣、保護它們，以及管理工具和Single Music服務自己的仔細過程。這項工做的大部分本能夠自動化，但對於每一年最多發生兩次的事情，那將須要數週的工做。

這種狀況並不理想，若是管理平面崩潰，咱們將面臨離線8個小時手工重建。考慮到Single Music如今每週至少要發行一個很是知名藝術家的新發行，所以這是巨大的業務風險。我知道咱們必須在某個時候解決這個問題，但我估計所需的時間在80-120小時之間。Single Music並非個人全職工做，像這樣的遷移須要持續的專一工做，在幾個月的週末裏零零碎碎地作並不能解決問題。

設定目標

在移動應用程序以前，我必須確保咱們可以知足軟件的開發和操做需求，同時只構建最小的工具集來管理平常操做。我與團隊一塊兒爲遷移設置了合理的基準和要求：

1. 在雲中運行所需的全部底層平臺服務和工具必須在1小時內從零開始爲咱們的生產應用程序服務。
2. 本地開發環境必須使用可以使用徹底相同的清單、工具以及兼容或相同的基礎設施組件的平臺來服務，此外，還必須在15分鐘或更少的時間內徹底配置/操做。
3. 除了咱們的持續部署系統以外，用於提高和管理部署的任何定製工具都必須用於本地操做。

這是一個實驗的核心，雖然我相對有信心咱們能夠實現這些目標，但我不肯定須要多長時間。使用Kubernetes是顯而易見的選擇，由於咱們的構建工具、應用程序和架構已經與雲原生兼容。基於我構建研討會和演示的經驗，我有信心在開發團隊的其餘成員的幫助下可以實現其餘目標。

實驗

Lift and shift遷移應用程序並不像一些供應商所作的那樣容易，可是咱們有一些能夠利用的方法。咱們已經在全部應用程序中使用了一致的模式和工具，全部這些都很好地適應了雲原生生態系統。我將列舉以下以供參考：

• Maven/Fabric8--在咱們全部的應用程序中，甚至是非java應用程序、版本管理、測試等等，都採用一致的構建模式。
• Gitlab/GitlabCI--咱們全部的應用程序都被設計爲持續構建，咱們的鏡像被標記，被推到docker鏡像註冊表中，並部署到預生產環境中。

下一個階段是決定咱們將使用哪些工具來管理咱們的應用程序的生命週期，包括部署平臺自己、咱們的服務，以及咱們將如何監控它。咱們選擇了一些不一樣的工具：

• Helm--爲咱們的後端服務預先作好生產準備的清單，我已經有了爲研討會和教程構建chart的經驗。成熟的社區和普遍採用的，這使咱們可以爲全部分佈式應用程序建立一個統一的chart，併爲可伸縮的後端組件利用社區chart。
• eksctl--雖然沒有kops那麼靈活，這個工具在第一輪就能夠工做，並知足了咱們自動設置生產集羣的初始需求。
• kind--很是適合本地開發和測試，這是一種輕量級解決方案，用於建立本地開發所需的一次性K8s環境，而不依賴於大型而緩慢的VM。
• Kontena Lens--Kubernetes的一個可視化工具，這個應用程序很是適合管理運行在本地和雲中的K8s中的服務和後端組件。這取代了咱們爲Swarm內部構建的定製工具之一，該工具處理了Lens中可用的大部分功能，好比快速訪問狀態、執行、日誌和工做負載的配置細節。

Hello Kubernetes

因爲新冠肺炎對經濟的影響，我於2020年3月底從全職工做中下崗。我決定如今是時候了，由於我已經預料到在這場經濟冰雹風暴中很難找到一份新工做。幸運的是，Containous和我找到了彼此，在被解僱的一週內，我開始了一個很棒的新角色。可是，在開始以前，我決定完成這個遷移，因此讓咱們開始。

步驟1：

開發者。開發者。開發者。

重要的是，開發者要有一個儘量接近將在生產環境中運行的環境。在此以前，他們一直依賴fabric8-maven-plugin在本地docker網絡上啓動應用程序--這與咱們在雲中運行相同的應用程序的方式相去甚遠。我知道，要想讓它發揮做用，就必須有一個儘量接近部署到新平臺的快速本地環境。我最終在這裏構建的工具不只能夠用於本地環境，還能夠用於咱們的雲堆棧。

在筆記本電腦上運行本身的Kubernetes集羣並不徹底是輕量級的。咱們須要一個不涉及VM或其餘雲資源的解決方案。我還須要一些輕量級的、容易拆卸和從新配置的、在WSL2（個人環境）和Linux（其餘開發者+咱們的CI）上工做的東西。

Hello kind, Kubernetes-IN-Docker。這個項目最初是爲處理Kubernetes的持續集成測試而構建的，很是適合咱們的需求。我但願咱們的開發者可以在15分鐘內從零起步，建立一個包含20多個服務和配套基礎設施組件的完整工做應用程序棧。此外，部署新構建須要花費幾秒鐘的時間。

cmdr是什麼？

爲了管理本地環境的過程，我建立了一個Python應用程序「cmdr」，它處理配置類型、安裝Traefik、MetalLB，以及經過Helm部署咱們的基礎設施、應用程序和UI組件。咱們已經標準化瞭如何命名、構建和配置咱們的服務，因此一切都已經抽象和DRY（Don't Repeat Yourself）--這使得建立新服務對於Single Music團隊的開發者來講至關輕鬆。

除了本地引導程序外，我還建立了一個deploy命令，該命令接受一個項目名稱，該名稱在整體上的projects.yaml文件中引用，而後提取特定於環境的詳細信息（入口端點，環境配置）以應用到該項目的相關Helm chart。咱們爲基礎設施組件使用了一些開源Helm chart，如MySQL、Postgres、Redis、RabbitMQ和Confluent Cloud（Kafka）。deploy命令也接受env標誌、鏡像標籤、應用程序版本，全部這些配置元數據和chart特定的版本標籤，幫助咱們在EKS中跟蹤環境中的應用程序版本。

開發者還構建了一個命令「promote」，經過GitLab流水線從咱們的登臺環境（咱們的CI是惟一可以部署到咱們集羣的代理）提高應用。此時，咱們已經準備好在託管的Kubernetes環境中運行咱們的服務。咱們選擇Amazon EKS是由於咱們已經在該提供商中運行，而且剛剛購買了價值幾千美圓的保留實例。咱們還將全部客戶的音樂安全存儲在S3中，並依賴於他們的其餘數據服務，如Redshift和RDS。各位，供應商鎖定是真的。

第二步：一步一步來

Single Music天天要處理大約150萬筆交易。擴展或失敗的遷移將是一場災難。除了構建開發人員可使用的環境以外，咱們還必須確保咱們也使用兼容的基礎架構組件，包括從Traefik 1.7升級到2.2，利用他們的新CRD以及使用Bitnami Redis和RabbitMQ chart，所以咱們的緩存和消息傳遞系統能夠在不久的未來進行擴展並高度可用。

遷移Traefik

雖然繼續使用Traefik 1.7和「official/stable」Helm chart能夠工做，但這並無意義，有三個緣由：

1. Traefik 1.7的支持將於2021年結束
2. Traefik 2.x引入了現代概念，如服務、路由器和中間件，新的helm chart利用了CRD，這有助於減小注釋的混亂
3. Containous正處於從「stable」變爲官方支持的圖表的過程當中，由於它在今年年末被棄用，許多其餘的維護者也是如此。

咱們還認識到從1.7到2.x的遷移須要一種新的配置方法，既然咱們已經從Swarm遷移到Kubernetes，咱們如今就應該繼續使用最新版本。

升級後，咱們能夠選擇利用現有的Kubernetes Ingress模式以及註釋，或利用CRD--對咱們來講，使用CRD選項很合適，由於它減小了在已經有些複雜的清單中添加和管理一堆條件註釋的麻煩。

遷移基礎設施

在Kubernetes以前，咱們使用Redis的單個實例來處理緩存和鎖定問題，使用RabbitMQ來處理異步任務隊列。在將來一兩年的某個時候，咱們的工做負載將須要向外擴展這些技術，以處理預計的事務負載。咱們也在完善咱們的分析平臺，而且已經開始爲這個項目實施Kafka和Redshift。

咱們的生產工做負載徹底依賴於咱們的事務性數據存儲（RDS、Redshift、Kafka）的託管服務，但咱們的非生產環境利用了同等的開源服務。遷移到Kubernetes意味着，當咱們最終不得不處理生產中的RabbitMQ和Redis時，咱們能夠選擇利用操做器來實現這些技術，同時也能夠爲咱們的交易組件提供非生產環境。咱們在實現RabbitMQ和Redis的bitnami chart時沒有遇到任何麻煩，同時使用Kafka的官方confluent helm圖表。

咱們尚未開始擴展這些組件，但咱們已經準備好了，能夠先在本地進行試驗，而後最終在生產中實現高可用性。若是不先遷移到Kubernetes，就不可能同時得到商業和社區對該功能的支持。

準備……哎呀……

咱們達到了開發環境的基準，成功地在EKS上搭建了咱們的平臺，成功地遷移了咱們的關鍵基礎設施組件，並解決了咱們發現的一些問題。

咱們發現的一個值得注意的問題是，當咱們捕獲用戶地理位置數據時，服務在處理交易時開始失敗。現代負載平衡器生成一個「X-Forwarded-For」頭，它容許目標服務經過驗證請求鏈中代理的子網來驗證事務，但它也是咱們的報告系統的真相來源。一開始，咱們只是簡單地將缺乏頭信息的緣由，歸咎於Metallb和本地環境的古怪，可是咱們很快發現這個問題也出如今EKS的登臺（staging）環境中，這個環境最終將成爲咱們的生產環境。

確保咱們的客戶對其客戶的購買有準確的報告數據是沒有商量餘地的。遷移被阻塞，直到咱們可以肯定問題。幸運的是，個人整個DevOps職業生涯實際上只是在谷歌上搜索時的偶然運氣，我發現了最有可能致使這個問題的緣由。Spring Boot的最新版本引入了一種行爲變化，即運行時檢測到它正在Kubernetes上運行，並簡單地刪除了header，這致使咱們的服務在嘗試讀取該鍵值時失敗。

第三步：上線！

當咱們配置好集羣，並確認全部工做負載在登臺環境上都是可操做的，實際的遷移就很簡單了。因爲咱們的服務徹底是基於webhook和消息的，咱們能夠在數據庫被移動後，讓隊列耗盡，並切換工做負載。咱們預計此次行動將不超過30分鐘，分爲三個階段：

1. 咱們的關鍵基礎設施組件，如Traefik、Redis和RabbitMQ，已經在生產命名空間中運行。咱們繼續在維護模式下運行咱們的着陸服務，並將咱們在Route 53的全部A記錄，指向已經註冊了上述Traefik服務的新ALB。任何請求都將使用503維護頁面來回答。
2. 這容許隊列耗盡咱們的Swarm集羣，此時咱們中止了Swarm中的全部生產服務，並開始將RDS實例移動到新的VPC上。咱們不知道這將花費多長時間，最終它花了大部分時間來進行遷移。數據庫在新的VPC中以後，咱們驗證了集羣中的鏈接性，而後進入下一個步驟。
3. 咱們開始了打開服務和關閉維護模式的過程。咱們啓動了事件分派器，它處理傳入的webhook，以及咱們的UI服務和API。當確認工做正在排隊，咱們便履行服務，並使用APM提供商DataDog密切關注咱們的基礎架構指標和跟蹤遙測，以避免出現麻煩。

幾個小時後，咱們沒有注意到任何問題，全部跡象都代表這是一次很是成功的遷移。

回顧

整個遷移過程大約花了三週時間。若是沒有咱們團隊中開發者的支持，這是不可能的。當他們遷移到一個新的開發平臺，並忍受因爲使用和適應新工具而帶來的不便時，他們會不斷地提供反饋。總的來講，Kubernetes的遷移，對於Single Music來講是一個巨大的成功。咱們解決了業務運營的主要風險，提升了咱們的可靠性、容錯性和增加能力，同時下降了開發和運營成本。

若是沒有Kubernetes、Helm、Traefik等開源項目，像如今這樣的項目將須要更多的工程師和複雜性。很是感謝Docker團隊將SwarmKit做爲咱們啓動的初始平臺，併爲咱們提供了支持、經驗和實踐，使咱們可以絕不費力地遷移到Kubernetes。咱們感謝社區和工具給了咱們建立服務的機會，幫助小型獨立藝術家和世界上一些最大的藝術家，將他們的創做直接帶給他們的觀衆。

參與

儘管咱們的堆棧中有許多關鍵組件，其中一個從一開始就存在的組件是Traefik。做爲CNCF的成員和開源人士，有不少不一樣的方式加入Traefik社區，並瞭解更多關於Containous構建的產品和解決方案：

• 在咱們的社區論壇上與其餘Traefik用戶和開發者進行交流
• 在咱們的Github倉庫的各類Containous項目作出貢獻
• 瞭解更多關於Traefik如何爲開發者提供靈活易用的Kubernetes Ingress的信息

你能夠在社區論壇上找到咱們的Traefik大使和維護者，包括我本身，或者你能夠直接經過電子郵件kevin.crawley@containo.us聯繫我。

點擊閱讀網站原文。

---

CNCF (Cloud Native Computing Foundation)成立於2015年12月，隸屬於Linux  Foundation，是非營利性組織。
CNCF（雲原生計算基金會）致力於培育和維護一個廠商中立的開源生態系統，來推廣雲原生技術。咱們經過將最前沿的模式民主化，讓這些創新爲大衆所用。掃描二維碼關注CNCF微信公衆號。