挑戰
成立於 2012 年，Nav 為小型企業主提供來自三大商業信用機構（Equifax、Experian 和 Dun & Bradstreet）的企業信用評分，以及最符合其需求的融資方案。成立五年後，這家新創公司快速成長，「我們的雲端環境變得非常龐大，而我們對這些環境的使用率卻極低，不到 1%，」工程總監 Travis Jeppson 說。「我們希望我們對雲端環境的使用率能更緊密地與我們實際需要的相符，因此我們開始研究容器化和協調，以幫助我們能夠運行彼此獨立但可以共享類似資源池的工作負載。」
解決方案
在評估了許多協調解決方案後，Nav 團隊決定採用在 AWS 上運行的 Kubernetes。Kubernetes 社群的強大力量以及其 Google 血統都非常吸引人。此外，「其他解決方案往往相當笨重、非常複雜、非常龐大，而且一開始就很難管理，」Jeppson 說。「Kubernetes 為我們提供了一個非常簡單的方法來踏入一個協調解決方案，這個方案在當時符合我們的需求，而且其可擴展性也讓我們能夠與之共同成長，並在以後建構更多功能。」
影響
這個四人團隊在六個月內啟動並運行了 Kubernetes，並在另外六個月內完成了 Nav 的 25 個微服務的完整遷移。結果令人印象深刻：資源利用率（這最初引導公司走上這條道路）已從 1% 提高到 40%。啟動一項新服務過去需要兩位開發人員花費兩週時間；現在只需一位開發人員不到 10 分鐘即可完成。部署次數增加了 5 倍。而且公司在基礎架構成本方面節省了 50%。
幾年前，Nav 意識到自身成功之路上的障礙。業務快速成長，「我們的雲端環境變得非常龐大，而我們對這些環境的使用率卻極低，不到 1%，」Jeppson 說。「大部分問題都圍繞著擴展能力。我們只是在砸錢。『讓我們啟動更多伺服器。讓我們做更多事情來處理增加的負載。』而對於我們這樣的新創公司來說，這可能會導致我們的失敗。我們沒有錢可以浪費在這種事情上。」
此外，每項新服務都必須經過 10 個不同的人員，需要長達兩週的不可接受的時間才能啟動。「所有的修補程式管理和伺服器管理都是手動完成的，所以我們都必須密切關注並維護它，」Jeppson 補充說。「這只是一個非常麻煩的系統。」
Jeppson 在他之前的工作中使用過容器，並向 Nav 的管理層推銷這項技術作為解決這些問題的方案。他在 2017 年初獲得了批准。「我們希望我們對雲端環境的使用率能更緊密地與我們實際需要的相符，因此我們開始研究容器化和協調，以幫助我們能夠運行彼此獨立但可以共享類似資源池的工作負載，」他說。
在評估了許多協調解決方案後，公司決定採用在 AWS 上運行的 Kubernetes。Kubernetes 社群的強大力量及其 Google 起源都非常吸引人。此外，「其他解決方案往往相當笨重、非常複雜、非常龐大，而且一開始就很難管理，」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 在來年的下一步：研究追蹤、儲存和服務網格。他們目前正在評估 Envoy、OpenTracing 和 Jaeger，此前他們在 KubeCon 上花費了大量時間與其他公司交談。「社群絕對至關重要：能夠交流想法、討論我們都面臨的許多類似挑戰，並獲得幫助。我喜歡我們能夠因為不同的原因而解決相同的問題，但卻能一路互相幫助，」Jeppson 說。「在可擴展性方面，在能夠真正完全採用雲端原生解決方案方面，還有很多很多事情要做。」
當然，這一切都始於 Kubernetes。憑藉這項技術，Jeppson 的團隊建立了一個允許 Nav 擴展的平台，並且「透過允許所有這些我們以前從未擁有的新自由，為 Nav 帶來了巨大的價值，」他說。
過去關於新產品的對話常常因為他們必須等待六個月才能建立具有隔離的環境，然後弄清楚如何處理流量高峰而陷入僵局。「但現在這對我們來說根本不算什麼，」Jeppson 說。「我們現在處理的流量是現在的四到十倍，而且感覺就像，『喔，耶。我們很好。Kubernetes 為我們處理了這個問題。』」