超越“迁移”的思考：应用程序该如何被Kubernetes接管？

传统虚拟机（VM）的可扩展性差强人意，但Kubernetes可以快速，无缝地扩展正在运行的服务。

Kubernetes将容器、集群以及广泛的抽象配置方法引入桌面，用于提升部署和变更管理体验，从而使人们对Kubernetes关注更多。

示例： “简单”三层应用程序

“一致性逻辑抽象”是什么意思？也许一个例子会有所帮助。让我们看一个简单的三层应用程序，如下图1所示。

图1：一个简单的三层应用程序（逻辑视图）

像上述那种逻辑视图有意隐藏了许多技术细节。在这种情况下，我们认为使用网络是理所当然的，即使它在表示层和应用程序层之间包含一个负载平衡器，也可以将流量定向到在单独的VM上运行的应用程序实例中。

三层应用程序在云中运行，也面临一些基本限制。如扩展需要配置其他VM，这通常太慢而无法响应需求的突然变化，并且配置和维护也很昂贵。

扩大负责维护和更新应用程序团队的难度很大，因为随着应用程序规模的扩大，大型团队的成员并行工作变得越来越困难。

将应用程序迁移到Kubernetes

云原生架构是构建基于Kubernetes的应用程序的核心最佳实践，它增加了抽象层，以掩盖其他复杂性。

这样，虽然三层应用程序仍然基本上保持了三个逻辑层，但是在将其迁移到Kubernetes之后，该应用程序的逻辑看起来却大不相同，如下图2所示。

图2：Kubernetes应用程序的逻辑视图

在上图中，我们已经将以浏览器为中心的表示层扩展到了抽象客户端，该客户端包括移动设备、IoT终结点、第三方SaaS应用程序的云终结点等。

同样，我们用抽象存储代替了传统的持久层，而我们的Kubernetes集群现在代表了应用层。

虽然三层逻辑架构将网络视为理所当然，但在Kubernetes架构中，它是一等公民，因为配置以一致的方式驱动跨计算，网络和存储的抽象。

服务网格通过这种全面的抽象来处理Kubernetes集群中的微服务交互，该抽象将物理网络特征（如VLAN和IP地址）与逻辑网络隔离开来。

云原生API管理技术处理集群中客户端和微服务之间的交互，以及抽象的存储接口（使用容器存储接口（CSI）插件和persistentVolumes之类的技术）。

生产部署的所有方面都应通过配置来表示（在Helm图表，YAML文件等中）。为了进行生产方面的任何更改，Kubernetes团队应遵循不变的基础架构的“非宠物”原则，根据需要更改配置并重新部署。

抽象化“升迁”

将图1所示的应用程序迁移到Kubernetes中，使其最终看起来像图2那样，绝非易事。

即使原始应用程序是完全基于云的应用程序，这种迁移离基本操作也很遥远。

这种情况是棘手难题。

首先，提供一个附加的抽象层，使应用程序可以从图1迁移到图2，而不必进行应用程序通常需要的重新构造和重写。

此外，解决每个层的特殊需求，特别是现在必须利用抽象存储的持久性层。

这一层的挑战是Kubernetes本质上是无状态的，因此，图2中架构的各个方面都不能跟踪任何应用程序的状态或数据。

请记住，Kubernetes容器本质上是短暂的，因此，如果它们跟踪任何内容，状态信息很容易突然丢失。

已迁移的应用程序，需要考虑处理所有由此产生的状态管理问题，处理与抽象存储的交互问题，同时解决与回退和灾难恢复等与状态层相关的棘手问题。

此外，还要维护应用程序的状态– 这方面Kubernetes本身没有提供任何处理方法。例如，如果某个流程（例如，电子商务购买）在中途失败，Kubernetes即时动态配置组件无效时，就需要维持应用程序的状态。

为简单起见，上面的讨论只针对单个应用程序。但是，在现实世界中，企业正在一次将多个应用程序转移到Kubernetes。

企业不仅会转移单个应用程序，也会将多个应用程序组合到“应用程序管道”中，这些组合是经常更新以响应市场不断变化的应用程序的组合。

支持这种动态管道的云原生架构与以前的架构方法本质上是不同的，即使它们一定是建立在过去经验上的。

为了与Kubernetes一起取得成功，必须跳出框框进行思考，框框是您认为关于大规模构建企业应用程序基础架构所了解的一切。