【51CTO.com快譯】公共云提供商的托管Kubernetes服務提供彈性且高度可用的Kubernetes控制平面部署。這種服務與各自云提供商的原生功能以及本地Kubernetes部署集成起來。然而，這種服務并不總是與其他云提供商的產品集成，至少集成起來不是很容易或很順暢。

如果你決定采用一家云提供商，并將所有編排流程與該提供商的平臺上的部署關聯起來，***使用托管Kubernetes服務，比如Amazon Elastic Container Service for Kubernetes(EKS)、Azure Kubernetes服務(AKS)和谷歌Kubernetes引擎(GKE)。你的應用程序在此規則方面帶來的例外情況越多，單個托管Kubernetes服務適合你的可能性就越小。

決定與多家云提供商合作的企業要料到，跨多云部署環境集成容器編排任務會變得很難。

想評估托管Kubernetes服務的優缺點，請遵循這三步。

1. 規劃部署。

任何容器編排策略的***步是規劃托管空間，也就是列出用來托管應用程序的整套資源。這可能包括本地數據中心和多家公共云提供商。針對每個應用程序，確定其部署范圍，包括你將在哪里托管其組件。這一步可大致表明你的Kubernetes部署將如何不同。

適合托管Kubernetes服務的企業會有編排圖，顯示了兩個重要的方面：首先，它們只計劃使用一家云提供商，如果另換提供商，準備好重新制定運營策略。其次，組件托管在云和數據中心的任何應用程序幾乎不執行故障切換或突發操作。

另一方面，不適合托管Kubernetes服務的企業是這類組織：計劃使用多家公共云提供商，并在它們之間迅速移動應用程序。此外，如果公司計劃使用所有托管資源(包括本地數據中心)作為應用程序組件可以利用的龐大資源池，不適合這種托管服務。

2. 確定多云目標。

大多數公司介于這兩個極端之間。如果是這種情況，下一步是定義多云策略。確定你是有靜態多云模式(即將應用程序組件放入固定的云提供程序托管組)，還是動態多云模式(即組件可在不同云提供商的平臺之間自由移動)。

對于使用靜態模式的企業來說，在每個公共云中使用托管Kubernetes服務很可能非常合情合理，但前提是云提供商將Kubernetes與像Istio這些可分配工作并管理分布式流程的工具緊密集成。在這種情況下，使用每家云提供商的工具可能會提升容器托管能力。

然而，使用動態多云模式的企業很可能無法得益于云提供商的托管Kubernetes服務。相反，它們需要一種能夠自由跨越云邊界的總體編排方法。這類企業應考慮部署自己的Kubernetes編排平臺，使用與云無關的工具。

3. 選擇你想要如何投入。

云托管的托管Kubernetes服務無法與其他云提供商的原生功能集成。這意味著，如果你致力于多云模式的這些服務，在大多數情況下，還要致力于另外編排每個公共云。

如果你選擇Kubernetes的軟件發行版，比如Red Hat OpenShift，就得在每個云域中部署應用程序和Kubernetes。你還要管理Kubernetes元素及其控制平面連接的可用性。

面向Kubernetes的一個常見的多云框架是Stackpoint.io，除了本地環境外，它還支持三大公共云提供商：AWS、Azure和谷歌。借助Stackpoint.io，企業可以創建一個通用的多云Kubernetes控制平面，從而可以統一部署。有許多商業供應商提供Kubernetes和Stackpoint.io版本，并附帶支持，包括DigitalOcean、Red Hat和VMware。

***，考慮一下你的云提供商對容器和Kubernetes的承諾。谷歌已表明了對兩者都大力支持，但谷歌云最近的領導層更迭可能預示著方向有變。至于微軟，它似乎幾乎和谷歌一樣堅定，但AWS在改進其自己的容器托管和編排服務方面起步緩慢，其新的Firecracker微虛擬機產品可能表明會更關注虛擬機。

原文標題：Weigh the pros and cons of managed Kubernetes services，作者：Tom Nolle

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】