小心“移植税”：Kubernetes 不能使应用程序具有可移植性

本文经作者授权，由 InfoQ 翻译并发布。

Gartner 分析师 Marco Meinardi、Richard Watson 和 Alan Waite 表示，不能主要为了应用程序的可移植性而采用 Kubernetes，因为虽然 K8s 从理论上提高了可移植性，但在实践中它使应用依赖于特定平台，同时有可能让应用无法使用云平台的最佳特性。

他们最近在“专业技术建议”文件中提出了这一理论，并且在 2020 年 9 月 4 日的一篇博文中总结了这个理论。

我们阅读了完整的文件，其中心思想是：想要采用 Kubernetes 的话，你还得选择合适的 Kubernetes 管理工具供应商才行。

“使用 Kubernetes 时，你只是将一种依赖形式换成了另外一种。”他们写道，“通过使用 Kubernetes 来减少对特定供应商的依赖是很吸引人的，但 K8s 的抽象层使其演变为另一种形式的依赖。你现在依赖于抽象层，而不是底层基础环境。”

这很重要，因为“尽管抽象层对于可移植性可能很有用，但底层云服务商常常掩盖或扭曲这些抽象层，使其并不具有完全相同的功能。总的来说，公有云服务所提供的抽象层会带来成本和服务不一致的问题，所以当你的组织将产品迅速上市和迅速产生收益作为首要目标时，采用云服务商提供的这些抽象层并不是什么好选项。”

他们还担心为了实现可移植性，用户可能无法使用云平台的最佳特性。

“使 Kubernetes 应用具备可移植性需要避免一切对基础设施提供商的依赖，例如云服务商提供的原生服务。而我们开始使用该云平台的原因通常就是因为这些服务所提供的功能。”他们写道。

然后，他们三人指出不同云服务商运行 Kubernetes 的基础设施特性不同，这也使移植变得不太容易。

“计算实例用到的云服务提供者的特定功能越多，实现可移植性的可能性就越低。”分析师们写道，“例如，在 AWS Fargate 上使用 EKS 未经 CNCF 认证，甚至可以说它不是标准的 Kubernetes。由容器实例（ACI）实现的 Azure 虚拟节点也是如此。”

该文件也指出，采用 Kubernetes 几乎肯定意味着要采用第三方的存储和网络组件，这也意味着移植应用程序必须同时复制这些额外的组件，因此这也使应用程序更加依赖于特定平台。

使用云服务商在基础设施堆栈中预置的软件可以减少一些麻烦，例如可以选择 Google Anthos，Azure Stack 或 AWS Outposts。

但总体而言，该文件表明你别无选择，只能“依赖于特定平台，尽可能减轻这种依赖并接受它。”

而且，应该是在三位分析师评估的应用移植概率“极低”的情况下做这个选择。

“由于可移植性的挑战，大多数应用程序不会在云服务提供商之间迁移，但是大多数应用程序也不需要这种可移植性。“数据引力”使应用程序往往更靠近数据的存储位置。迁移数据通常是困难且昂贵的。出于类似的原因，为了利用最便宜的基础设施而频繁移动应用程序的情况尚未出现。”

因此，该建议表明为移植性而建立应用可能会引入“移植税”。

“如果你采用 Kubernetes 仅仅是为了实现应用的可移植性，那么你会在尝试解决一个问题的同时，引入了三个本来没有的新问题。”

但是如果你不管上述问题，仍然选择使用 Kubernetes 并且重视可移植性，他们三人推荐使用另外一层基础设施。

“进一步抽象是避免依赖于特定 Kubernetes 消费模型和供应商的合理方法。这种方法建议使用 Kubernetes 管理器的管理器，例如 D2iQ Kommander，Giant Swarm，Google Anthos，Platform9，Rancher，VMware Tanzu Mission control 或者类似的管理器。”

但是，一旦你使用了这样的平台，就会出现另一个你无法避免的问题。

分析师写道：“这类联合产品的目的是联合多个 Kubernetes 集群供应和管理，跨越多种基础架构和 Kubernetes 消费模型。但是，这就会冒着对该联合产品产生新的依赖性的风险，而这种新的依赖比对主要云服务商或软件供应商的依赖还要糟糕。”

原文链接：

https://www.theregister.com/2020/09/08/kubernetes_app_portability_problems