传统虚拟机(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一起取得成功,必须跳出框框进行思考,框框是您认为关于大规模构建企业应用程序基础架构所了解的一切。
以上所述就是小编给大家介绍的《超越“迁移”的思考:应用程序该如何被Kubernetes接管?》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 第十八篇:CSRF导致账号接管
- 图解源码 | 接管SpringMVC的自动配置
- 通过暴露的docker.sock文件接管容器
- PHP中使用Redis接管文件存储Session
- GandCrab后继有人?Sodinoki勒索软件接管战场
- 有漏洞!黑客可以完全接管你的路由器
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。