超越“迁移”的思考:应用程序该如何被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一起取得成功,必须跳出框框进行思考,框框是您认为关于大规模构建企业应用程序基础架构所了解的一切。

发布了1535 篇原创文章 · 获赞 586 · 访问量 237万+

猜你喜欢

转载自blog.csdn.net/sD7O95O/article/details/104057715