何時應使用 Kubernetes
使用容器協調流程平台 (例如 Kubernetes) 的決策取決於業務和開發需求。 以下是無人機追蹤解決方案高層級架構的回顧。
該解決方案是以微服務的形式建立，其設計為鬆散結合的共同作業服務。 為了簡化解決方案的設計和維護，您將這些服務彼此分開部署。 以下是您解決方案的目前設定。
- Web 前端：顯示地圖及所追蹤無人機的資訊。
- 快取服務：儲存網站上所顯示的經常要求資訊。
- RESTful API：用於受追蹤無人機傳送狀態相關資料，例如 GPS 位置和電池電量。
- 佇列：用於保存 RESTful API 所收集但尚未處理的資料。
- 資料處理服務：用於從佇列擷取資料並加以處理。
- NoSQL 資料庫：儲存擷取自網站和資料處理服務，已經過處理的追蹤資料與使用者資訊。
公司的個別小組開發並擁有這些服務。 每個小組都使用容器來建立和部署其服務。 這個新策略可供開發人員小組隨時掌握現代化軟體開發對自動化、測試及整體穩定性和品質的需求。
開發人員需求的改變為公司帶來數個程序與業務優勢。 例如更有效運用裝載的計算資源、新功能已縮短上市時間，以及提升的客戶覆蓋率。
不過，有數個促使公司調查容器協調流程解決方案的容器管理挑戰。 小組發現將追蹤應用程式擴展至幾個部署相當簡單，但調整和管理許多執行個體則很困難。
此外，還有數個其他層面需要考量。 例如處理失敗的容器、儲存體配置、網路設定及應用程式祕密管理。
如先前所學，Kubernetes 以協調流程平台的形式為所有這些挑戰提供支援。
當公司有下列情況時，建議使用 Kubernetes：
- 將應用程式作為微服務開發。
- 將應用程式作為雲端原生應用程式開發。
- 使用容器來部署微服務。
- 大規模更新容器。
- 需要集中式容器網路功能與儲存體管理。
何時不應使用 Kubernetes
並非所有應用程式都需要在 Kubernetes 中執行。 因此 Kubernetes 不一定適合公司使用。
例如，容器化和部署整合型應用程式的工作的優點可能大於在 Kubernetes 中執行應用程式。 整合型架構無法輕鬆地使用個別元件調整或更新等功能。
Kubernetes 可為軟體開發、部署、管理及程序簡化帶來諸多業務優勢。 不過，Kubernetes 的學習曲線相當陡峭。 Kubernetes 的模組化設計引進了影響您公司各個小組的潛在新概念。
您的開發小組在開發和設計應用程式時，必須採用現代化的設計概念。 這些概念包括使用微服務和容器化這些服務。 小組也必須進行容器和協調流程環境實驗，才能充分利用所有可用的選項。
若公司尚未準備好採用這項變更，Kubernetes 可能就不適合您的公司。