ShareThis：生產環境中的 Kubernetes

ShareThis 自最初作為一個允許您分享到您喜愛社交服務的小部件以來，已經取得了巨大的發展。它現在每月服務超過450萬個域名，幫助出版商創造更真實的數字體驗。

快速增長也付出了代價。為了快速擴充套件和發展我們的產品，我們利用了技術債務，尤其是在基礎設施方面。隨著公司的擴張，基礎設施成本也隨之增加——無論是低效利用還是人員成本。大約1年前，很明顯需要做出改變。

TL;DRKubernetes 一直是我們透過以下方式減少基礎設施技術債務的關鍵組成部分：

• 促進 Docker 的採用
• 簡化容器管理
• 為開發人員提供基礎設施培訓
• 實現持續整合和交付。我們透過徹底採用 Kubernetes 並將我們的 DevOps 團隊轉變為一個在容器和微服務方面工作的雲平臺團隊來實現這一目標。這包括建立一些工具來解決我們自己的遺留債務。

問題

唉，雲計算是新事物，我們當時也很年輕。我們從傳統的資料中心思維方式開始。我們管理所有自己的服務：MySQL、Cassandra、Aerospike、Memcache，等等。我們像傳統伺服器一樣設定虛擬機器，在上面安裝我們的應用程式，並在 Nagios 或 Ganglia 中進行管理。

不幸的是，這種思維方式與以云為中心的方法背道而馳。我們不是從服務的角度思考，而是從伺服器的角度思考。我們沒有使用現代的雲方法，如自動伸縮、微服務，甚至託管虛擬機器，而是考慮指令碼化設定、伺服器部署和避免供應商鎖定。

這些思維方式本身並沒有錯，它們只是效率低下。它們沒有充分利用雲端正在快速發生的變化。這也意味著，當需要進行更改時，我們將其視為資料中心的重大緩慢更改，而不是雲端的小型快速更改。

解決方案

Kubernetes 作為促進 Docker 採用的工具

隨著 Docker 在我們行業中變得越來越強大，ShareThis 的工程師也開始嘗試並取得了良好的效果。很快就顯而易見，我們需要為公司中的每個應用程式提供一個工作容器，以便簡化開發環境中的測試。

一些應用程式很快遷移到 Docker，因為它們簡單且依賴項少。對於那些依賴項較小的應用程式，我們能夠使用 Fig（Fig 是 Docker Compose 的原始名稱）進行管理。儘管如此，我們的許多資料管道或相互依賴的應用程式都過於複雜，無法直接 Docker 化。我們仍然想這樣做，但 Docker 仍不足夠。

2015年末，我們對遺留基礎設施的沮喪情緒達到了頂點，最終下定決心。我們評估了 Docker 的工具、ECS、Kubernetes 和 Mesosphere。很快就發現，Kubernetes 在穩定性和使用者友好性方面比其競爭對手更適合我們的基礎設施。作為一家公司，我們可以透過簡單地設定將所有基礎設施都遷移到 Kubernetes 的目標來鞏固我們在 Docker 上的基礎設施。

工程師們一開始持懷疑態度。然而，一旦他們看到應用程式能夠輕鬆擴充套件到每個應用程式數百個例項，他們就被迷住了。現在，不僅有痛點推動我們轉向 Docker，進而轉向 Kubernetes，而且對這項技術也產生了真正的興奮感。這使我們能夠相當快地完成一次極其困難的遷移。我們現在在多個區域執行 Kubernetes，大約有65個大型虛擬機器，並將在未來幾個月內增加到100多個。我們的 Kubernetes 叢集目前每天處理8億個請求，並計劃在未來幾個月內每天處理超過20億個請求。

Kubernetes 作為容器管理工具

我們最早使用 Docker 在開發方面前景光明，但在生產方面卻不盡如人意。最大的摩擦點是無法大規模管理 Docker 元件。知道哪些容器在哪裡執行，正在執行哪個部署版本，應用程式處於什麼狀態，如何管理子網和 VPC 等問題，都阻礙了它投入生產。所需的工具將是巨大的。

當您檢視 Kubernetes 時，有幾個關鍵功能立即吸引了我們：

• 它很容易安裝在 AWS 上（我們所有的應用程式都在那裡執行）
• 透過 yaml/json 檔案，從 Dockerfile 到複製控制器有直接路徑
• Pod 數量可以輕鬆擴充套件
• 我們可以輕鬆擴充套件 Kubernetes 叢集中 AWS 上執行的虛擬機器數量
• 滾動部署和回滾內置於工具中
• 每個 pod 都透過健康檢查進行監控
• 服務終結點由工具管理
• 擁有一個活躍而充滿活力的社群

不幸的是，最大的痛點之一是這些工具並沒有解決我們現有的遺留基礎設施問題，它只是提供了一個可以遷移到的基礎設施。仍然存在各種網路問題，導致我們無法將應用程式直接遷移到新的 VPC 上。此外，對如此多應用程式的重構要求開發人員解決傳統上由系統管理員和運營團隊解決的問題。

Kubernetes 作為開發人員基礎設施培訓工具

當我們決定從本質上由 Chef 執行的設定切換到 Kubernetes 時，我想我們並沒有完全理解所有會遇到的痛點。我們的伺服器以各種不同的方式執行，配置了各種不同的網路，這與在全新 Kubernetes VPC 上找到的乾淨設定大相徑庭。

在生產環境中，我們同時在多個區域的 AWS VPC 和 AWS 經典環境中執行。這意味著我們管理著幾個具有不同訪問控制的子網，這些子網跨越不同的應用程式。我們最近的應用程式也高度安全，沒有公共端點。這意味著我們結合了 VPC 對等、網路地址轉換 (NAT) 和以各種配置執行的代理。

在 Kubernetes 世界中，只有 VPC。所有 Pod 理論上都可以相互通訊，並且服務終結點被明確定義。開發人員很容易忽略一些細節，並且它消除了（大部分）對操作的需求。

我們決定將所有基礎設施/DevOps 開發人員轉變為應用程式開發人員（真的！）。我們本來就根據他們的開發技能而非操作技能進行招聘，所以這聽起來可能沒有那麼瘋狂。

然後，我們決定對整個工程組織進行運維培訓。開發人員適應性強，喜歡挑戰，也喜歡學習。這真是了不起。僅僅一個月後，我們的組織就從只有少數 DevOps 人員，變成了每個工程師都能修改我們架構的團隊。

網路、生產化、問題解決、根本原因分析等方面的入職培訓，都是在將 Kubernetes 大規模投入生產中進行的。第一個月後，我還在咬指甲，擔心我們的選擇。兩個月後，它看起來可能有一天會變得可行。三個月後，我們每週部署 10 次。四個月後，每週部署 40 個應用程式。雖然只有 30% 的應用程式完成了遷移，但所獲得的收益不僅顯著，而且令人驚歎。Kubernetes 讓我們從一個“基礎設施拖慢我們速度，太糟糕了！”的組織，變成了一個“基礎設施加速我們速度，太棒了！”的組織。

Kubernetes 作為實現持續整合和交付的手段

我們是如何做到每週部署40多次的？簡單來說，持續整合和部署（CI/CD）是我們遷移的副產品。我們在 Kubernetes 中的第一個應用程式是 Jenkins，並且每個進入 Kubernetes 的應用程式也都新增到了 Jenkins。隨著我們前進，我們使 Jenkins 變得更加自動化，直到 Pod 被新增到 Kubernetes 和從 Kubernetes 中移除的速度快得我們無法跟上。

有趣的是，我們現在面臨的擴充套件問題是，想要同時推出太多更改，人們不得不等待輪到他們。我們的目標是透過新基礎設施每週實現100次部署。如果我們能繼續執行我們的遷移和對 Kubernetes 和 Jenkins 上 CI/CD 流程的承諾，這是可以實現的。

後續步驟

我們需要完成遷移。目前，問題大多已解決，最大的困難在於任務的繁瑣。將事物從我們的遺留基礎設施中移出意味著更改網路配置，以允許訪問 Kubernetes VPC 及其跨區域。這仍然是一個非常真實的痛點，我們仍在繼續解決。

有些服務在 Kubernetes 中表現不佳——例如有狀態分散式資料庫。幸運的是，我們通常可以將這些服務遷移到第三方，由他們為我們管理。在本次遷移結束時，我們將只在 Kubernetes 上執行 Pod。我們的基礎設施將變得更加簡單。

所有這些改變都不是免費的；將我們整個基礎設施都交給 Kubernetes 意味著我們需要有 Kubernetes 專家。我們的團隊在基礎設施方面已經擺脫了障礙，他們正忙於透過應用程式開發（這是他們應該做的）來增加業務價值。然而，我們目前還沒有專門的工程師來及時瞭解 Kubernetes 和雲計算的變化。

因此，我們已將一名工程師調到新的“雲平臺團隊”，並將招聘另外幾名工程師（我提到過我們正在招聘嗎！）。他們將負責開發我們可以用來與 Kubernetes 良好互動並管理我們所有云資源的工具。此外，他們還將參與 Kubernetes 原始碼，成為 Kubernetes SIG 的一部分，理想情況下，還會將程式碼推送到開源專案中。

總結

總而言之，雖然遷移到 Kubernetes 最初看起來令人生畏，但它遠沒有我們想象的那麼複雜和具有破壞性。而最終的回報是，公司能夠像客戶期望的那樣快速響應。編者注：在最近的一次 Kubernetes 聚會上，ShareThis 團隊就他們在生產環境中使用 Kubernetes 進行了演講。影片嵌入在下方。

• ←上一篇
• 下一篇→