挑戰
2016 年，Booking.com 遷移到了 OpenShift 平臺，這使產品開發人員能夠更快地訪問基礎設施。但由於 Kubernetes 對開發人員進行了抽象，當出現問題時，基礎設施團隊成了“知識瓶頸”。試圖擴充套件這種支援是不可持續的。
解決方案
在運營 OpenShift 一年後，平臺團隊決定構建自己的原生 Kubernetes 平臺，並要求開發人員學習一些 Kubernetes 知識才能使用它。“這不是一個神奇的平臺，”B 平臺技術負責人 Ben Tyler 說。“我們並不聲稱你可以閉著眼睛就使用它。開發人員需要進行一些學習，而我們將盡一切努力確保他們能夠獲得這些知識。”
影響
儘管有學習曲線，但新的 Kubernetes 平臺的採用率還是大幅上升。在容器化之前，如果開發人員懂 Puppet，建立一個新服務可能需要幾天時間，如果不懂，則需要數週。在新平臺上，最快只需要 10 分鐘。在最初的 8 個月裡，平臺上就構建了大約 500 個新服務。
該技術所提供的功能給團隊留下了深刻印象，但鑑於其規模——該網站平均每天處理超過 150 萬個房間夜的預訂——需要企業級功能，團隊決定採用 OpenShift 平臺。
這個平臺被包裝在一個 Heroku 風格的高階 CLI 介面中，“在我們的產品開發人員中確實很受歡迎，”B 平臺技術負責人 Ben Tyler 說。“我們讓他們能更快地訪問基礎設施。”
但他補充說，“每當出現一點小問題，開發人員沒有任何知識來自己解決。”
在運營這個平臺一年後，基礎設施團隊發現自己成了“知識瓶頸”，他說。“大多數使用它的開發人員都不知道底層是 Kubernetes。應用程式的故障和平臺的故障看起來都像是那個 Heroku 風格工具的故障。”
擴充套件所需的支援似乎既不可行也不可持續，因此平臺團隊需要一個新的解決方案。他們在運營 OpenShift 平臺時獲得的對 Kubernetes 的理解，給了他們信心去構建一個自己的原生 Kubernetes 平臺，並根據公司的需求進行定製。
“對於進入這個領域來說，OpenShift 確實非常有幫助，”B 平臺高階系統管理員 Eduard Iacoboaia 說。“它向你展示了這項技術能做什麼，並讓你很容易上手。在花了一些時間之後，我們意識到需要更好地學習 Kubernetes，才能充分發揮其潛力。那時，我們轉向構建自己的 Kubernetes 平臺。從長遠來看，我們肯定會因為邁出這一步並投入時間來獲取這些知識而受益。”
Iacoboaia 的團隊為了讓 OpenShift 的工具在 Booking.com 執行，定製了很多內容，而“那些整合點有點脆弱，”他說。“我們花了更多的時間來理解 Kubernetes 的所有元件，它們如何工作，以及它們如何相互作用。” 這項研究促使團隊從 OpenShift 內建的 Ansible playbooks 轉向了 Puppet 部署，因為 Booking 的其餘基礎設施都使用 Puppet。控制平面也從叢集內部移到了裸機上，因為公司執行著數萬臺裸機伺服器和一套龐大的在裸機上執行應用程式的基礎設施。（Booking 在其擁有計算資源的各個地區的多個數據中心中的多個叢集中執行 Kubernetes。）“我們決定讓它儘可能簡單，並使用我們最熟悉的工具，” Iacoboaia 說。
另一個重大變化是，產品工程師必須學習 Kubernetes 才能上手。“這不是一個神奇的平臺，”Tyler 說。“我們並不聲稱你可以閉著眼睛就使用它。開發人員需要進行一些學習，而我們將盡一切努力確保他們能夠獲得這些知識。” 這包括培訓、部落格文章、影片和 Udemy 課程。
儘管有學習曲線，但新的 Kubernetes 平臺的採用率還是大幅上升。“我認為我們能夠成功達成這個協議的原因是，我們沒有要求他們學習一個專有的應用系統，” Tyler 說。“我們要求他們學習的是開源的東西，這些知識是可轉移的。他們透過學習 Kubernetes 來投資自己的職業生涯。”
這一策略成功的明顯標誌是，在支援渠道中，當用戶提出問題時，其他產品工程師會主動參與進來回答。“我以前從未在公司內部看到過圍繞某個平臺產品有如此高的社群參與度，” Tyler 說。“這非常有幫助，因為它在公司外部顯然是一個生態系統標準，所以人們覺得投資於這些知識並與他人分享是有價值的，這真的、真的非常強大。”
還有其他可量化的證據：在容器化之前，如果開發人員懂 Puppet，建立一個新服務可能需要幾天時間，如果不懂，則需要數週。在新平臺上，只需要 10 分鐘。“我們有一個教程。你跟著教程走，你的程式碼就開始運行了。然後，就是專注於業務邏輯的時候了，” Tyler 說。“獲取資源的時間被大大縮短了。” 在最初的 8 個月裡，平臺上就構建了大約 500 個新服務，每天有數百次釋出。
該平臺提供了不同“層次的契約，可以這麼說，” Tyler 說。“在最底層，它就是 Kubernetes。如果你是 Kubernetes 專業使用者，這裡有一個 Kubernetes API，就像你從 GKE 或 AKS 獲得的一樣。我們努力成為同一級別的提供商。但我們在公司內部的全部工作是提供比原生基礎設施更大的附加值，所以我們為我們的主要技術棧 Perl 和 Java 提供了一套基礎映象。”
並且“隨著我們的使用者學習 Kubernetes 併成為更成熟的 Kubernetes 使用者，他們會給我們施加壓力，要求我們提供更好、更原生的 Kubernetes 體驗，這很棒，” Tyler 說。“這是一種非常健康的動態。”
該平臺還包括其他 CNCF 技術，如 Envoy、Helm 和 Prometheus。Booking.com 的大部分關鍵服務流量都透過 Envoy 進行路由，而 Prometheus 主要用於監控基礎設施元件。Helm 被用作打包標準。該團隊還開發並開源了 Shipper，這是 Kubernetes 的一個擴充套件，用於新增更復雜的釋出策略和多叢集編排。
可以肯定的是，關於從頭開始構建 Kubernetes 平臺的明智性，內部曾有過討論。“這並不是我們的核心競爭力——Kubernetes 和旅遊，它們相差甚遠，對吧？” Tyler 說。“但我們在 CNCF 元件上做了幾筆賭注，結果對我們來說非常成功。特別是 Envoy 和 Kubernetes，對我們的組織非常有益。我們能夠對它們進行定製，要麼是因為我們可以檢視原始碼，要麼是因為它們有擴充套件點，我們能夠很快從中獲得價值，而無需改變任何內部的正規化。”