何時該用無服務器,何時該用 Kubernetes?

何時該用無服務器,何時該用 Kubernetes?

什麼時候該用無服務器,什麼時候該用 Kubernetes 構建雲原生應用程序?

一個好的無服務器應用場景應該是在夜間沒有太多或者完全沒有流量。由於無服務器平臺僅在代碼運行期間收費,因此可以顯著降低成本。較大的應用程序不執行任何操作,無服務器便宜的可能性越大。

但是,這並不意味著無服務器就可以降低成本,如果應用程序全天候運行,可能存在一些隱性成本,比如管理 API 造成的額外成本和測試函數的調用成本。

沒經驗,怎麼選?

就聽而言,無服務器和 Kubernetes 好像已經非常成熟;但就實踐而言,二者還有很多成長空間,研發人員也並未達到人人普及的程度。如果既沒有無服務器也沒有 Kubernetes 經驗,那麼,在無服務器平臺運行 Hello World 應用程序應該更容易。

因為無服務器只需將精力集中在代碼上即可,使用 Kubernetes 則通常需要等待一段時間來創建集群,配置 Kubernetes 以獲取公共 IP 地址,然後再部署容器。使用無服務器平臺,只需使用雲提供商的 Web 工具即可在幾分鐘內上手。

有經驗,怎麼看?

這種難易程度也是變化的,無服務器並不總比 Kubernetes 更容易。使用一堆函數構建和管理無服務器應用程序比只有一個容器的簡單 Kubernetes 應用程序更難。實際上,將 Kubernetes 用於更復雜的應用程序可能更容易,因為該平臺更成熟。

無服務器計算最強大的功能之一是自動可擴展性,開發人員無需採取任何措施就可利用此功能。使用 Kubernetes,研發人員還可使用 pod 甚至節點自動可擴展性,但需要一些配置並且速度稍慢,因為只有在某些規則適用時才會觸發此過程。

但是,Kubernetes 可能提供比某些無服務器平臺更好的可擴展性,因為 Kubernetes 更加成熟,並且在不同區域之間提供 HA(高可用性),這並非所有無服務器平臺都提供。

A/B 測試可能是構建雲原生應用程序的關鍵功能,但無服務器平臺並不具備這一點,Kubernetes 則可以。此外,Kubernetes 應用程序的監控功能更加成熟。例如,使用 Istio 可以看到微服務的執行時間,服務調用情況以及是否存在問題。無服務器平臺因其自身的最大優勢就是不需要操心基礎設施,所以研發人員可做的操作也十分有限。

如果應用程序相當簡單,只有一個函數提供 API,則無服務器可能是更好的選擇,因為部署會更容易,並且各種無服務器平臺都可提供對單個函數的監控。

響應延遲對比

使用無服務器平臺時,由於需要初始化代碼,因此第一次調用函數需要花費一些時間。比如,在 OpenWhisk 中使用 Docker 容器,容器需要時間才能啟動 Java 應用程序。如果需要快速可靠的響應時間,則可以使用 Kubernetes。

通過應用緩存,無服務器平臺對響應時間做了改善。第一次冷啟動後,不必再花費較長響應時間啟動第二次,這可能足以滿足應用需求。

高性能計算對比

無服務器平臺通常具有某些資源限制,比如,功能不能超過 512 MB 的 RAM,不能超過 5 分鐘。如果這些限制對應用程序來說過於嚴格,則需要使用 Kubernetes。有時也會在較小的功能中分解應用程序,比如,將現有單片應用程序移到雲中。

結語

無服務器計算和 Kubernetes 對應不同的應用場景,也有著各自的缺點。如果是初學者,建議從無服務器計算開始,畢竟 Kubernetes 的配置過程相對繁瑣。如果是企業用戶,追求高性能計算、更優性能並希望運行大規模應用程序,Kubernetes 依舊是最佳選擇。

參考鏈接:https://dzone.com/articles/when-to-use-serverless-when-to-use-kubernetes


分享到:


相關文章: