挑戰
Crowdfire 協助內容創作者在網際網路上的任何地方創作內容，並以正確的格式發布到其他地方。自 2010 年推出以來，用戶已成長到 1600 萬。該產品最初是一個在 Google App Engine 上運行的單體應用程式，並在 2015 年，公司開始轉型為在 Amazon Web Services Elastic Beanstalk 上運行的微服務。「最初對於我們的用例來說還可以，但隨著服務數量、開發團隊和規模的增加，部署時間、自我修復能力和資源利用率開始成為我們的問題」，Crowdfire 基礎設施團隊負責人軟體工程師 Amanpreet Singh 說道。
解決方案
「我們意識到我們需要更雲原生的方法來處理這些問題」，Singh 說。團隊決定實作基於 Terraform 和 Ansible 的 Kubernetes 自訂設定。
影響
「Kubernetes 幫助我們將部署時間從 15 分鐘縮短到不到一分鐘」，Singh 說。「由於 Kubernetes 的自我修復性質，營運團隊在節點或 Pod 故障時無需進行任何手動干預。」此外，他說，「開發-生產一致性得到了改善，因為開發人員可以在開發/預演集群中試驗各種選項，當最終確定後，他們只需提交各自程式碼儲存庫中的配置變更即可。這些變更會透過 CI/CD 管道自動複製到生產集群。」
對於大多數內容創作者來說，這句電影名言可能只對了一半。當然，像 Wordpress、YouTube 和 Shopify 這樣的平台讓幾乎任何人都可以輕鬆開始在網路上發布新內容，但吸引受眾並不容易。Crowdfire「幫助用戶將他們的內容發布到所有可能的受眾所在的地方」，位於印度孟買的公司軟體工程師 Amanpreet Singh 說。自 2010 年推出以來，Crowdfire 已獲得超過 1600 萬用戶，從部落客和藝術家到創作者和小企業。
憑藉這種成長，以及用戶對新功能和持續改進的高度需求，Crowdfire 團隊在幕後努力跟上。2015 年，他們將單體 Java 應用程式遷移到 Amazon Web Services Elastic Beanstalk，並開始將其分解為微服務。
這是一個良好的開端，但團隊很快意識到他們需要進一步深入雲原生之路，這將引導他們走向 Kubernetes。「最初對於我們的用例來說還可以，但隨著服務和開發團隊數量的增加以及我們進一步擴展，部署時間、自我修復能力和資源利用率開始變得有問題」，Crowdfire 基礎設施團隊負責人 Singh 說。「我們意識到我們需要更雲原生的方法來處理這些問題。」
當他尋找解決方案時，Singh 列出了一份 Crowdfire 需要的清單。「我們希望將一些東西分開，以便它們可以獨立於其他東西發布；這將有助於消除阻礙，讓不同的團隊以自己的步調工作」，他說。「我們也做出許多數據驅動的決策，因此快速發布功能及其迭代是必須的。」
Kubernetes 完全符合所有條件，甚至更多。「最好的事情之一是內建的服務發現」，他說。「當你有一堆需要互相調用的微服務時，擁有現成的內部 DNS 以及自動設定為環境變數的服務 IP 和端口會很有幫助。」此外，他補充說，「Kubernetes 的意見主導方法使其更容易上手。」
採用雲原生方法還有另一個引人注目的商業理由。「在當今瞬息萬變的業務需求世界中，使用雲原生技術提供了多種選擇，甚至可以在混合雲環境中運行服務」，Singh 說。「企業可以將服務保留在離用戶最近的區域，從而受益於高可用性和彈性。」
因此，在 2016 年 2 月，Singh 使用提供的 kube-up 腳本設定了一個測試 Kubernetes 集群。「我探索了這些功能，並且能夠非常輕鬆地部署應用程式」，他說。「然而，它看起來像一個黑盒子，因為我沒有完全理解這些組件，也不知道 kube-up 腳本在底層做了什麼。因此，當它崩潰時，很難找到問題並修復它。」
為了更好地理解，Singh 深入研究了 Kubernetes 的內部結構，閱讀了文件，甚至是一些程式碼。他還向 Kubernetes 社群尋求更多見解。「我過去常常每天晚上熬夜（許多用戶只有在印度這裡是晚上時才活躍），並嘗試回答 Kubernetes 社群 Slack 上剛入門的用戶提出的問題」，他說。「我也會密切關注其他對話。我必須承認，我能夠避免在我們的設定中出現許多問題，因為我知道其他人也遇到過同樣的問題。」
基於他獲得的知識，Singh 決定實作基於 Terraform 和 Ansible 的 Kubernetes 自訂設定。「我編寫了 Terraform 來啟動 Kubernetes master 和節點 (Auto Scaling Groups)，以及一個 Ansible playbook 來安裝所需的組件」，他說。（該公司最近改為使用預先建置的 AMI 以加快節點啟動速度，並計劃更改其網路層。）
首先，團隊將一些預演服務從 Elastic Beanstalk 遷移到新的 Kubernetes 預演集群，然後在一個月後設定了一個生產集群來部署一些服務。結果令人信服。「到 2016 年 3 月底，我們確定所有新服務都必須部署在 Kubernetes 上」，Singh 說。「Kubernetes 幫助我們將部署時間從 15 分鐘縮短到不到一分鐘。由於 Kubernetes 的自我修復性質，營運團隊在節點或 Pod 故障時無需進行任何手動干預。」最重要的是，他說，「開發-生產一致性得到了改善，因為開發人員可以在開發/預演集群中試驗各種選項，當最終確定後，他們只需提交各自程式碼儲存庫中的配置變更即可。這些變更會透過 CI/CD 管道自動複製到生產集群。這使得對所做的變更更具可見性，並保持了稽核追蹤。」
在接下來的六個月裡，團隊致力於將所有服務從 Elastic Beanstalk 遷移到 Kubernetes，除了少數已被棄用且即將終止的服務之外。服務一次移動一個，並監控其性能兩到三天。「今天，我們已經完全遷移，我們在 Kubernetes 上運行所有新服務」，Singh 說。
影響是巨大的：借助 Kubernetes，公司在 Elastic Load Balancer 上節省了 90% 的成本，現在僅用於其公共的、面向用戶的服務。他們的 EC2 營運費用已減少多達 50%。
Crowdfire 的所有 30 位工程師都一次性加入了。「我做了一個內部演講，我在其中分享了基本組件並演示了 kubectl 的用法」，Singh 說。「每個人都對使用 Kubernetes 感到興奮和高興。開發人員現在可以更好地控制和了解他們在生產環境中運行的應用程式。最重要的是，他們對低部署時間和自我修復服務感到滿意。」
他們也變得更有效率。「我們過去每天進行約 5 次部署」，Singh 說，「現在我們幾乎每天進行 30 多次生產部署和 50 多次預演部署。」
Singh 指出，幾乎所有工程師每天都與預演集群互動，這在 Crowdfire 創造了一種文化變革。「開發人員現在更了解雲基礎設施」，他說。「他們已經開始遵循雲端最佳實務，例如更好的健康檢查、stdout [標準輸出] 的結構化日誌以及透過檔案或環境變數進行配置。」
憑藉 Crowdfire 對 Kubernetes 的承諾，Singh 正在尋求擴展公司的雲原生堆疊。團隊已經使用 Prometheus 進行監控，他說他正在評估 Linkerd 和 Envoy Proxy，作為一種「獲得更多關於請求延遲和失敗的指標，並更好地處理它們」的方式。其他 CNCF 專案，包括 OpenTracing 和 gRPC 也都在他的關注範圍內。
Singh 發現雲原生社群在印度也在成長，尤其是在班加羅爾。「許多新創公司和新公司開始在 Kubernetes 上運行其基礎設施」，他說。
當人們詢問 Crowdfire 的經驗時，他提供了以下建議：「Kubernetes 是一項很棒的技術，但它可能不適合你，特別是如果你只有一兩個服務，或者你的應用程式不容易在容器化環境中運行」，他說。「在全力投入之前，評估你的情況以及 Kubernetes 提供的價值。如果你確實決定使用 Kubernetes，請確保你了解在底層運行的組件以及它們在順利運行集群中所起的作用。另一個需要考慮的事情是你的應用程式是否『Kubernetes 就緒』，這意味著它們是否具有適當的健康檢查並處理終止訊號以優雅地關閉。」
如果你的公司符合這種情況，那就去嘗試吧。Crowdfire 顯然做到了，並且現在正在收穫成果。「在我們使用 Kubernetes 的 15 個月裡，它對我們來說非常棒」，Singh 說。「它使我們能夠快速迭代、提高開發速度，並持續向用戶交付新功能和錯誤修復，同時將我們的營運成本和基礎設施管理開銷控制在可控範圍內。」