在阿里云上使用Marathon

  • 时间:
  • 浏览:1
  • 来源:大发彩神8下载最新版—大发快三官网大发彩神

可见,无感知平滑漂移是另一一5个容器调度服务系统的必备功能。只能实现了平滑漂移,才有将会落地快速迭代开发依据,每天线上发版数十次;只能实现了平滑漂移,运维机器人才能放开手脚,自由的重启情形异常的容器,合理的调整容器的配额,更好的为实现高可用零宕机服务!

朋友部署了另一一5个基于golang web server的运维服务平台(osp),在上边实现了这人 回调接口。该接口订阅status_update_event事件,并判断taskStatus的值。将会taskStatusTASK_RUNNING,没人就加带对应节点到SLB;将会是[TASK_FINISHED, TASK_KILLED, TASK_LOST, TASK_FAILED],则从SLB中移除对应的后端节点。

以前的文章《阿里云容器服务测评》就高可用零宕机方面对容器服务作了删改测评,本文朋友介绍一下小博无线目前的线上环境,Mesos+Marathon,是怎样做到高可用零宕机的。

朋友利用Marathon的Event Bus机制来补救这人 疑问,启动Marathon时,还才能 配置另一一5个HTTP回调地址,当一点特定的事件处在时,Marathon通知回调地址。

测试发现这人 方案不可行,愿因是Marathon并是是不是在第一次向容器发送SIGTERM信号时,一点在发送SIGKILL信号将容器强制停止后,才触发taskStatus==TASK_KILLED事件,

Marathon支持三种模式的健康检查:

这人 疑问朋友起初期望通过Event Bus来补救:

一点朋友又加入了另一一5个上边层,它是另一一5个部署在容器中的golang web server,做下面两件事情:

补救了上边和SLB有关的另一一5个疑问后,才能补救容器的启动与停止过程中对服务质量的影响。但在容器运行中,依然有将会处在影响服务的情形,之类负载的变化。

Marathon作为Mesos的容器调度框架,三种就提供了非常可靠的高可用方案:

将会web server处在容器内控 ,健康检查还才能 由COMMAND模式改为HTTP模式,原来就很好地补救了上边碰到的另一一5个疑问。确实增加了些比较复杂度,还要在每个容器中嵌入这人 web server,但还才能 将这人 步固化在最底层的base image中,一点其硬件开销几乎还才能 忽略不计(只能2M内存)。

原来做了以前,服务在任意时刻总要处在另一一5个合理的配置,既能负担高峰期的压力,又不至于闲置太大的资源。

然而,Marathon我太大 原生支持动态地伸缩容器。为了补救这人 疑问,朋友制作了运维机器人TidyMaid,用于收集、分析每个容器负载,判断是横向还是纵向地伸缩服务。大致的方案为:

合理的资源配置参数不应是静态的,而应随着负载的变化而动态地伸缩。这里的伸缩,分为另一一5个方面:

这人 流程处在以下严重不足:

最终的方案为,在容器中捕获SIGTERM信号,以前通知运维平台容器即将被停止,运维平台收到请求后将该容器在SLB的权重设为0。通过设置executor_shutdown_grace_perioddocker_stop_timeout参数为容器从收到SIGTERM信号到被强制停止之间留出一分钟,这每段时间用于SLB的断流以及容器对已有请求的补救的平滑切换。

最终的流程如下:

但哪些地方地方还严重不足,将会:

在阿里云上使用Marathon,基本上总要遇到这5个疑问。下面介绍朋友是怎样补救哪些地方地方疑问的。

该方案背后的考虑是,CPU负载的变化,一般和流量压力紧密关联,压力的变化会立即反映在CPU负载上,横向伸缩能立即适配流量压力;一点内存则不然,一点以前,内存负载升高,仅靠增加容器个数我太大 能补救疑问。确实增加容器使每个容器的请求压力降低,但对于内存将会居高的容器,其负载我太大 会立即下降,好多好多 选取直接停止服务将会纵向伸缩(纵向伸缩会重启服务)。

一年多的线上实战表明,这套补救方案是非常可靠的。无论是部署、重启、还是停止容器,都还才能 做到无感知平滑漂移。

怎样让Marathon的健康检查获取到SLB的情形?朋友的设计是通过加带另一一5个负责查询SLB情形的上边层,并让健康检查请求这人 上边层。

第一版的整个流程如图:

朋友在最底层的镜像中创建了服务的运行框架,其中另一一5个python任务管理器会将指定的所有服务启动起来。一点朋友我希望在这人 python任务管理器中捕获SIGTERM信号并通知运维平台即可补救疑问。

Marathon支持对每个容器配置不同的资源(CPU、内存、磁盘),也还才能 选取不配置,让所有容器共用ECS资源,但建议尽量我太大 没人做,这人 做法确实简单,原来风险很高,让单个服务是是不是将会耗光ECS上的CPU或内存资源,进而影响到部署在ECS上所有服务的服务质量。

其中TCP和HTTP只能请求容器内的端口,COMMAND则还才能 设置为任意shell命令。朋友在osp上实现了原来另一一5个接口:查询SLB情形,将会情形为『正常』,缓存结果下次不再查询,一点每次都调用SLB API进行查询。不言而喻缓存查询结果,是将会SLB Health API迅速,一点有调用次数的限制。最后使用COMMAND健康检查请求这人 接口。配置如下: