# 從裸機到 Kubernetes > 原文： [http://highscalability.com/blog/2019/4/8/from-bare-metal-to-kubernetes.html](http://highscalability.com/blog/2019/4/8/from-bare-metal-to-kubernetes.html)  *這是位于舊金山的零售服裝公司和眾籌平臺 [Betabrand](https://www.betabrand.com) 的首席工程師 [Hugues Alary](https://www.linkedin.com/in/huguesalary/?locale=en_US) 的特邀帖子。 本文最初在此處發表[。](https://boxunix.com/post/bare_metal_to_kube/)* * [早期基礎架構](#_early_infrastructure) * [VPS](#_vps) * [機架空間](#_rackspace) * [OVH](#_ovh) * [硬件基礎結構](#_hardware_infrastructure) * [可伸縮性和可維護性問題](#_the_scalability_and_maintainability_issue) * [擴展開發流程](#_scaling_development_processes) * [Docker](#_the_advent_ofdocker) 的出現 * [調速器](#_kubernetes) * [學習 Kubernetes](#_learning_kubernetes) * [正式遷移](#_officially_migrating) * [開發/分階段環境](#_the_developmentstaging_environments) * [在](#_a_year_after)之后一年 如何將 [Betabrand](https://www.betabrand.com) 的裸機基礎架構遷移到托管在 Google Container Engine 上的 Kubernetes 集群，從而解決了許多工程問題-從硬件故障到生產服務的可伸縮性不足，復雜的配置管理和高度異構的開發 -分階段生產環境-使我們能夠實現可靠，可用和可擴展的基礎架構。 這篇文章將引導您了解 Betabrand 從 2011 年到 2018 年遇到的許多基礎架構變更和挑戰。 * * * ## 早期基礎設施 ### VPS 在我工作的 7 年中，Betabrand 的基礎架構發生了許多次變化。 2011 年，也就是我們的 CTO 雇用我的那一年，該網站托管在具有 Plesk 界面且沒有 root 訪問權限的共享服務器上（當然）。 每封新聞通訊（最多發送給數百人）都會使該網站屈服并使其爬行，有時甚至完全無響應。 我的第一筆生意就是尋找替代品，并將網站轉移到自己的專用服務器上。 ### 機架空間 經過幾天的在線研究，我們在 Rackspace 上安裝了 VPS-8GB RAM，320GO 磁盤，4 個虛擬 CPU，150Mbps 帶寬。 再過幾天，我們就生活在由……1 臺服務器組成的新基礎架構上； 運行帶有 Memcached 提示的典型 Linux，Apache，PHP，MySQL 堆棧。 毫不奇怪，此基礎架構很快就過時了。 它不僅沒有擴展，而且更重要的是，它的每個部分都是單點故障。 阿帕奇下來？ 網站關閉。 Rackspace 實例關閉了嗎？ 網站關閉。 MySQL 崩潰了……您明白了。 它的另一方面是它的成本。 我們的平均每月賬單迅速攀升至 1,000 美元以上。 對于一臺機器和我們當時產生的低流量來說，這是很昂貴的價格。 在運行了該堆棧幾年后，即 2013 年中，我決定是時候讓我們的網站更具可擴展性，冗余性，并且更具成本效益了。 我估計，我們至少需要 3 臺服務器才能使我們的網站有些冗余，這在 Rackspace 上每年高達$ 14400。 作為一家非常小的初創公司，我們無法證明基礎設施賬單的“高價”； 我一直在尋找。 最便宜的選擇最終導致我們的堆棧在裸機服務器上運行。 ### OVH 我過去曾在 OVH 工作過，一直都很滿意（盡管在線上有不同的評論）。 我估計以 OVH 運行 3 臺服務器每年的費用為 3240 美元，幾乎比 Rackspace 便宜 5 倍。 OVH 不僅更便宜，而且其服務器的功能也比 Rackspace 的服務器高出 4 倍：32GB RAM，8 個 CPU，SSD 和無限帶寬。 最重要的是，他們剛剛在北美開設了一個新的數據中心。 幾周后，Betabrand.com 被托管在加拿大博哈努瓦的 OVH。 ## 硬件基礎架構 在 2013 年至 2017 年之間，我們的硬件基礎架構經歷了一些架構更改。 到 2017 年底，無論是在軟件還是在硬件方面，我們的堆棧都大大超過了以往。 Betabrand.com 在 17 臺裸機上運行： * 2 臺負責 SSL 卸載的 HAProxy 機器配置為熱備用 * 在我們的 Web 服務器的熱備用負載均衡中配置了 2 個清漆緩存計算機 * 5 臺運行 Apache 和 PHP-FPM 的計算機 * 2 個 Redis 服務器，每個服務器運行 2 個獨立的 Redis 實例。 1 個實例用于某些應用程序緩存，1 個實例用于我們的 PHP 會話 * 3 臺配置為 master-master 的 MariaDB 服務器，但以 master-slave 方式使用 * 3 個 Glusterd 服務器為我們所有的靜態資產服務 否則，每臺計算機都將運行一個或多個進程，例如 keepalived，Ganglia，Munin，logstash，exim，備份管理器，有監督的，sshd，fail2ban，prerender，rabbitmq 和 docker。 但是，盡管此基礎架構非常便宜，冗余且沒有單點故障，但它仍不可擴展，并且維護起來也非常困難。 ### 可伸縮性和可維護性問題 現在，管理服務器“艦隊”需要編寫一組 Ansible 腳本并進行維護，盡管 Ansible 是一款出色的軟件，但這絕非易事。 盡管 Ansible 會竭盡所能，但是 Ansible 不能保證您的系統狀態。 例如，在由異構 OS（例如 debian 8 和 debian 9）組成的服務器機群上運行 Ansible 腳本，會使所有計算機的狀態都接近您定義的狀態，但是最終可能會出現差異。 第一個是您在 Debian 8 和 Debian 9 上運行，但是在某些服務器和其他服務器上，軟件版本和配置也不同。 > 我經常搜索 Ansible 替代品，但從未發現更好。 > > 我看了看 Puppet，但發現它的學習曲線太陡峭了，從閱讀別人的食譜中，*似乎*似乎以太多不同的方式來做同樣的事情。 有些人可能認為這是靈活性，我認為這是復雜性。 > > SaltStack 引起了我的注意，但也發現很難學習。 盡管他們進行了廣泛而深入的文檔編制，但他們的命名選擇（礦井，礦井，鹽等）從未對我產生影響； 在復雜性方面，它似乎遭受了與 Puppet 相同的問題。 > > Nix 軟件包管理器和 NixOS 聽起來很棒，除了我對學習全新的操作系統感到不舒服（我已經使用 Debian 多年了），并擔心盡管選擇了大量的軟件包，但最終我仍需要軟件包 可用，這將成為新的維護對象。 > > 這些是我查看過的僅有的 3 個工具，但我敢肯定還有很多其他我可能從未聽說過的工具。 然而，編寫 Ansible 腳本并進行維護并不是我們唯一的問題； 增加容量是另一個。 對于裸機，無法即時添加和刪除容量。 您需要提前計劃好您的需求：購買一臺機器-通常租用至少 1 個月-等待其準備就緒-可能需要 2 分鐘至 3 天的時間-安裝其基本操作系統， 安裝 Ansible 的依賴項（主要是 python 和其他一些軟件包），然后最后對它運行 Ansible 腳本。 對我們來說，整個過程是完全不切實際的，通常發生的事情是，我們會為預期的峰值負載增加容量，但之后再也不會刪除它，這反過來又增加了我們的成本。 但是，值得注意的是，即使基礎架構中未使用的容量類似于在燒錢，但在裸機上的成本仍比在云中便宜得多。 另一方面，使用裸機服務器帶來的工程難題只是將成本從純粹的材料成本轉移到了管理成本。 在我們的裸機設置容量計劃中，服務器管理和 Ansible 腳本只是冰山一角。 ### 擴展開發流程 在 2017 年初，雖然我們的基礎架構有所發展，但我們的團隊也有所發展。 我們又雇用了 7 名工程師，使我們的團隊由 9 人組成，其技能組從后端到前端遍布各個領域，并具有不同的資歷水平。 即使在一個只有 9 人的小型團隊中，也要保持生產效率并限制部署到生產中的錯誤數量，就可以確保簡單，易于設置和易于使用的開發，分階段和生產三聯產品。 將您的開發環境設置為新員工，無需花費數小時，也無需升級或重新創建它。 此外，應該存在公司范圍內可訪問的登臺環境，該環境應與您的產品的 99％（如果不是 100％）相匹配。 不幸的是，在我們的硬件基礎架構中，達到這種和諧的三重奏是不可能的。 ### 開發環境 首先，我們工程團隊中的每個人都使用 MacBook Pro，這是一個問題，因為我們的堆棧基于 Linux。 但是，要求所有人切換到 Linux 并可能更改他們寶貴的工作流程并不是一個理想的選擇。 這意味著最好的解決方案是提供一個與開發人員的機器偏好無關的開發環境。 我只能看到兩個明顯的選擇： 提供一個可以運行多個虛擬機的 Vagrant 堆棧（實際上更可能是 17 個計算機運行我們的整個堆棧），或者重新使用已經編寫的 ansible 腳本，然后對我們的本地 macbook 運行它們。 在調查了 Vagrant 之后，我覺得使用虛擬機會嚴重影響性能，這是不值得的。 我決定（不管是好是壞）走 Ansible 路線（事后看來，這可能不是最好的決定）。 我們將在生產，登臺和開發中使用相同的 Ansible 腳本集。 當然，我們的開發堆棧雖然接近生產，但并不是 100％匹配。 這足夠好一段時間了。 但是，這種失配會在以后（例如，我們的開發和生產 MySQL 版本未統一）時引起問題。 一些在開發人員上運行的查詢不會在生產環境中使用。 #### 暫存環境 其次，在不同的軟件（mac os 與 debian）上運行開發和生產環境意味著我們絕對需要一個暫存環境。 不僅是由于版本不匹配導致的潛在錯誤，還因為我們需要一種在發布之前與外部成員共享新功能的方法。 我再次有多種選擇： * 購買 17 臺服務器并對它們運行 ansible。 但是，這會使我們的成本增加一倍，并且我們試圖節省資金。 * 在一個可以從外部訪問的獨特的 linux 服務器上設置我們的整個堆棧。 更便宜的解決方案，但再次沒有提供我們生產系統的精確副本。 我決定實施節省成本的解決方案。 暫存環境的早期版本涉及 3 個獨立的 linux 服務器，每個服務器運行整個堆棧。 然后，開發人員會在整個房間（或聊天室）大喊大叫，“接管 dev1”，“有人在使用 dev3 嗎？”，“ dev2 關閉了：/”。 總體而言，我們的開發，分階段和生產設置遠非最佳：它可以完成工作； 但絕對需要改進。 ## Docker 的出現 2013 年，Dotcloud 發布了 Docker。 Docker 的 Betabrand 用例立即顯而易見。 我將其視為簡化我們的開發和登臺環境的解決方案。 通過擺脫煩人的腳本（好吧，差不多；稍后再介紹）。 這些腳本現在僅用于生產。 當時，團隊面臨的一個主要痛點是競爭我們的三臺物理登臺服務器：dev1，dev2 和 dev3；另一臺服務器是 dev3。 對我來說，維護這 3 臺服務器是一個很大的麻煩。 在觀察了 docker 幾個月后，我決定在 2014 年 4 月試用它。 在其中一個登臺服務器上安裝 docker 之后，我創建了一個包含整個堆棧（haproxy，清漆，redis，apache 等）的 docker 映像，然后在接下來的幾個月中編寫了一個工具（`sailor`），使我們可以創建 ，銷毀和管理可通過單獨的唯一 URL 訪問的無限數量的登臺環境。 > 值得一提的是，當時 docker-compose 還不存在； 而且將整個堆棧放入一個 docker 映像中當然是很大的禁忌，但這在這里并不重要。 從那時起，團隊不再競爭訪問登臺服務器。 任何人都可以使用 Sailor 從 Docker 映像創建一個完全配置的新登臺容器。 我也不再需要維護服務器； 更好的是，我關閉并取消了其中的 2 個。 但是，我們的開發環境仍在 macos（當時為“ Mac OS X”）上運行，并使用 Ansible 腳本。 然后，大約在 2016 年 docker-machine 被釋放。 Docker machine 是一種工具，可在您選擇的任何堆棧上部署 docker 守護進程：virtualbox，aws，gce，bare-metal，azure（由您命名），docker-machine 可以完成； 在一個命令行中。 我將其視為輕松，快速地將基于 ansible 的開發環境遷移到基于 docker 的機會。 我修改了`sailor`以使用 docker-machine 作為其后端。 設置開發環境現在只需創建一個新的 docker-machine，然后傳遞一個標志供水手使用即可。 至此，我們的開發階段流程已大大簡化； 至少從開發人員的角度來看：每當我需要將我們的堆棧中的任何軟件升級到較新版本或更改配置時，都無需修改我的 ansible 腳本，而是要求所有團隊來運行它們，然后自己在所有 3 個設備上運行它們 登臺服務器； 我現在可以簡單地推送一個新的 docker 映像。 具有諷刺意味的是，我最終需要虛擬機（故意避免使用）在我們的 macbook 上運行 docker。 從一開始，使用無業游民而不是 Ansible 是一個更好的選擇。 后視總是 20/20。 將 docker 用于我們的開發和登臺系統為 Betabrand.com 現在運行的更好的解決方案鋪平了道路。 ## 州長 由于 Betabrand 主要是一個電子商務平臺，因此黑色星期五每年越來越多地出現在我們的網站上。 令我們驚訝的是，自 2013 年以來，該網站已處理了越來越多的負載，而沒有發生任何重大災難，但是它確實需要提前一個月的準備：盡可能地增加容量，負載測試和優化我們的結帳代碼路徑。 但是，在為 2016 年黑色星期五做準備之后，很明顯基礎架構無法在 2017 年黑色星期五進行擴展。 我擔心在負載下該網站將無法訪問。 幸運的是，在 2015 年的某個時候，Kubernetes 1.0 的發布引起了我的注意。 就像在 docker 中看到一個明顯的用例一樣，我知道 k8s 是解決許多問題所需要的。 首先，它最終將使我們能夠運行幾乎與*相同的 dev-staging-production 環境。 而且，還將解決我們的可伸縮性問題。* 我還評估了其他兩個解決方案，即 Nomad 和 Docker Swarm，但 Kubernetes 似乎是最有前途的。 對于 2017 年黑色星期五，我著手將整個基礎架構遷移到 k8s。 > 盡管我考慮了這一點，但我很快就排除了將我們當前的 OVH 裸機服務器用于 k8s 節點的問題，因為這將與我擺脫 Ansible 而不是處理硬件服務器附帶的所有問題的目標背道而馳。 此外，在我開始調查 Kubernetes 之后不久，Google 便發布了托管的 Kubernetes（GKE）產品，我很快就選擇了它。 ### 學習 Kubernetes 遷移到 k8 首先需要通過閱讀在線文檔來深入了解其架構和概念。 最重要的是了解容器，容器，部署和服務以及它們如何組合在一起。 然后依次執行 ConfigMaps，Secrets，Daemonsets，StatefulSets，Volumes，PersistentVolumes 和 PersistentVolumeClaims。 其他概念也很重要，盡管使集群前進的必要性較低。 一旦吸收了這些概念，第二個也是最困難的一步就是將我們的裸機架構轉換為一組 YAML 清單。 從一開始，我就打算只有一套清單，用于創建所有三個開發，登臺和生產環境。 我很快就遇到了需要參數化我的 YAML 清單的問題，而 Kubernetes 并不能立即使用它。 這是 Helm ^{[ [1](#_footnotedef_1 "View footnote.") ]} 派上用場的地方。 > Helm 網站的*：Helm 幫助您管理 Kubernetes 應用程序-Helm Charts 幫助您定義，安裝和升級最復雜的 Kubernetes 應用程序。* Helm 將自己定位為 Kubernetes 的程序包管理器，但我最初只是將其用于模板功能。 現在，我也開始欣賞它的軟件包管理器方面，并用它來安裝 Grafana ^{[ [2](#_footnotedef_2 "View footnote.") ]} 和 Prometheus ^{[ [3](#_footnotedef_3 "View footnote.") ]} 。 經過一番汗水和幾滴眼淚，我們的基礎架構現在被整齊地組織為 1 個 Helm 程序包，17 個部署，9 個 ConfigMap，5 個 PersistentVolumeClaims，5 個秘密，18 個服務，1 個 StatefulSet，2 個 StorageClasses，22 個容器映像。 剩下的就是遷移到這個新的基礎架構并關閉所有硬件服務器。 ### 正式遷移 2017 年 10 月 5 日是夜晚。 扣動扳機非常容易，而且順利進行。 我創建了一個新的 GKE 集群，運行`helm install betabrand --name production`，將我們的 MySQL 數據庫導入到 Google Cloud SQL 中，然后，實際上花費了大約 2 個小時，我們才生活在 Clouds 中。 遷移很簡單，就是。 當然，最有用的是在 Google GKE 中創建多個集群的能力：在遷移產品之前，我能夠通過多次測試遷移進行排練，記下成功啟動所需的每個步驟。 Betabrand 的黑色星期五 2017 年非常成功，我們遇到的一些技術問題與遷移無關。 ### 開發/分期環境 我們的開發機器通過 Minikube ^{[ [4](#_footnotedef_4 "View footnote.") ]} 運行 Kubernetes 集群。 相同的 YAML 清單用于創建本地開發環境或“類似生產”的環境。 在生產環境中運行的所有內容，也在開發環境中運行。 兩種環境之間的唯一區別是，我們的開發環境與本地 MySQL 數據庫對話，而生產與 Google Cloud SQL 對話。 創建登臺環境與創建新的生產集群完全相同：所需要做的只是克隆生產數據庫實例（只需單擊幾下或一個命令行），然后通過`--set database`將登臺集群指向該數據庫。 `helm`中的]參數。 ### 一年后 從我們將基礎架構移至 Kubernetes 至今已經一年零兩個月了，我再也高興不起來了。 Kubernetes 在生產中一直堅如磐石，我們還沒有遇到過停機的情況。 預計 2018 年黑色星期五將有大量流量，我們能夠在幾分鐘內創建生產服務的精確副本并進行大量負載測試。 這些負載測試顯示特定的代碼路徑性能非常差，只能顯示大量流量，因此我們可以在黑色星期五之前修復它們。 不出所料，2018 年黑色星期五給 Betabrand.com 帶來了前所未有的流量，但是 k8s 兌現了承諾，而 Horizo??ntalPodAutoscaler 與 GKE 的節點自動縮放相結合的功能使我們的網站能夠毫無問題地吸收峰值負載。 K8 與 GKE 相結合，為我們提供了使我們的基礎架構可靠，可用，可伸縮和可維護所需的工具。 * * * [1](#_footnoteref_1). [https://helm.sh/](https://helm.sh/)[2](#_footnoteref_2). [https://grafana.com/](https://grafana.com/)[3](#_footnoteref_3). [https://prometheus.io/](https://prometheus.io/)[4](#_footnoteref_4). [https://github.com/kubernetes/minikube](https://github.com/kubernetes/minikube) 雨果，好帖子！ 真的很脆，沒有花哨/不必要的術語。 我很好奇看到您每月帳單的比較-OVH 裸機與 GCP K8S I too am curious to see a comparison of your monthly bill - OVH bare-metall vs GCP K8S...?? 您認為這對這家公司來說太過分了嗎？ 我一直都很喜歡 Kube，不是因為業務需要它，而是因為人們喜歡高科技。 IDK，只是想一想 為什么不使用不同的名稱空間進行測試和暫存，而不是創建不同的集群？