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

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

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

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

1. 規(guī)劃部署。

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

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

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

2. 確定多云目標。

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

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

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

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

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

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

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

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

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

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