挑戰
全球最大的資產管理公司貝萊德 (BlackRock)採用一種高度受控的靜態部署方案，多年來實現了可擴充套件性。但在其資料科學部門，需要更動態地訪問資源。“我們希望能夠讓每位投資者都能接觸到資料科學，這意味著Python Notebook，甚至更高階的東西，比如基於Spark的 MapReduce 引擎，”貝萊德產品集團的董事總經理 Michael Francis 說，該集團負責公司的投資管理平臺。“在使用者桌面管理複雜的 Python 安裝確實很困難，因為每個人最終都會有略微不同的環境。我們有現有的環境可以做這些事情，但我們需要讓它變得真實、廣闊和可擴充套件。能夠按需啟動、拆除，使其更具動態性，成為我們關鍵的思考過程。與其說是我們必須解決主要的生產核心問題，不如說是我們如何擴充套件它？我們如何發展？”
解決方案
借鑑去年使用Docker環境進行的試點所學到的經驗，Francis 組建了一個由 20 人組成的多部門團隊，使用Kubernetes構建了一個投資者研究網路應用程式，目標是在一個季度內將其投入生產。
影響
“我們的目標是：如何快速為人們提供工具，而無需在他們的桌面上安裝它們？” Francis 說。該團隊在 100 天內實現了目標。Francis 對結果很滿意，並表示：“隨著時間的推移，我們將把這個基礎設施用於許多其他應用程式工作負載。這不僅僅是資料科學；是這種需要動態性的應用程式風格。但我認為我們離做出（大規模）決策還有 6-12 個月。我們需要獲得在生產中執行該系統的經驗，我們需要了解故障模式以及如何最好地管理操作問題。有趣的是，僅僅擁有這項技術正在改變我們的開發人員開始思考未來開發的方式。”
貝萊德產品集團員工在 2017 年的管理目標之一是“構建酷炫的東西”。由董事總經理 Michael Francis 領導的一個由 20 人組成的多部門團隊做到了這一點：他們推出了一個完整的生產 Kubernetes 環境，併發布了一個新的投資者研究網路應用程式。在 100 天內。
對於一家全球最大的資產管理公司來說，“僅僅裝置採購有時就需要 100 天，更不用說從構思到交付了，”高階系統管理員 Karl Wieman 說。“這是一個激進的時間表。但它推動了變革。”事實上，該專案實現了兩個目標：它解決了一個業務問題（建立所需的網路應用程式），並提供了 Kubernetes 的實際生產經驗，Kubernetes 是該公司渴望探索的雲原生技術。“與其說是我們必須解決主要的生產核心問題，不如說是我們如何擴充套件它？我們如何發展？” Francis 說。除了交付應用程式之外，該專案的最終成功在於“我們設法將一種全新的思維過程整合到我們不想改變的受控基礎設施中。”
畢竟，在貝萊德存在的三十年裡，它“擁有一個非常完善的計算資源管理環境，” Francis 說。“我們在機器上管理大型叢集程序，因此我們以一種非常‘雲’化的概念對主要生產程序進行大量編排和管理。我們能夠以一種高度受控的靜態部署方案進行管理，這為我們帶來了巨大的可擴充套件性。”
儘管這對於核心生產執行良好，但該公司發現某些資料科學工作負載需要更動態地訪問資源。“這是一個非常爆發式的過程，” Francis 說，他是該公司 Aladdin 投資管理平臺部門的資料主管。
Aladdin 即時連線了資金管理所需的人員、資訊和技術，在內部使用，也作為平臺出售給其他資產管理公司和保險公司。“我們希望能夠讓每位投資者都能接觸到資料科學，這意味著Python Notebook，甚至更高階的東西，比如基於Spark的 MapReduce 引擎，” Francis 說。但是“在使用者桌面管理複雜的 Python 安裝確實很困難，因為每個人最終都會有略微不同的環境。Docker 讓我們能夠扁平化那個環境。”
儘管如此，挑戰依然存在。“如果你有一個共享叢集，就會出現‘群集風暴’問題，每個人都想在同一時間做同樣的事情，” Francis 說。“你可以對其施加限制，但你必須建立一個基礎設施來定義我們程序的限制，而 Python Notebook 並不是為此而設計的。我們有現有的環境可以做這些事情，但我們需要讓它變得真實、廣闊和可擴充套件。能夠按需啟動、拆除，使其更具動態性，成為我們關鍵的思考過程。”
Francis 的團隊由技術、基礎設施、生產運營、開發和資訊安全部門的經理組成，他們能夠全面審視問題，併為貝萊德提出一個合理的解決方案。“我們最初的草案是，我們將使用Ansible構建一切，並使用一些完全不同的分散式環境來執行所有內容，” Francis 說。“那將是絕對錯誤的做法。如果我們作為開發團隊獨自開發這個解決方案，它會是一個非常不同的產品。而且會非常昂貴。我們不會選擇在我們現有的編排系統下執行。因為我們不瞭解它。這些（運營和基礎設施）人員瞭解它。擁有多學科團隊使我們能夠找到正確的解決方案，這實際上意味著我們沒有構建我們原以為會構建的那麼多。”
為了尋找一種能夠按使用者級別管理使用情況的解決方案，Francis 的團隊傾向於 Red Hat 的OpenShift Kubernetes 產品。該公司已經嘗試過其他雲原生環境，但團隊喜歡 Kubernetes 是開源的，而且“我們覺得長期來看，風向正吹向 Kubernetes，” Francis 說。“通常，我們選擇的都是我們相信在未來 5-10 年內仍將以某種形式存在的技術。而目前，在這個領域，Kubernetes 感覺就是那個將會存在的技術。”生產運營副總裁 Uri Morris 補充道：“當你看到非谷歌的 Kubernetes 提交者數量超過谷歌提交者時，這就是其發展勢頭的指標。”
一旦做出決定，主要的挑戰就是弄清楚如何讓 Kubernetes 在貝萊德現有的框架內工作。“關鍵在於瞭解我們如何操作、管理和支援這樣一個平臺，以及將其附加到我們現有的技術平臺，”專案經理 Michael Maskallis 說。“我們所有現有的控制措施、變更管理流程、軟體開發生命週期、我們經歷的入職流程——我們如何完成所有這些事情？”
第一個（預期）障礙是解決貝萊德公司防火牆後面的問題。“我們面臨的挑戰之一是，大多數開源軟體中都沒有防火牆，” Francis 說。“因此，幾乎所有安裝指令碼都會以某種奇怪的方式失敗，並且下載包不一定能成功。”團隊在使用Minikube時遇到了這些型別的問題，並對開源專案進行了一些小的貢獻。
還有一些關於服務發現的問題。“你可以將 Aladdin 視為一個服務雲，服務之間有 API，這使我們能夠快速構建應用程式，” Francis 說。“所有這些都建立在專有訊息總線上，這給我們帶來了各種優勢，但同時，這如何在第三方[平臺]中發揮作用呢？”
他們需要解決的另一個問題是，在貝萊德現有的系統中，訊息協議在不同的開發、測試和生產環境中具有不同的例項。雖然 Kubernetes 實現了更具 DevOps 風格的模型，但這對於貝萊德來說並不合適。“我認為我們非常自豪的是，我們能夠在這個（新）基礎設施中實現令人難以置信的快速生產部署，但我們擁有了控制點，而且我們不必顛覆一切，” Francis 說。“這次開發的大部分成本都在於思考如何最好地利用我們的內部工具。因此，它的成本比我們實際想象的要低。”
例如，該專案利用了與訊息匯流排相關的工具。“Kubernetes 叢集與我們內部訊息平臺通訊的方式是透過一個閘道器程式，這個閘道器程式已經內建了檢查和節流功能，” Morris 說。“我們可以使用它們來控制和潛在地節流來自 Kubernetes 極具彈性的基礎設施到生產基礎設施的請求。我們將繼續朝這個方向發展。它使我們能夠從運營角度按需擴充套件。”
該解決方案還必須與貝萊德的集中運營支援團隊結構互補。“Kubernetes 的核心基礎設施元件與我們現有的編排框架連線在一起，這意味著我們支援團隊中的任何人都能夠使用現有運營工具對叢集進行控制和可見性，” Morris 解釋道。“這意味著我不需要僱傭更多人。”
確定這些要點後，團隊為專案建立了一個程式：“我們首先將其推廣到開發環境，然後轉移到測試環境，最後按順序轉移到兩個生產環境，”Maskallis 說。“這大大促進了我們的學習曲線。我們有所有這些移動部件，基礎設施側的軟體元件，直接與 Kubernetes 相關的軟體元件，以及與我們在貝萊德運營的其餘環境的互聯互通，以及我們如何連線所有這些部件。如果我們遇到問題，我們就會修復它們，然後轉移到不同的環境中進行復制，直到我們最終進入生產環境，這個特定的叢集應該在那裡執行。”
團隊每週舉行一次一小時的工作會議，所有成員（遍佈全球）都參與其中，並舉行了更小規模的分組或深度會議，重點討論特定的技術細節。可能的解決方案會報告給小組並在下週進行辯論。“我認為之所以成為一個成功的實驗，是因為人們必須努力學習，並且他們與他人分享了經驗，”副總裁兼軟體開發人員 Fouad Semaan 說。然後，Francis 說，“我們給工程師提供了發揮他們所長的空間。這不是自上而下的。”
他們遵循一個關鍵原則：保持專注，避免範圍蔓延。這意味著他們不會使用 Kubernetes 和 Docker 核心中不存在的功能。但如果確實需要，他們會自己構建這些功能。幸運的是，Francis 說：“由於開發速度很快，很多我們原以為必須自己構建的東西都已整合到核心產品中。[包管理器Helm就是一個例子]。大家都有類似的問題。”
在100天結束時，該應用程式已為貝萊德的內部使用者上線並執行。最初的30個使用者容量在幾小時內就達到了，並迅速增加到150個。“人們立刻就投入使用了，”弗朗西斯說。在該專案的下一階段，他們計劃擴充套件叢集以增加容量。
更重要的是，他們現在擁有了在生產環境中運用 Kubernetes 的經驗，可以繼續在此基礎上進行建設——以及一套完整的推廣新應用程式的框架。“隨著時間的推移，我們將把這個基礎設施用於許多其他應用程式工作負載。這不僅僅是資料科學；這是這種需要動態性的應用程式風格，”Francis 說。“這是我們核心生產流程的正確遷移方向嗎？有可能。我們還沒到可以說‘是’或‘否’的地步，但我們認為，以某種形式和規模擁有 Kubernetes 這樣的實際生產經驗將有助於我們理解這一點。我認為我們離做出（大規模）決策還有 6-12 個月。我們需要獲得在生產中執行該系統的經驗，我們需要了解故障模式以及如何最好地管理操作問題。”
對於考慮類似專案的其他大型公司，Francis 表示承諾和奉獻是關鍵：“我們從第一天起就得到了（高階管理層）的批准，並承諾能夠找到合適的人。如果我必須說明像這樣複雜的事情成功的關鍵因素，我會說能夠實際推動它的資深實踐者會帶來巨大的不同。”在此基礎上，他補充道，“我想對我們這樣的其他企業說，你們實際上可以將 Kubernetes 整合到現有、精心編排的機制中。你們不必拋棄所做的一切。而且，使用 Kubernetes 使一個複雜的問題變得顯著更容易。”