您现在的位置是:主页 > 数据库技术 > 数据库技术

如何实现分布式协调Kubernet

IDCBT2021-12-24服务器技术人已围观

简介这篇文章将为大家详细讲解有关如何实现分布式协调Kubernet,小编觉得挺实用的,因此分享给大家做个参考,希望大家阅读完这篇文章后可以有所收获。 处理调度Jobs 单一的应用程序,就

这篇文章将为大家详细讲解有关如何实现分布式协调Kubernet,小编觉得挺实用的,因此分享给大家做个参考,希望大家阅读完这篇文章后可以有所收获。

处理调度Jobs

单一的应用程序,就是之前在单个节点上运行的单个实例,包括了很多在数据库更新状态的调度jobs(现在也同样发布商务events)。单体程序创建在java中,并且大量使用Spring,所以job看起来是这个样子的:

Spring之后会确认提到过的 doSomethingEveryMinute方法每分钟执行一次。问题是,如果我们目前不在Kubernetes上主持单体程序,并且跟多个实例一起运行,这个job就每分钟会在每个实例上被执行一次,而不仅仅只是每分钟执行了一次而已。如果job有类似发送通知邮件或更新数据库这样的副作用的话,这就是一个问题了。所以我们要怎样避免这个?当然,解决方案还是很多的,显而易见的选择就是利用Kubernetes Jobs,让Kubernetes自己周期性调度jobs。问题就是这个作用只在Kubernetes1.3版本及以上版本中可用,但是1.3还没有发布。但是即使我们能够使用这样一个功能,从技术角度来说,这也是不太可行的。我们的jobs被高度耦合到已经存在的代码库,并且提取每个job到它自己的应用程序,程序可能会有错误,而且如果一次性完成的话会非常耗费时间。所以我们最初的计划是提取所有的调度jobs到一个应用程序,这个应用程序在Kubernetes中只能作为一个实例来运行。但由于现有代码的本质,和高耦合性,即使是这样也很难实现。那么,有没有一种很轻松的办法允许我们目前在单体应用中保持jobs,并且当我们从这个应用中提取功能到独立的服务的时候,逐渐替代他们呢?其实还是有的。

Kubernetes中的Leader选举

要解决这个,我们需要做一些分布式协调,比如,当jobs被Spring执行的时候,如果这个节点不是“leader节点”,为运行调度jobs负责,我们就只需要传回信息(而且,不要和job一起运行代码)。有一些项目能够帮助我们来处理诸如zookeeper和hazelcast之类的东西。但是仅仅只是为了决定哪个节点执行调度jobs,以此来设置、保留zookeeper集群就太劳师动众了。我们需要一些易于管理的东西,假如我们能够利用Kubernetes会怎么样呢?Kubernetes已经在cover下(使用 RAFT consensus algorithm)处理了leader选举。结果证明,这个功能通过使用gcr.io/google_containers/leader-elector Docker镜像已经被暴露给了终端用户。之前已经有一个很棒的博客帖子很细节地描述过这个是如何运行的了,点击这个网址查看:http://blog.kubernetes.io/2016/01/simple-leader-election-with-Kubernetes.html。所以在这里我就不多加赘述了,但是我会讲一讲我们是如何利用镜像来解决我们的问题的。

标签:

很赞哦! ()

本栏推荐