笔者：Kubernetes 形象了资源和工作负载的操作模式，对立了工具集，实现人机接口的标准化。正如类 Docker 工具提供了利用运行时的操作模式；Spring Framework 提供了 Java 利用的开发模式。
Kubernetes 是对于跨云的技能、工具和实际的可移植性。不是工作负载的可移植性。— Bilgin Lbryam @bibryam
本文翻译自 Kubernetes magic is in enterprise standardization, not app portability
Kubernetes 不会神奇地使你的应用程序具备可移植性，但它可能会给你带来更好的货色。
云为企业提供了看似有限的抉择。然而，依据 Canonical-sponsored 的一项考察，这并不是大多数企业采纳 Kubernetes 等云敌对技术的起因。相同，Kubernetes 的次要指标是标准化——外观和操作与其他人一样。
可移植性不是指标
我之前曾经探讨过这个问题，参考了 Gartner 对于 Kubernetes 和可移植性的指南。许多人认为 Kubernetes（和容器）能够让他们在云之间轻松移植，但事实证明并不是这样的。正如 Gartner 分析师 Marco Meinardi 所写，当被问及公司是否应该采纳“Kubernetes 使他们的应用程序可移植 …… 答案是：不。”再说一次？
考察显示，[在云提供商之间挪动应用程序] 的可能性实际上非常低。一旦部署在供应商中，应用程序往往会留在那里。这是因为数据湖难以移植且老本昂扬，因而最终成为迁徙的重心。
因而 Kubernetes 通常不会被公司承受，以加强应用程序的可移植性；相同，议论人员可移植性或换言之，技能可移植性更靠近事实。Weaveworks 首席执行官亚历克西斯·理查森（Alexis Richardson）将这个主题打回家：
重点是“技能可移植性”，因为应用规范操作模型和工具链。大型组织心愿开发人员应用规范的工作形式，因为这能够升高培训老本，并打消员工在不同我的项目之间转移的阻碍。如果你的“平台”（或多个平台）基于雷同的外围云原生工具集，那么它也能够更轻松、更便宜地利用策略。
这让咱们回到标准考察。
Samesies
当被问及确定与采纳 Kubernetes 等云原生技术相干的技术指标时，考察受访者将可移植性排在最初，将更间接的问题排在第一位：
- 改良保护、监控和自动化 – 64.6%。
- 基础设施现代化 – 46.4%。
- 更快的上线工夫 – 26.5%。
- 删除供应商依赖项 – 12.8%。
- 寰球覆盖率 – 12.5%。
- 围绕流量顶峰的敏捷性 – 9.2%。
- 确保便携性 – 8.9%
我喜爱 Google Cloud 的开发者倡导者 Kelsey Hightower 在调查报告中评论这些后果的形式：
很多人认为组织转向 Kubernetes 是因为规模，或者因为他们想成为超大规模者，或者与 Twitter 领有雷同的流量程度。对于大多数组织而言，状况并非肯定如此。很多人都喜爱 K8s 中内置了许多决策，例如日志记录、监控和负载平衡。
人们往往会遗记事件有如许简单，只是为了构建一个没有所有自动化的应用程序。如果你在私有云上，你能够应用一些本机集成和工具。然而，如果你在本地，那不是给定的——你必须本人将解决方案粘合在一起。应用 Kubernetes，你简直将 25 种不同的工具合二为一。
这就是人们所说的“古代基础设施”的意思——他们并不是在议论做一些以前从未做过的事件。他们议论的是过来 10 年或 15 年始终在生产的货色。Kubernetes 是当今所有“古代模式”的检查站。
换句话说，人们真正想要从 Kubernetes 取得的是一种规范的基础设施思考形式。回到 Richardson 之前的观点，尽管 Kubernetes 和云原生技术使公司可能以更高的速度经营，但最大的益处可能是使技能在组织之间能够调换——这为雇主和员工都发明了微小的绩效收益。这是企业一直减少对 Kubernetes 投资的另一个起因。
申明：我为 AWS 工作，但此处表白的观点是我的。
文章对立公布在公众号
云原生指北