嘿哈布爾！
我們代表 Exness 平台團隊。 之前我們的同事已經寫過一篇文章 。 今天我們想分享我們將服務遷移到 Kubernetes 的經驗。
首先，我們為您提供一些數字，以便您更好地了解將討論的內容：
- 我們的開發部門由 100 多人組成，其中包括 10 多個不同的團隊，擁有獨立的 QA、DevOps 和 Scrum 流程。 開發堆疊 - Python、PHP、C++、Java 和 Golang。
- 測試和生產環境的規模各約為 2000 個容器。 他們在自己的虛擬化和 VMware 下運行 Rancher v1.6。
動機
正如人們所說，沒有什麼是永恆的，Rancher 很久以前就宣布結束對 1.6 版本的支援。 是的，在三年多的時間裡我們已經學會瞭如何準備並解決出現的問題，但我們越來越多地面臨著永遠無法糾正的問題。 Rancher 1.6 還有一個僵化的權利發行系統，你要嘛幾乎可以做任何事情，也可以什麼都不做。
儘管專有虛擬化提供了對資料儲存及其安全性的更大控制，但鑑於公司的不斷增長、專案數量及其要求，它帶來了難以接受的營運成本。
我們希望遵循 IaC 標準，並在必要時在任何地理位置快速獲得容量且不受供應商鎖定，也能夠快速放棄它。
第一步驟
首先，我們希望依靠現代技術和解決方案，使團隊能夠擁有更快的開發週期，並最大限度地降低與提供動力的平台互動的營運成本。
當然，我們首先想到的是 Kubernetes，但我們並沒有興奮，而是做了一些研究，看看它是否是正確的選擇。 我們只評估開源解決方案，在一場不公平的戰鬥中，Kubernetes 無條件獲勝。
接下來是選擇建立叢集的工具的問題。 我們比較了最受歡迎的解決方案：kops、kubespray、kubeadm。
首先，kubeadm 在我們看來是一條過於複雜的道路，更像是「自行車」的發明者，而 kops 沒有足夠的靈活性。
獲勝者是：
我們開始嘗試自己的虛擬化和 AWS，嘗試重新建立與我們先前的資源管理模式大致相似的東西，其中每個人共享相同的「叢集」。 現在，我們擁有了第一個由 10 個小型虛擬機器組成的集群，其中幾個位於 AWS 中。 我們開始嘗試將團隊遷移到那裡，一切似乎都“很好”，故事可以結束了，但是…
第一個問題
Ansible 是 kubespray 的基礎，它不是一個允許您遵循 IaC 的工具：在調試/停用節點時，不斷出現問題並需要某種幹預，並且當使用不同的操作系統時，劇本的行為不同。 。 隨著叢集中團隊和節點數量的增加，我們開始注意到 playbook 的完成時間越來越長，結果我們的記錄是 3,5 小時，你們的呢？ 🙂
看起來 kubespray 就是 Ansible，乍看之下一切都很清楚，但：
在旅程開始時，任務是僅在 AWS 和虛擬化中啟動功能，但隨後，正如經常發生的那樣，需求發生了變化。
有鑑於此，很明顯，我們將資源組合到一個編排系統中的舊模式並不適合 - 在叢集非常遙遠且由不同提供者管理的情況下。
另外。 當所有團隊在同一個叢集中工作時，節點選擇器安裝不正確的各種服務可能會飛到另一個團隊的「外部」主機並利用那裡的資源，並且如果設定了污點，則會不斷出現一個或另一個服務無法工作的請求，由於人為因素導致分配不正確。 另一個問題是計算成本，特別是考慮到跨節點分發服務的問題。
另一個故事是向員工發放權利：每個團隊都希望成為集群的「領導者」並完全管理它，這可能會導致徹底崩潰，因為團隊基本上是相互獨立的。
怎麼辦呢？
考慮到上述情況以及團隊更獨立的願望，我們做出了一個簡單的結論：一隊一集群。
所以我們得到了第二個：
然後是第三個簇：
然後我們開始思考：假設一年後我們的團隊將擁有多個集群？ 例如，在不同的地理區域，或在不同的提供者的控制下？ 其中一些會希望能夠快速部署臨時叢集來進行一些測試。
完整的 Kubernetes 即將到來！ 事實證明，這是某種 MultiKubernetes。
同時，我們都需要以某種方式維護所有這些集群，能夠輕鬆管理對它們的訪問，以及創建新集群和退役舊集群，而無需手動幹預。
自從我們開始進入 Kubernetes 世界以來已經過去了一段時間，我們決定重新檢查可用的解決方案。 事實證明，市場上已經存在——Rancher 2.2。
在我們研究的第一階段，Rancher Labs 已經發布了第2 版，雖然可以透過啟動一個沒有外部依賴且帶有幾個參數的容器或使用官方HELM Chart 來非常快速地提升版本XNUMX，但它看起來很粗糙對我們來說，我們不知道我們是否可以依賴這個決定，無論它會被開發還是很快就被放棄。 UI 本身中的 cluster = clicks 範例也不適合我們，而且我們不想與 RKE 聯繫在一起，因為它是一個關注範圍相當狹窄的工具。
Rancher 2.2 版本已經具有更實用的外觀，並且與先前的版本一起，具有許多開箱即用的有趣功能，例如與許多外部提供者整合、權限和 kubeconfig 檔案的單點分發、啟動 kubectl具有您在UI中的權限的圖像，嵌套命名空間又稱為項目。
還有一個圍繞著 Rancher 2 形成的社區，並創建了一個名為 HashiCorp Terraform 的提供者來管理它，這幫助我們將所有內容整合在一起。
發生了什麼事
結果，我們最終得到了一個運行 Rancher 的小型集群，所有其他集群以及連接到它的許多集群都可以訪問，對其中任何集群的訪問都可以像將用戶添加到 ldap 目錄一樣簡單地授予，無論它位於哪裡以及它使用哪個提供者的資源。
使用 gitlab-ci 和 Terraform 創建了一個系統，可讓您在雲端供應商或我們自己的基礎架構中建立任何配置的集群，並將它們連接到 Rancher。 所有這些都是以 IaC 風格完成的，其中每個叢集都由儲存庫描述，並且其狀態是版本化的。 同時，大多數模組都是從外部儲存庫連接的，因此剩下的就是傳遞變數或描述實例的自訂配置，這有助於減少程式碼重複的百分比。
當然，我們的旅程還遠遠沒有結束，前面仍然有許多有趣的任務，例如使用任何叢集的日誌和指標的單點工作、服務網格、用於管理多叢集中負載的 gitop 等等。 我們希望您覺得我們的經驗很有趣！
本文由平台工程師 A. Antipov 和 A. Ganush 撰寫。
來源： www.habr.com