红联Linux门户
Linux协助

容器环境中的署理模型

发布时刻:2018-04-02 13:45:09来历:linux.cn作者:geekpi
 
咱们大多数人都了解署理怎么作业,但在依据容器的环境中有什么不同?让咱们来看看有什么改动。
 
 
内联、侧臂side-arm、反向和前向。这些从前是咱们用来描绘网络署理架构布局的术语。
 
现在,容器运用一些相同的术语,但它们正在引进新的东西。这对我是个机会来论述我独爱的一切主题:署理。
 
云的首要驱动之一(咱们从前有过本钱操控的白日梦)便是可扩展性。在曩昔五年中,扩展在各种查询中面临着敏捷性的应战(有时乃至取胜),由于这是组织在云核算环境中布置运用的最大寻求。
 
这在必定程度上是由于在(咱们现在运营的)数字经济中,运用已经成为像实体店的“经营/歇息”的标牌和导购相同的东西。缓慢、无呼应的运用好像商铺关灯或短少经营人员相同。
 
容器环境中的署理模型
 
运用需求随时可用且能够满意需求。扩展是完成这一事务方针的技能呼应。云不只供给了扩展的才能,而且还供给了主动扩展的才能。要做到这一点,需求一个负载均衡器。由于这便是咱们扩展运用程序的方法 :运用署理来负载均衡流量/恳求。
 
容器在扩展上与预期没有什么不同。容器有必要进行扩展(并主动扩展)这意味着运用负载均衡器(署理)。
 
假如你运用的是原有的署理机制,那便是选用依据 TCP/UDP 进行根本的负载平衡。一般来说,依据容器的署理的完成在 HTTP 或其他运用层协议中并不流通,并不能在老式的负载均衡(POLB)之外供给其他功用。这一般足够了,由于容器扩展是在一个克隆的、假定水平扩展的环境中进行的:要扩展一个运用程序,就增加另一个副本并在其上分发恳求。在进口处(在进口操控器和 API 网关中)能够找到第 7 层(HTTP)路由功用,而且能够运用尽可能多(或更多)的运用路由来扩展运用程序。
 
但是,在某些状况下,这还不行。假如你期望(或需求)更多以运用程序为中心的扩展或刺进其他服务的才能,那么你就能够取得更强健的产品,可供给可编程性或以运用程序为中心的可伸缩性,或许两者兼而有之。
 
这意味着刺进署理。你正在运用的容器编列环境在很大程度上决议了署理的布置模型,不管它是反向署理仍是前向署理。更风趣的是,还有第三个模型挎斗形式 ,这是由新式的服务网格完成支撑的可扩展性的根底。
 

反向署理

容器环境中的署理模型
 
反向署理最挨近于传统模型,在这种模型中,虚拟服务器承受一切传入恳求,并将其分发到资源池(服务器中心、集群)中。
 
每个“运用程序”有一个署理。任何想要连接到运用程序的客户端都连接到署理,署理然后挑选并转发恳求到恰当的实例。假如绿色运用想要与蓝色运用通讯,它会向蓝色署理发送恳求,蓝色署理会确认蓝色运用的两个实例中的哪一个应该呼应该恳求。
 
在这个模型中,署理只关怀它正在办理的运用程序。蓝色署理不关怀与橙色署理相关的实例,反之亦然。
 

前向署理

 
容器环境中的署理模型
这种形式更挨近传统的出站防火墙的形式。
 
在这个模型中,每个容器 节点 都有一个相关的署理。假如客户端想要连接到特定的运用程序或服务,它将连接到正在运转的客户端地点的容器节点的本地署理。署理然后挑选一个恰当的运用实例,并转发客户端的恳求。
 
橙色和蓝色的运用连接到与其节点相关的同一个署理。署理然后确认所恳求的运用实例的哪个实例应该呼应。
 
在这个模型中,每个署理有必要知道每个运用,以保证它能够将恳求转发给恰当的实例。
 

挎斗署理

 
容器环境中的署理模型
这种模型也被称为服务网格路由。在这个模型中,每个容器都有自己的署理。
 
假如客户想要连接到一个运用,它将连接到挎斗署理,它会挑选一个适宜的运用程序实例并转发客户端的恳求。此行为与前向署理模型相同。
 
挎斗署理和前向署理之间的差异在于,挎斗署理不需求修正容器编列环境。例如,为了刺进一个前向署理到 k8s,你需求署理和一个 kube-proxy 的代替。挎斗署理不需求这种修正,由于运用会主动连接到 “挎斗” 署理而不是经过署理路由。
 
总结
每种形式都有其长处和缺陷。三者一起依靠环境数据(长途监控和装备改变),以及融入生态体系的需求。有些模型是依据你挑选的环境预先确认的,因而需求细心考虑将来的需求(服务刺进、安全性、网络复杂性)在树立模型之前需求进行评价。
 
在容器及其在企业中的开展方面,咱们还处于前期阶段。跟着它们持续延伸到出产环境中,了解容器化环境发布的运用程序的需求以及它们在署理模型完成上的差异是非常重要的。
 
这篇文章是仓促写就的。现在就这么多。