ShareThis：生產環境中的 Kubernetes

自 ShareThis 最初作為一個小型 Widget，讓您分享到您最喜愛的社群服務以來，ShareThis 取得了巨大的成長。現在，它每月為超過 450 萬個網域提供服務，協助發布商創造更真實的數位體驗。

快速成長是有代價的。我們利用技術債來快速擴展和發展我們的產品，尤其是在基礎架構方面。隨著公司的擴張，基礎架構成本也隨之增加 - 無論是在效率低下的利用率方面還是在人力成本方面。大約 1 年前，我們清楚地意識到需要做出改變。

簡而言之；Kubernetes 一直是我們減少基礎架構中技術債的關鍵組件，透過以下方式：

• 促進 Docker 的採用
• 簡化容器管理
• 讓開發人員熟悉基礎架構
• 解鎖持續整合和交付。我們透過徹底採用 Kubernetes，並將我們的 DevOps 團隊轉變為以容器和微服務為基礎的雲端平台團隊來實現這一點。這包括建立一些工具來解決我們自己的遺留債務。

問題

唉，雲端是新的，我們也很年輕。我們從傳統的資料中心思維模式開始。 我們管理我們自己的所有服務：MySQL、Cassandra、Aerospike、Memcache 等等。 我們像設置傳統伺服器一樣設置 VM，在它們上面安裝我們的應用程式，並在 Nagios 或 Ganglia 中管理它們。

不幸的是，這種思維方式與以雲端為中心的方法背道而馳。我們沒有以服務的角度思考，而是以伺服器的角度思考。我們沒有使用現代雲端方法，例如自動擴展、微服務，甚至是託管 VM，而是以腳本化設定、伺服器部署和避免供應商鎖定的角度思考。

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

解決方案

Kubernetes 作為促進 Docker 採用的工具

隨著 Docker 在我們的行業中變得越來越重要，ShareThis 的工程師也開始嘗試使用它，效果很好。很快就變得顯而易見，我們需要為公司中的每個應用程式都準備一個可運作的容器，以便簡化我們開發環境中的測試。

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

在 2015 年末，我們對我們的舊有基礎架構感到非常沮喪，以至於我們最終下定決心。我們評估了 Docker 的工具、ECS、Kubernetes 和 Mesosphere。很快就顯而易見，對於我們的基礎架構而言，Kubernetes 比其競爭對手更穩定且更使用者友善。作為一家公司，我們可以透過簡單地設定將我們所有基礎架構都放在 Kubernetes 上的目標，來鞏固我們在 Docker 上的基礎架構。

工程師起初持懷疑態度。然而，一旦他們看到應用程式毫不費力地擴展到每個應用程式數百個實例，他們就被迷住了。現在，不僅有痛點推動我們前進到 Docker 以及延伸的 Kubernetes，而且還有對技術的真正興奮感吸引著我們。這使我們能夠相當快速地完成一項非常困難的遷移。我們現在在多個區域的約 65 台大型 VM 上運行 Kubernetes，並且在接下來的幾個月內將增加到 100 多台。我們的 Kubernetes 叢集目前每天處理 8 億個請求，並計劃在未來幾個月內每天處理超過 20 億個請求。

Kubernetes 作為管理容器的工具

我們最早使用 Docker 在開發方面很有希望，但在生產方面卻不太理想。最大的摩擦點是無法大規模管理 Docker 組件。知道哪些容器在哪裡運行、正在運行哪個版本的部署、應用程式處於什麼狀態、如何管理子網路和 VPC 等等，都阻礙了它進入生產環境的可能性。所需的工具將是巨大的。

當您查看 Kubernetes 時，有幾個關鍵功能立即引起了人們的注意：

• 它很容易在 AWS 上安裝（我們所有的應用程式都在這裡運行）
• 從 Dockerfile 到複製控制器，有一條直接的路徑，透過 yaml/json 檔案
• Pod 能夠輕鬆地擴展數量
• 我們可以輕鬆地在 Kubernetes 叢集中擴展 AWS 上運行的 VM 數量
• 滾動部署和回滾都內建在工具中
• 每個 Pod 都透過健康檢查進行監控
• 服務端點由工具管理
• 有一個活躍且充滿活力的社群

不幸的是，最大的痛點之一是，該工具並未解決我們現有的舊有基礎架構，它只是提供了一個可以遷移到的基礎架構。仍然存在各種網路怪癖，這些怪癖不允許我們將應用程式直接遷移到新的 VPC 上。 此外，重新設計如此多的應用程式需要開發人員投入到傳統上由系統管理員和營運團隊解決的問題中。

Kubernetes 作為讓開發人員熟悉基礎架構的工具

當我們決定從基本上是 Chef 運行的設定切換到 Kubernetes 時，我不認為我們理解我們會遇到的所有痛點。 我們以各種不同的方式在各種不同的網路配置中運行我們的伺服器，這些網路配置與您在新的 Kubernetes VPC 上找到的乾淨設定有很大不同。 

在生產環境中，我們在跨多個區域的 AWS VPC 和 AWS classic 中運行。這意味著我們管理著多個子網路，這些子網路在不同的應用程式之間具有不同的訪問控制。我們最新的應用程式也非常安全，沒有公共端點。這意味著我們結合使用了 VPC 對等互連、網路位址轉換 (NAT) 和以各種配置運行的代理伺服器。

在 Kubernetes 世界中，只有 VPC。 所有 Pod 理論上都可以互相交談，並且明確定義了服務端點。開發人員很容易忽略一些細節，並且（主要）消除了對營運的需求。 

我們決定將我們所有的基礎架構/DevOps 開發人員轉變為應用程式開發人員（真的！）。無論如何，我們已經開始根據他們的開發技能而不是他們的營運技能來聘請他們，所以也許這聽起來並沒有那麼瘋狂。

然後，我們決定讓我們整個工程組織熟悉營運。開發人員很靈活，他們喜歡挑戰，他們喜歡學習。這真是太了不起了。 1 個月後，我們的組織從只有少數 DevOps 人員，變成了每個工程師都具備修改我們架構的能力。

熟悉網路、生產化、問題解決、根本原因分析等的訓練場，是以大規模將 Kubernetes 投入生產環境。在第一個月之後，我感到非常緊張，並擔心我們的選擇。2 個月後，看起來有一天可能會可行。3 個月後，我們每週部署 10 次。4 個月後，每週部署 40 個應用程式。只有 30% 的應用程式已遷移，但收穫不僅顯著，而且令人驚嘆。Kubernetes 讓我們從一個「基礎架構拖慢我們速度 - 唉！」的組織，轉變為一個「基礎架構加速我們速度 - 耶！」的組織。

Kubernetes 作為解鎖持續整合和交付的手段

我們是如何達到每週 40 多個部署的？簡而言之，持續整合和部署 (CI/CD) 是我們遷移的副產品。我們在 Kubernetes 中的第一個應用程式是 Jenkins，並且每個進入的應用程式也都添加到 Jenkins 中。隨著我們向前發展，我們使 Jenkins 更加自動化，直到 Pod 的新增和從 Kubernetes 中移除的速度比我們追蹤的速度還快。 

有趣的是，我們在擴展方面遇到的問題現在是關於想要一次推出太多變更，以及人們必須等到輪到他們。我們的目標是透過新的基礎架構，每週獲得 100 個部署。如果我們能夠繼續執行我們的遷移，並繼續致力於 Kubernetes 和 Jenkins 上的 CI/CD 流程，那麼這是可以實現的。

下一步

我們需要完成我們的遷移。在這一點上，問題基本上都已解決，最大的困難在於手頭任務的繁瑣。將東西從我們的舊有基礎架構中移出意味著更改網路配置，以允許訪問 Kubernetes VPC 以及跨區域的網路配置。這仍然是一個非常真實的痛點，也是我們繼續解決的問題。 

有些服務在 Kubernetes 中運行不佳 - 想想有狀態的分散式資料庫。幸運的是，我們通常可以將這些服務遷移到將為我們管理它們的第三方。在此遷移結束時，我們將僅在 Kubernetes 上運行 Pod。我們的基礎架構將變得更加簡單。

所有這些變更都不是免費的；將我們整個基礎架構提交給 Kubernetes 意味著我們需要擁有 Kubernetes 專家。 我們的團隊在基礎架構方面已經暢通無阻，他們正忙於透過應用程式開發來增加業務價值（正如他們應該做的那樣）。但是，我們（尚未）有專門的工程師來隨時了解 Kubernetes 和雲端運算的變化。 

因此，我們已將一位工程師調到一個新的「雲端平台團隊」，並將再聘請幾位（我是否提到我們正在招聘！）。他們將負責開發我們可以使用的工具，以便與 Kubernetes 良好地介接並管理我們所有的雲端資源。此外，他們將在 Kubernetes 原始碼中工作，成為 Kubernetes SIG 的一部分，理想情況下，將程式碼推送到開源專案中。

總結

總而言之，雖然最初遷移到 Kubernetes 看起來令人望而生畏，但它遠沒有我們想像的那麼複雜和具有破壞性。而另一端的回報是一家能夠以客戶想要的速度做出回應的公司。編者註：在最近的一次 Kubernetes 線下聚會中，ShareThis 團隊就他們在生產環境中使用 Kubernetes 發表了演講。影片嵌入在下方。

• ←上一篇
下一篇→