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

图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一起取得成功，必须跳出框框进行思考，框框是您认为关于大规模构建企业应用程序基础架构所了解的一切。