挑戰
2016 年，Booking.com 遷移至 OpenShift 平台，使產品開發人員能更快存取基礎架構。但由於 Kubernetes 對開發人員隱藏，當挑戰出現時，基礎架構團隊成為了「知識瓶頸」。試圖擴展這種支援方式並不可持續。
解決方案
在運作 OpenShift 一年後，平台團隊決定構建自己的原生（vanilla）Kubernetes 平台，並要求開發人員學習一些 Kubernetes 知識以便使用。「這不是一個魔法平台，」B Platform Track 的首席開發人員 Ben Tyler 說。「我們不是聲稱你可以閉著眼睛就能使用它。開發人員需要進行一些學習，我們會盡一切努力確保他們能夠獲得這些知識。」
成果
儘管有學習曲線，但新 Kubernetes 平台的採用率仍大幅提升。在容器出現之前，如果開發人員了解 Puppet，建立一項新服務可能需要幾天時間，如果不懂則需要數週。在新的平台上，最快只需 10 分鐘即可完成。在該平台運行的前 8 個月內，已經建立了約 500 項新服務。
由於對該技術提供的功能印象深刻，但同時需要滿足其規模的企業級特性——該網站平均每天處理超過 150 萬個客房夜間預訂——團隊決定採用 OpenShift 平台。
B Platform Track 首席開發人員 Ben Tyler 表示，該平台被封裝在類似 Heroku 的高階 CLI 介面中，「確實受到我們產品開發人員的歡迎。我們讓他們能更快存取基礎架構。」
但他補充道，「每當出現一點問題時，開發人員都沒有任何必要的知識來進行自我支援。」
他說，在運作該平台一年後，基礎架構團隊發現它已經成為「一個知識瓶頸」。 「大多數使用它的開發人員並不知道底層是 Kubernetes。應用程式故障和平台故障看起來都像是那個 Heroku 風格工具的故障。」
擴展必要的支援似乎不可行也不具永續性，因此平台團隊需要一個新的解決方案。他們在運作 OpenShift 平台時獲得的 Kubernetes 知識，讓他們有信心構建屬於自己的原生 Kubernetes 平台，並根據公司需求進行客製化。
「對於入門來說，OpenShift 確實非常有幫助，」B Platform Track 資深系統管理員 Eduard Iacoboaia 說。「它向你展示了該技術的功能，並讓你易於使用。在我們花了一些時間使用它之後，我們意識到為了充分發揮其潛力，我們需要更好地學習 Kubernetes。在那時，我們轉向構建自己的 Kubernetes 平台。我們從長遠來看，絕對受益於採取這一步驟並投入時間來獲取知識。」
Iacoboaia 的團隊客製化了許多 OpenShift 工具以使其在 Booking.com 上運作，他說「這些整合點相當脆弱」。 「我們花了更多時間了解 Kubernetes 的所有元件、它們如何運作、以及它們如何相互作用。」這項研究促使團隊從 OpenShift 內建的 Ansible Playbook 切換到 Puppet 部署，後者用於 Booking 其餘的基礎架構。控制平面（Control Plane）也從叢集內部移到了裸機上，因為該公司運作著數以萬計的裸機伺服器，並擁有用於在裸機上執行應用程式的大型基礎架構。（Booking 在其擁有運算資源的各個區域的多個資料中心的多個叢集中執行 Kubernetes。）「我們決定保持盡可能簡單，並使用我們最熟悉的工具，」Iacoboaia 說。
另一個重大改變是，產品工程師必須學習 Kubernetes 才能進行入職（onboard）。「這不是一個魔法平台，」Tyler 說。「我們不是聲稱你可以閉著眼睛就能使用它。開發人員需要進行一些學習，我們會盡一切努力確保他們能夠獲得這些知識。」這包括培訓、部落格文章、影片和 Udemy 課程。
儘管有學習曲線，但新 Kubernetes 平台的採用率仍大幅提升。「我認為我們能夠成功達成這種共識的原因是，我們沒有要求他們學習專有的應用程式系統，」Tyler 說。「我們要求他們學習的是開源的技術，知識是可以轉移的。他們透過學習 Kubernetes 正在為自己的職業生涯進行投資。」
這項策略取得成功的一個明確跡象是，在支援頻道中，當使用者有問題時，其他產品工程師會主動跳出來回答。「在此之前，我從未見過內部針對特定平台產品有這種社群參與度，」Tyler 說。「它在公司外部顯然是生態系統標準，這非常有幫助，因此人們覺得投資於這些知識並與他人分享具有價值，這真的很強大。」
還有其他可量化的證據：在容器出現之前，如果開發人員了解 Puppet，建立一項新服務可能需要幾天時間，如果不懂則需要數週。在新的平台上，只需要 10 分鐘。「我們有一個教學指南。你按照指南操作。你的程式碼就在運作了。接下來，就是發揮業務邏輯的時間了，」Tyler 說。「存取資源的時間大幅縮短了。」在該平台運行的前 8 個月內，已經建立了約 500 項新服務，每天發布數百次。
該平台提供不同「合約層級，可以這麼說，」Tyler 說。「最基礎的，它就是 Kubernetes。如果你是一名 Kubernetes 專業使用者，這裡有 Kubernetes API，就像你從 GKE 或 AKS 獲得的一樣。我們試圖成為同一層級的供應商。但我們在公司內部的全部職責是提供比單純的原生基礎架構更大的附加價值，因此我們為我們的主要技術堆疊（Perl 和 Java）提供了一組基礎映像檔。」
而且，「隨著我們的使用者學習 Kubernetes 並成為更成熟的使用者，他們會對我們施加壓力，要求提供更好、更原生的 Kubernetes 體驗，這非常好，」Tyler 說。「這是一種超級健康的動態關係。」
該平台還包括其他 CNCF 技術，例如 Envoy、Helm 和 Prometheus。Booking.com 的大部分關鍵服務流量都透過 Envoy 路由，而 Prometheus 主要用於監控基礎架構元件。Helm 被視為包裝標準使用。團隊還開發並開源了 Shipper，這是 Kubernetes 的一個擴充功能，用於增加更複雜的發布策略和多叢集編排。
當然，內部曾討論過從頭構建 Kubernetes 平台的智慧性。「這確實不是我們的核心競爭力——Kubernetes 和旅遊業，它們有點遙遠，對吧？」Tyler 說。「但我們對 CNCF 元件進行了幾次投注，效果非常好。特別是 Envoy 和 Kubernetes，對我們的組織非常有益。我們能夠客製化它們，要麼是因為我們可以查看原始碼，要麼是因為它們有擴充點，我們能夠非常快速地從中獲取價值，而無需在內部改變任何範式。」