云端Kubernetes并不像看起来那样与供应商无关，以及应如何应对

F5生态系统 | 2020年11月26日

Kubernetes是一个开源平台。因此，您可能会认为它不受特定供应商限制，可以轻松地从一种Kubernetes实现迁移到另一种。

但事实并非如此。实际上，许多Kubernetes解决方案，尤其是与特定公有云绑定的解决方案，并不像您想象的那样不受供应商限制。

好在，即使希望避免供应商锁定，也不意味着无法利用公有云托管Kubernetes。您仍然可以这样做，但必须合理设计Kubernetes策略，既避免受制于特定云提供商的Kubernetes服务，又能充分利用云端Kubernetes的优势。

基于云的Kubernetes方案

如今，所有主流公有云都通过SaaS架构提供托管式Kubernetes服务。Amazon提供Elastic Kubernetes Service，Azure提供Azure Kubernetes Service，Google提供Google Kubernetes Engine，IBM提供IBM Cloud Kubernetes Service。

这些服务将云基础设施与有助于实现Kubernetes部署和管理自动化的软件相结合，因此对于希望快速启动并运行Kubernetes的组织而言，是一种颇具吸引力的解决方案。

云端Kubernetes的供应商锁定风险

这些云Kubernetes服务看似不受特定供应商限制，这也增强了其吸引力。表面上看，从一个Kubernetes SaaS平台迁移到另一个平台似乎相当容易。所有这些平台都基于标准的开源Kubernetes，提供相同的Kubernetes工具（如kubectl），通常也支持相同类型的存储和网络配置。因此，它们看起来基本不受特定供应商限制。

然而，深入了解后就会发现，以托管服务形式提供Kubernetes的公有云并不像表面上那样灵活、通用。它们会以各种方式与所在公有云中运行的其他服务集成，并依赖这些服务。无论使用哪种云，都必须在该云上创建IAM策略来管理Kubernetes集群。身份验证可能需要使用特定于供应商的服务，例如Azure Kubernetes Service可能会使用Azure Active Directory。此外，Kubernetes服务通常会建议使用某些附加工具或替代工具，即使并非强制要求。例如，Google Kubernetes Engine建议使用gke-deploy而非kubectl，而Elastic Kubernetes Service则设计为与Amazon的专有工具eksctl配合使用。

因此，无论使用哪种云来托管Kubernetes，其底层Kubernetes代码可能都相同。尽管从技术上讲，确实可以坚持使用通用工具，但最终最有可能采用的工具和配置并非与供应商无关，而是取决于所使用的具体Kubernetes服务。

如果要从Azure Kubernetes Service迁移到Google Kubernetes Engine，这会形成一大障碍。即使可以直接迁移Kubernetes工作负载，也无法以同样的方式迁移支持这些工作负载的工具链和配置文件。

避免受云端Kubernetes平台锁定

如果希望在部署Kubernetes集群时利用公有云的便利性和可扩展性，同时避免供应商锁定，可以采用两种基本解决方案。

一种方案是使用基于云的虚拟机手动搭建集群，并自行管理。采用这种方法，虽然无法获得云提供商SaaS Kubernetes产品所提供的自动化和集成功能，但仍可使用其基础设施。由于不使用专用工具，将集群从一家云托管服务商迁移到另一家时会更容易，无需重新构建所有内容。当然，这种方案的缺点是，搭建和管理集群需要投入大量人工。

另一种方法更加自动化且更具可扩展性，即使用Volterra的VoltStack®服务来管理集群，无论这些集群位于哪个云中。采用这种策略，实际上是用适用于任何公有云的集中式命令与控制中心，取代各供应商平台中针对特定云的工具，从而可以轻松地在不同公有云之间迁移或复制集群。这样既能获得与Google Kubernetes Engine和Azure Kubernetes Engine等服务相同的可管理性，又不会受制于特定公有云。