挑戰
這家企業內容管理公司成立於 2005 年，讓超過 5 千萬名使用者能夠在雲端管理內容。Box 主要以裸機建構，並在公司自己的資料中心內運行，採用單體式 PHP 程式碼庫。隨著公司在全球擴張，Box 需要專注於「我們如何在從裸機到公有雲等眾多不同的雲端基礎架構上執行工作負載」，Box 的共同創辦人暨服務架構師 Sam Ghods 說。「這一直是一項巨大的挑戰，因為不同的雲端，尤其是裸機，具有非常不同的介面。」
解決方案
在過去幾年中，Box 一直將其基礎架構分解為微服務，並成為 Kubernetes 容器 Orchestration 的早期採用者和貢獻者。Ghods 說，Kubernetes 讓 Box 的開發人員能夠「以可在所有雲端之間移植的通用概念集為目標」。
影響
Ghods 說：「在使用 Kubernetes 之前，我們的基礎架構非常老舊，部署新的微服務需要超過六個月的時間。如今，部署新的微服務只需不到五天的時間。而且我們正努力將其縮短到一小時。」
Box 是一個平台，讓超過 5 千萬名使用者（包括政府和大型企業，如 奇異電器）能夠在雲端管理和共享內容，最初是一個 PHP 單體式應用程式，包含數百萬行程式碼，完全以裸機建構在其自己的資料中心內部。它已經開始慢慢削減單體式應用程式，將其分解為微服務。「隨著我們擴展到全球各地區，以及公有雲戰爭日益激烈，我們更加專注於弄清楚我們如何在許多不同的環境和許多不同的雲端基礎架構供應商之間執行工作負載」，Box 共同創辦人暨服務架構師 Sam Ghods 說。「到目前為止，這一直是一項巨大的挑戰，因為所有這些不同的供應商，尤其是裸機，都具有非常不同的介面和與之互動的方式。」
Box 的雲端原生之旅在當年六月加速，當時 Ghods 出席了 DockerCon。公司已經意識到它不能再僅僅在裸機上運行其應用程式，並且正在研究使用 Docker 進行容器化、使用 OpenStack 進行虛擬化以及支援公有雲。
在那次會議上，Google 宣布發布其 Kubernetes 容器管理系統，Ghods 被說服了。「我們研究了許多不同的選項，但 Kubernetes 真的脫穎而出，特別是因為 Borg 資深人員的極其強大的團隊，以及擁有一種完全與基礎架構無關的方式來運行雲端軟體的願景」，他說，他指的是 Google 的內部容器 Orchestration 工具 Borg。「它從一開始就被設計為可以在裸機以及 Google Cloud 上良好運行，這意味著我們實際上可以將其遷移到我們的資料中心內部，然後使用相同的工具和概念在公有雲供應商之間運行。」
另一個優點：Ghods 喜歡 Kubernetes 具有一組通用的 API 物件，如 Pod、Service、Replica Set 和 Deployment Object，這創建了一個一致的介面來建構工具。「即使是建立在 Kubernetes 之上的 PaaS 層，如 OpenShift 或 Deis，仍然將這些物件視為第一原則」，他說。「我們很高興這些抽象概念可以在整個生態系統中共享，這將比我們在其他潛在解決方案中看到的產生更大的動力。」
六個月後，Box 在生產資料中心的一個叢集中部署了 Kubernetes。當時 Kubernetes 仍然是 pre-beta 版本，版本號為 0.11。他們從小規模開始：Ghods 的團隊在 Kubernetes 上運行的第一個東西是一個 Box API 檢查器，用於確認 Box 是否正常運行。「那只是為了編寫和部署一些軟體，以使整個管線正常運作」，他說。接下來是一些處理工作的守護程式，這「很好而且安全，因為如果它們遇到任何中斷，我們也不會讓來自客戶的同步傳入請求失敗。」
幾個月後，第一個可以路由到並請求資訊的線上服務啟動了。Ghods 說，在那個時候，「我們對 Kubernetes 叢集的穩定性感到滿意。我們開始將一些服務移植過來，然後我們會增加叢集大小並移植更多服務，最終在每個資料中心都部署了大約 100 台專門用於 Kubernetes 的伺服器。而且在接下來的 12 個月中，這個數字將會大幅擴張，可能達到數百甚至數千台。」
在觀察開始將 Kubernetes 用於其微服務的團隊時，「我們立即看到發布的微服務數量有所增加」，Ghods 注意到。「顯然，人們對通過微服務建構更好的軟體方式存在壓抑的需求，而敏捷性的提高幫助我們的開發人員提高了生產力，並做出了更好的架構選擇。」
Ghods 回顧說，作為早期採用者，Box 的旅程與現在公司的經歷有所不同。「我們肯定與等待某些東西穩定或功能發布保持同步」，他說。「在早期，我們做了很多貢獻[到 kubectl apply 等組件]，並等待 Kubernetes 發布它們中的每一個，然後我們會升級、貢獻更多，並來回多次。從我們在 Kubernetes 上首次真正部署到全面可用，整個專案大約花了 18 個月的時間。如果我們今天做完全相同的事情，可能不會超過六個月。」
在任何情況下，Box 都不需要對 Kubernetes 進行太多修改才能使其為公司工作。「我們團隊為在 Box 實施 Kubernetes 所做的大部分工作都是使其在我們現有的（通常是舊有的）基礎架構內部工作」，Ghods 說，「例如將我們的基礎作業系統從 RHEL6 升級到 RHEL7，或將其整合到 Nagios，我們的監控基礎架構中。但總體而言，Kubernetes 在適應我們的許多限制方面非常靈活，而且我們已經在我們的裸機基礎架構上非常成功地運行它。」
對於 Box 來說，更大的挑戰也許是文化上的。「Kubernetes 和一般的雲端原生代表著一個相當大的典範轉移，而且它不是非常漸進的」，Ghods 說。「我們基本上是在推銷 Kubernetes 將解決一切問題，因為它以正確的方式做事，而且一切都突然變得更好。但重要的是要記住，它遠沒有許多其他解決方案那麼成熟。你無法說這家或那家公司花了多長時間來完成它，因為還沒有那麼多公司這樣做。我們的團隊不得不真正爭取資源，因為我們的專案有點像登月計畫。」
從經驗中學習，Ghods 為面臨類似挑戰的公司提供了以下兩條建議
服務發現是 Box 的一個巨大問題，團隊不得不決定是建立一個臨時解決方案，還是等待 Kubernetes 原生滿足 Box 的獨特需求。經過多次討論，「我們只是開始專注於交付一些可行的東西，然後再處理可能遷移到更原生解決方案的問題」，Ghods 說。「團隊的首要目標應該始終是在基礎架構上服務真正的生產用例，無論多麼微不足道。這有助於保持團隊本身和組織對專案的認知的動力。」
早期，團隊在 Docker 檔案之上建立了一個抽象層，以幫助確保映像具有正確的安全更新。但事實證明這是多餘的工作，因為容器映像被認為是不可變的，你可以輕鬆地在建構後掃描它們，以確保它們不包含漏洞。由於通過容器化管理基礎架構是一個如此不連續的飛躍，因此最好從直接與原生工具互動並學習它們的獨特優勢和注意事項開始。只有在實際需要出現後才應建立抽象層。
最終，影響是巨大的。「在使用 Kubernetes 之前」，Ghods 說，「我們的基礎架構非常老舊，部署新的微服務需要超過六個月的時間。現在部署新的微服務只需不到五天的時間。而且我們正努力將其縮短到一小時。誠然，這六個月的大部分時間是由於我們的系統有多麼糟糕造成的，但除非你有像 Kubernetes 這樣的系統來幫助管理它，否則裸機本質上是一個難以支援的平台。」
根據 Ghods 的估計，Box 距離他成為 90% 以上 Kubernetes 商店的目標還有幾年的路要走。「我們在擁有一個任務關鍵型、穩定的 Kubernetes 部署方面取得了很大進展，這提供了很大的價值」，他說。「目前，我們所有運算中約有 5% 在 Kubernetes 上運行，我認為在接下來的六個月裡，這個比例可能會在 20% 到 50% 之間。我們正在努力啟用所有無狀態服務用例，然後將重點轉移到有狀態服務上。」
事實上，這就是他對整個產業的願景：Ghods 預測 Kubernetes 有機會成為新的雲端平台。Kubernetes 提供了一個跨不同雲端平台（包括裸機）的一致 API，「我不認為人們已經看到了當你可以針對單一介面進行程式設計時，可能實現的全部潛力」，他說。「正如 AWS 改變了基礎架構，讓你不再需要考慮伺服器或機櫃或網路設備一樣，Kubernetes 使你能夠專注於你正在運行的容器，這非常令人興奮。這就是願景。」
Ghods 指出，Kubernetes 作為雲端平台的專案已經在開發或最近發布：叢集聯邦、儀表板 UI 和 CoreOS 的 etcd 運算子。「我真的相信這是我在雲端基礎架構中看到的最令人興奮的事情」，他說，「因為它以前所未有的自動化和智慧程度圍繞著基礎架構，這種基礎架構是可移植的，並且與您運行基礎架構的每種方式都無關。」
Box 憑藉其早期決定使用裸機，出於必要踏上了 Kubernetes 之旅。但 Ghods 說，即使公司今天不必對雲端供應商保持不可知論，隨著越來越多的工具和擴展圍繞 API 構建，Kubernetes 可能很快就會成為行業標準。
「正如偏離 Linux 沒有意義，因為它是一個如此標準」，Ghods 說，「我認為 Kubernetes 正在走同樣的道路。現在仍然是早期階段——文件仍然需要改進，並且用於編寫和發布規格到 Kubernetes 叢集的使用者體驗仍然很粗糙。當你處於前沿時，你可以預期會付出一些代價。但底線是，這就是產業的發展方向。三到五年後，如果你以任何其他方式運行你的基礎架構，那真的會令人震驚。」