摘要：问题就是这个作用只在版本及以上版本中可用，但是还没有发布。中的选举要解决这个，我们需要做一些分布式协调，比如，当被执行的时候，如果这个节点不是节点，为运行调度负责，我们就只需要传回信息而且，不要和一起运行代码。
Parkster这个项目正在从单体应用转化到微服务的过程中，已经使用Kubernetes有一段时间了，尚未被移动到Kubernetes应用程序的就是单体应用剩下的部分。将单体应用完全分裂成微服务是一个愿景，在这个过程中，我们从kubernetes提供的调度、服务发现、高可用性、日志收集等服务中受益诸多。要达到在这种程度还需要做很多工作。在这篇文章中，我们要探索的是周期性单个开启调度工作的问题。
处理调度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镜像已经被暴露给了终端用户。之前已经有一个很棒的博客帖子很细节地描述过这个是如何运行的了，点击这个网址查看：这里。所以在这里我就不多加赘述了，但是我会讲一讲我们是如何利用镜像来解决我们的问题的。
解决问题我们做的就是带来gcr.io/google_containers/leader-elector容器到我们的pod，这样就可以让单体应用的实例都运行一个leader选举的实例。这是证明Kubernetes pod有用的典型例子。
以下是一个在我们的配置resource中定义好的pod的摘录：
我们开启leader选举以及我们的单体应用程序。注意，我们将--election=monolith-jobs当作第一个参数。这就意味着leader选举知道容器属于哪一个组。所以指定这个组的容器会是leader选举进程中的一部分，这个组之中只有一个容器会被选举为leader。--http=localhost:4040的第二个参数同样是非常重要的。它在4040端口打开了一个网页服务器，在这个端口，我们可以查询到目前leader的pod名字，然后以这个格式返回：
这是我们决定要不要运行我们的job的一个小把戏。我们要做的事情就是检查即将执行调度pod的名字是否跟选举出来的leader一致，如果一致，我们就应该继续执行，并且执行job，或者其它的我们应该返回的东西。比如：
所以我们来看看ClusterLeaderService是如何被实施的。首先，我们必须从应用程序获得pod的名字。Kubernetes将pod名字存储在/etc/hostname，Java将这个/etc/hostname暴露在HOSTNAME环境变量，这就是我们将在这个例子中引用的。另一个方法就是使用Downward API将pod名字暴露到环境变量选择。比如：
从这里，我们可以看到 metadata.name （也就是pod的名字）会与MY_POD_NAME环境变量联系在一起。但是现在让我们来看看 ClusterLeaderService的实施是看起来是怎么样的：
在这里例子中，我们正在从RESTAssured项目使用JsonPath来查询选举者网页服务，并且从回应中提取pod的名字。然后我们简单地将本地容器的名字跟leader相比较，如果他们是相同的，那么我们就知道这个实例就是leader！就是这样！
结论事实证明，上述工作运行地很不错！如果leader节点要挂掉了，那么另一个就会自动选举上。但这个过程会花上一点时间，要一分钟左右。所以这个还是要权衡一下的。假如你的工作中不允许错过任意一个job执行，那么这个选择对你来说是不合适的。但在我们上述的例子中，中间有那么一分钟job没有被准确执行，对我们来说无伤大雅。所以我觉得这个方法十分简单，而且当移植一个现有的包含调度jobs的应用程序的时候很有价值，因为调度jobs总有各种各样很难提取的原因。
原文链接
（如果需要转载，请联系我们哦，尊重知识产权人人有责；）
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/32474.html
摘要：那都是老一套了。已死已经没有人用了。现在所有的一切都在容器化，它是未来。这是确保它可靠的唯一方式。我现在需要一个是的，为了稳定性。我猜是规模的对，没错。我明白了，好吧，我懂了。那我来重复一遍确保我领悟了这些。 这是一篇在国外社区非常火的文章。由CircleCI创始人所写，追逐热点新技术的程序员与只想做个简单web应用的程序员对话，Docker到底能否解决简单小应用的问题吗？Herok...
摘要：公司始于名为的平台即服务供应商。跨多个机器之间协调这些容器需要额外的工具，这称之为容器编排。的核心优势是为应用程序开发人员提供了用于编排无状态容器的强大工具。有无数的文章都在讨论和比较Docker、Kubernetes 以及Mesos。如果你是初学者，那么你可能会认为这三个开源项目正为了称霸容器界而殊死搏斗。虽然这三种技术都使得使用容器部署、管理和伸缩应用成为可能，但实际上它们各自解决了不同...
摘要：分布式文件系统和数据库，由于性能和成本，是持久性本地存储的主要用例。在裸机上，除了性能之外，本地存储通常更便宜，并且使用它是配置分布式文件系统的必要条件。 作者：1.14发布团队 我们很高兴地宣布推出Kubernetes 1.14，这是我们2019年的首次发布！ showImg(https://segmentfault.com/img/bVbqrJZ?w=300&h=293); Kub...
摘要：分布式文件系统和数据库，由于性能和成本，是持久性本地存储的主要用例。在裸机上，除了性能之外，本地存储通常更便宜，并且使用它是配置分布式文件系统的必要条件。 作者：1.14发布团队 我们很高兴地宣布推出Kubernetes 1.14，这是我们2019年的首次发布！ showImg(https://segmentfault.com/img/bVbqrJZ?w=300&h=293); Kub...
摘要：同时该版本在安全性和等关键功能上作出了改进年月日，发布。尽管谷歌这些年来是的主要贡献者，但现在其他技术人员在这个项目上的贡献量已经几乎和谷歌持平了。这些举动都在表明云计算市场的战火将继续蔓延，已经成为兵家必争之地。年月日，宣布推出。 Kubernetes 在过去几年中一直是云计算领域最著名的开源项目之一。20...
阅读 813·2021-11-18 10:07
阅读 2306·2021-10-14 09:42
阅读 5220·2021-09-22 15:45
阅读 566·2021-09-03 10:29
阅读 3444·2021-08-31 14:28
阅读 1854·2019-08-30 15:56
阅读 3023·2019-08-30 15:54
阅读 975·2019-08-29 11:32
