挑戰
「在 2014 年從單體式架構轉向微服務 '解決了開發端的問題，但將問題推給了基礎架構團隊'」Squarespace 網站可靠性團隊的 Staff Engineer Kevin Lynch 說道。「我們在 5,000 台 VM 主機上的基礎架構部署流程拖慢了所有人的速度。」
解決方案
團隊嘗試了容器編排平台，發現 Kubernetes 「解答了我們所有的疑問」，Lynch 說道。公司於 2016 年開始在其資料中心運行 Kubernetes。
影響
自從 Squarespace 轉移到 Kubernetes，並結合其網路堆疊的現代化改造，部署時間已減少了近 85%。以前，他們的 VM 部署需要半小時；現在，Lynch 說，「有人可以產生一個範本化的應用程式，在五分鐘內部署它，並在那個時間點讓實際的容器化實例在我們的預演環境中運行。」他補充說，正因如此，「生產力時間是最大的成本節省來源。」「當我們開始 Kubernetes 專案時，我們可能只有十幾個微服務。今天，正在積極開發的管道中已經有兩倍的數量。」Kubernetes 也提高了韌性：「如果節點故障，它會立即重新排程，並且不會對效能造成影響。」
然而，在幕後，公司的單體式 Java 應用程式讓開發人員在持續改進平台方面變得不那麼容易。因此在 2014 年，公司決定「走上微服務之路」，Squarespace 網站可靠性團隊的 Staff Engineer Kevin Lynch 說道。「但我們一直以來都是在 vCenter VMware VM [在我們自己的資料中心] 中部署我們的應用程式。微服務解決了開發端的問題，但將問題推給了基礎架構團隊。我們在 5,000 台 VM 主機上的基礎架構部署流程拖慢了所有人的速度。」
Lynch 說，在嘗試了另一個容器編排平台並「以非常痛苦的方式將其弄壞」之後，團隊於 2016 年年中開始嘗試 Kubernetes，並發現它「解答了我們所有的疑問」。在資料中心而不是公有雲中部署它是他們最大的挑戰，而且當時沒有很多其他公司這樣做。「我們必須弄清楚如何在我們自己的基礎架構中部署它，而且我們必須將它與我們的其他應用程式整合」，Lynch 說道。
同時，Squarespace 的網路工程團隊正在將其網路堆疊現代化，從傳統的第二層網路切換到第三層 spine-and-leaf 網路。「它與我們想要用 Kubernetes 做的事情完美契合」，Lynch 說道。「它讓我們能夠讓我們的伺服器直接與機架頂端交換器通訊。我們使用 Calico 作為 Kubernetes 的 CNI 網路，因此我們可以宣告所有這些個別的 Kubernetes pod IP 位址，並讓它們與我們仍在 VM 中佈建的其他服務無縫整合。」
在幾個月內，他們就有了一個用於內部用途的穩定叢集，並開始為生產環境推出 Kubernetes。他們還將 Zipkin 和 CNCF 專案 Prometheus 和 fluentd 新增到他們的雲原生堆疊中。「我們切換到 Kubernetes，一個全新的世界，我們也徹底改造了我們所有的其他工具」，Lynch 說道。「它讓我們能夠簡化我們的流程，因此我們現在可以輕鬆地從範本建立整個微服務專案，為其產生程式碼和部署管道，產生 Dockerfile，然後立即將可運作、可部署的專案交付到 Kubernetes。」Lynch 補充說，跨 Dev/QA/Stage/Prod 的部署也「大幅簡化了」。 「現在配置差異很小。」
而且整個過程僅需五分鐘，與他們的 VM 部署相比，時間縮短了近 85%。 「從頭到尾可能需要半小時，而且這還沒有考慮到基礎架構工程師將負責執行此操作的事實，因此其中也存在一些業務延遲。」
Lynch 說，隨著部署速度加快，「生產力時間是最大的成本節省來源。」「我們有一個團隊正在實作一個新的檔案儲存服務，他們在沒有我們參與的情況下就開始將其與我們的儲存後端整合」——這在 Kubernetes 之前是不可能實現的。他補充說：「當我們開始 Kubernetes 專案時，我們可能只有十幾個微服務。今天，正在積極開發的管道中已經有兩倍的數量。」
應用程式的韌性也得到了正面影響。「當我們部署 VM 時，我們必須建立工具來確保服務適當地分散在機架上，並且能夠承受故障」，他說。「Kubernetes 就做到了。如果節點故障，它會立即重新排程，並且不會對效能造成影響。」
另一個巨大的好處是自動擴展。「以我們使用 VMware 的方式，這實際上是不可能的」，Lynch 說，「但現在我們可以透過 Kubernetes 直接添加適當的自動擴展功能，然後，隨著需求的增加，它就會擴展。而且它是開箱即用的。」
對於其他剛開始使用 Kubernetes 的人，Lynch 說他最好的建議是「快速失敗」：「一旦你規劃好事情，就直接執行。Kubernetes 非常適合快速嘗試某些東西，看看它是否有效。」
Lynch 和他的團隊計劃開源他們開發的一些工具，以擴展 Kubernetes 並將其用作 API 本身。第一個工具將相依應用程式作為容器注入到 pod 中。他解釋說，「當你交付一個應用程式時，通常它會帶有一堆需要與之一起交付的相依應用程式，例如，用於日誌記錄的 fluentd。」有了這個工具，開發人員就不需要擔心配置。
展望未來，Squarespace 的所有新服務都將進入 Kubernetes，最終目標是轉換所有可以轉換的服務。大約四分之一的現有服務已經遷移。「我們的單體式應用程式將是最後一個，只是因為它太龐大和複雜了」，Lynch 說道。「但現在我看到其他服務被遷移過來，例如檔案儲存服務。有人只是做了，而且它成功了——毫不費力。所以我相信如果我們著手解決它，它可能會比我們擔心的要容易得多。也許我應該聽從自己的建議，快速失敗！」