挑戰
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 主節點和工作節點（自動擴縮組），並編寫了一個 Ansible playbook 來安裝所需的元件，”他說。（該公司最近已切換到使用預烘焙的 AMI 來加快節點啟動速度，並計劃更改其網路層。）
首先，團隊將一些預演服務從 Elastic Beanstalk 遷移到新的 Kubernetes 預演叢集，然後在一個月後設置了生產叢集以部署一些服務。結果令人信服。Singh 說：“到 2016 年 3 月底，我們確定所有新服務都必須部署在 Kubernetes 上。”“Kubernetes 幫助我們將部署時間從 15 分鐘縮短到不到一分鐘。由於 Kubernetes 的自愈特性，在節點或 Pod 故障的情況下，運維團隊無需進行任何手動干預。”最重要的是，他說，“開發-生產環境的一致性得到了改善，因為開發人員可以在開發/預演叢集中試驗選項，一旦確定，他們只需在相應的程式碼倉庫中提交配置更改。這些更改將透過 CI/CD 流水線自動複製到生產叢集中。這提高了對所做更改的可見性，並保留了審計跟蹤。”
在接下來的六個月裡，團隊致力於將所有服務從 Elastic Beanstalk 遷移到 Kubernetes，除了少數已被棄用並將很快終止的服務。服務一次遷移一個，每個服務的效能都監測了兩到三天。今天，“我們已經完全遷移，並在 Kubernetes 上執行所有新服務，”Singh 說。
影響是巨大的：透過 Kubernetes，該公司在 Elastic Load Balancer 上節省了 90% 的成本，現在僅用於其公共、面向使用者的服務。其 EC2 運營費用已減少多達 50%。
Crowdfire 的所有 30 名工程師都同時入職。“我做了一次內部演講，分享了基本元件並演示了 kubectl 的用法，”Singh 說。“每個人都對使用 Kubernetes 感到興奮和高興。開發人員現在對在生產環境中執行的應用程式擁有更多的控制權和可見性。最重要的是，他們對低部署時間和自愈服務感到滿意。”
他們的生產力也大大提高了。Singh 說：“我們過去每天大約部署 5 次，現在我們幾乎每天進行 30 多次生產部署和 50 多次預演部署。”
Singh 指出，幾乎所有工程師每天都與預演叢集進行互動，這在 Crowdfire 創造了一種文化變革。“開發人員現在對雲基礎設施更加了解了，”他說。“他們已經開始遵循雲最佳實踐，例如更好的健康檢查、結構化日誌到 stdout [標準輸出] 以及透過檔案或環境變數進行配置。”
鑑於 Crowdfire 對 Kubernetes 的承諾，Singh 正在尋求擴充套件公司的雲原生堆疊。團隊已經使用 Prometheus 進行監控，他說他正在評估 Linkerd 和 Envoy Proxy，作為“獲取更多關於請求延遲和故障的指標，並更好地處理它們”的方式。其他 CNCF 專案，包括 OpenTracing 和 gRPC 也在他的考慮範圍之內。
Singh 發現，雲原生社群在印度，特別是在班加羅爾也在不斷發展。“許多初創公司和新公司都開始在 Kubernetes 上執行其基礎設施，”他說。
當人們問他 Crowdfire 的經驗時，他提供了以下建議：“Kubernetes 是一項偉大的技術，但它可能不適合你，特別是如果你只有一兩個服務或者你的應用程式不容易在容器化環境中執行，”他說。“在全力投入之前，評估你的情況以及 Kubernetes 提供的價值。如果你確實決定使用 Kubernetes，請確保你瞭解底層執行的元件以及它們在順利執行叢集中的作用。另一個需要考慮的問題是你的應用程式是否‘Kubernetes-ready’，這意味著它們是否有適當的健康檢查並處理終止訊號以優雅地關閉。”
如果你的公司符合這個要求，那就去做吧。Crowdfire 顯然做到了——現在正在收穫益處。Singh 說：“在我們使用 Kubernetes 的 15 個月裡，它對我們來說是驚人的。它使我們能夠快速迭代，提高開發速度，並不斷為使用者提供新功能和錯誤修復，同時將我們的運營成本和基礎設施管理開銷控制在可控範圍內。”