挑戰
Nav 成立於 2012 年，為小企業主提供查閱來自三大主要商業信用機構（Equifax、Experian 和 Dun & Bradstreet）的商業信用評分，以及最適合他們需求的融資選擇。公司成立五年後，這家初創公司迅速發展，“我們的雲環境變得非常龐大，但這些環境的使用率卻極低，大約低於 1%，”工程總監 Travis Jeppson 說道。“我們希望我們的雲環境使用率能更緊密地與我們的實際需求掛鉤，因此我們開始研究容器化和編排，以幫助我們執行彼此獨立但可以共享相似資源池的工作負載。”
解決方案
在評估了眾多編排解決方案後，Nav 團隊決定採用執行在 AWS 上的 Kubernetes。Kubernetes 強大的社群以及其源自谷歌的背景是強大的吸引力。此外，“其他解決方案往往過於笨重、複雜、龐大，並且一開始就很難管理，”Jeppson 說道。“Kubernetes 為我們提供了一種非常簡單的方式，可以逐步採用當時適合我們需求的編排解決方案，而且它的可擴充套件性也使我們能夠隨之成長，並在以後構建更多特性和功能。”
影響
這個由四人組成的團隊在六個月內讓 Kubernetes 執行起來，並在接下來的六個月內完成了 Nav 的 25 個微服務的全面遷移。結果令人印象深刻：資源利用率（正是最初促使公司走上這條道路的原因）從 1% 增加到 40%。過去，啟動一項新服務需要兩名開發人員兩週時間；現在，只需一名開發人員不到 10 分鐘。部署次數增加了 5 倍。公司在基礎設施成本上節省了 50%。
幾年前，Nav 發現自身成功之路上存在一個障礙。公司業務增長迅速，“我們的雲環境變得非常龐大，但這些環境的使用率卻極低，大約低於 1%，”Jeppson 說道。“大部分問題都圍繞著擴充套件能力。我們只是在燒錢。‘讓我們啟動更多伺服器。讓我們做更多事情來應對增加的負載。’而對於我們這樣一個初創公司來說，這可能會導致我們的滅亡。我們沒有錢來燒在那種事情上。”
此外，每項新服務都必須經過 10 個不同的人，啟動時間長達兩週，這讓人無法接受。“所有的補丁管理和伺服器管理都是非常手動化的，所以我們都必須很好地監控和維護它，”Jeppson 補充道。“這簡直是一個非常麻煩的系統。”
Jeppson 在他之前的工作中接觸過容器，並將這項技術推薦給 Nav 的管理層，作為解決這些問題的方案。他在 2017 年初獲得了批准。“我們希望我們的雲環境使用率能更緊密地與我們實際所需掛鉤，因此我們開始研究容器化和編排，以幫助我們執行彼此獨立但可以共享相似資源池的工作負載，”他說。
在評估了眾多編排解決方案後，公司決定採用執行在 AWS 上的 Kubernetes。Kubernetes 強大的社群以及其源自谷歌的背景是強大的吸引力。此外，“其他解決方案往往過於笨重、複雜、龐大，並且一開始就很難管理，”Jeppson 說道。“Kubernetes 為我們提供了一種非常簡單的方式，可以逐步採用當時適合我們需求的編排解決方案，而且它的可擴充套件性也使我們能夠隨之成長，並在以後構建更多特性和功能。”
Jeppson 的四人工程服務團隊在六個月內讓 Kubernetes 執行起來（他們決定使用 Kubespray 來啟動叢集），並在接下來的六個月內完成了 Nav 的 25 個微服務和一個主要整體的全面遷移。“我們無法重寫所有內容；我們不能停下來，”他說。“我們必須保持執行，保持可用性，並且停機時間要最短。所以我們非常熟悉我們的構建流水線、我們的指標和日誌，以及 Kubernetes 本身：如何啟動它、如何升級它、如何維護它。我們一點一點地遷移。”
這個過程的關鍵部分包括對 Nav 的 50 名工程師進行培訓，並就新的工作流程以及遷移路線圖保持透明。Jeppson 在此期間定期進行演示，併為所有工程師舉辦了為期一週、每天四小時的實驗課。然後，他在 GitLab 中建立了一個儲存庫來存放所有資訊。“我們向所有前端和後端開發人員展示瞭如何使用 kubectl 自行建立自己的名稱空間，”他說。“現在，很多時候，他們只是來找我們說，‘這已經準備好了。’我們在 GitLab 中點選一個小按鈕，允許它釋出到生產環境，然後他們就可以開始工作了。”
自 2018 年初完成遷移以來，成果令人印象深刻：資源利用率（正是最初促使公司走上這條道路的原因）從 1% 增加到 40%。過去，啟動一項新服務需要兩名開發人員兩週時間；現在，只需一名開發人員不到 10 分鐘。部署次數增加了 5 倍，從每天 10 次增加到每天 50 次。公司在計算方面的基礎設施成本節省了 50%。Jeppson 表示：“接下來我們希望解決資料庫方面的問題，一旦完成，我們將繼續大幅降低成本。”
Kubernetes 還幫助 Nav 滿足了其合規性需求。Jeppson 說，以前，“我們必須將一個應用程式對映到一個伺服器，這主要是由於圍繞資料的不同合規性法規。有了 Kubernetes API，我們可以新增網路策略並隔離資料，並在需要時對其進行限制。”公司將其叢集劃分為非受限區和受限區，受限區有自己的一組節點，用於資料保護。公司還使用 Twistlock 工具來確保安全，“這讓我們晚上睡得更安穩，”他補充道。
在 Kubernetes 部署到位後，Nav 團隊還透過採用 Prometheus 開始改進系統的指標和日誌記錄。“Prometheus 為指標建立了一個標準，開發人員很容易採納，”Jeppson 說。“他們可以自由地顯示他們想要的東西，做他們需要做的事情，並保持他們的程式碼庫乾淨，這對於我們來說是絕對必須的。”
Nav 在未來一年接下來的計劃是：研究追蹤、儲存和服務網格。在 KubeCon 上與其他公司進行大量交流後，他們目前正在評估 Envoy、OpenTracing 和 Jaeger。Jeppson 說：“社群絕對至關重要：能夠交流想法，討論我們都面臨的許多類似挑戰，並獲得幫助。我喜歡我們能夠出於不同的原因解決相同的問題，但在此過程中互相幫助。”“圍繞可擴充套件性，以及真正完全採用雲原生解決方案，還有很多很多工作要做。”
當然，這一切都始於 Kubernetes。有了這項技術，Jeppson 的團隊建立了一個允許 Nav 擴充套件的平臺，他表示：“這為 Nav 帶來了巨大的價值，賦予了我們前所未有的新自由。”
過去，關於新產品的討論常常因為需要等待六個月才能建立一個隔離環境，然後才能解決流量高峰問題而陷入僵局。Jeppson 說：“但現在對我們來說這根本不算什麼。”“我們現在處理的流量是以前的四到十倍，但我們只是覺得，‘哦，是的。我們很好。Kubernetes 為我們處理這一切。’”