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