HashiCorp Nomad中的高级节点排干

最新推荐文章于 2024-09-09 08:00:26 发布

zl1zl2zl3

最新推荐文章于 2024-09-09 08:00:26 发布

阅读量639

点赞数

分类专栏： nomad hashicorp产品文章标签： nomad drain

nomad 同时被 2 个专栏收录

19 篇文章 5 订阅

订阅专栏

hashicorp产品

17 篇文章 10 订阅

订阅专栏

HashiCorp Nomad 0.8引入了高级节点排干，以简化Nomad客户端节点的集群范围升级。本文探讨了如何使用HashiCorp Nomad改进的排干特性在不需要停机的情况下将现有的工作负载从一组节点转移到另一组新的节点。

传统上，升级由调度器管理的生产集群对操作人员来说是一个挑战，因为集群可能正在运行实时工作负载，这些工作负载是为客户端服务的，不能中断。另一个困难是集群操作人员可能不是服务所有者，并且不知道所有生产服务的需求。

HashiCorp Nomad的核心目标是使集群管理对操作人员来说是轻松的，并最小化服务停机时间。通过Nomad 0.8的高级节点排干功能，我们通过让操作人员和开发人员控制迁移如何在集群范围内协调发生来努力实现以上这些特性。

新节点排干器

使用Nomad 0.8引入了一种新的节点排干器，可以安全地排出在Nomad客户端节点上运行的任务。新的节点排干器将检查所有的排干节点，并能够检测哪些作业受到排干操作的影响。然后，它将检查migrate节中所有受影响的作业，并通过遵守节中定义的max_parallel来减少服务的停机时间。max_parallel参数限制了在任何给定时间可以迁移的分配数。Nomad通过限制并行迁移不超过这个值来遵守这个字段的规定。由于应用程序没有立即准备好为流量服务，Nomad等待替换的分配变得健康，然后继续迁移分配，这有助于减少服务停机时间。Nomad 0.8中的新节点排干器允许Nomad在排干节点时拥有一个集群范围的视图，并允许服务所有者定义使用migrate节在节点间迁移作业所需的所有必要参数。

Migrate节

使用Nomad 0.8，通过在任务组级别引入一个新的migrate节，改进了排干行为，它允许开发人员为他们的工作定义排干行为。下面是my-api作业的migrate节示例，它允许Nomad以每次一个分配的速度迁移作业，并且要求在迁移到下一个作业之前至少10秒内保持健康。

job "my-api" {
    datacenters = ["dc1"]
    type = "service"

    group "my-api" {
    count = 2

    migrate {
        # Perform one parallel migration at a time.
        max_parallel     = 1

        # Ensure that the newly placed allocations are healthy for at least 10
        # seconds before moving on with the migration process.
        min_healthy_time = "10s"

        # Give the allocation at most 3 minutes to be marked healthy before 
        # other migrations can continue.
        healthy_deadline = "3m"
    }

    restart {
.....

在排干节点时，Nomad将使用group的migrate节在集群中的其他节点上创建新的分配。在上面的示例中，如果在运行my-api作业的节点上发出一个节点排干命令，Nomad将通过在集群中的另一个节点上使用my-api服务的相同版本创建一个新分配来迁移作业。新创建的分配需要在Nomad继续迁移作业中的分配之前的3分钟内通过健康检查。这个过程帮助负责my-api服务的开发人员使用migrate节中定义的参数来定义在节点耗尽时如何迁移作业。这也有助于操作人员即使不知道这些细粒度设置，而将重点放在集群中的节点升级上。

Node Drain与Eligibility命令

新的node drain命令引入了节点资格的概念。每个Nomad客户节点都可以是可调度的，也可以是不可调度的。当排干节点时，Nomad会将节点标记为ineligible新位置。

Nomad 0.8还允许操作人员在排干节点时设定一个截止期限。设置后，Nomad将等待直到最后期限，在此期限内，所有的分配都必须从节点中移出，否则将被迫从节点中强行移除。设置最后期限为操作人员提供了最后的时间，在此期间，他们可以删除资源，但允许作业有足够的时间迁移到另一个节点。此外，Nomad允许batch作业继续在一个排干节点上运行，直到最后期限。这允许完成几乎完整的batch作业，有助于降低与运行batch作业相关的成本。下面是一个使用-deadline命令行标志和node drain命令的示例。

nomad node drain -enable -self -deadline 30m

在上面的示例中，Nomad将等待30分钟，然后强制将作业从节点中移除。

Nomad中的system作业允许日志传输器和指标收集器等服务在所有Nomad客户端节点上运行。如果客户端节点被排干，那么system作业是最后一个被迁移的，这允许在这些作业被排干之前，所有的指标和日志被传输。

改进以前的排干命令

在Nomad 0.8之前，当发出一个节点排干命令时，Nomad会用drain =true标记一个节点，这个节点不允许在本节点调度任何新的作业。然后，Nomad将为节点上运行的所有作业创建新的评估，并将它们重新调度到集群中的其他节点。这种行为在某些情况下会导致服务停机。与节点排干行为相关的其他几个问题如下:

在对客户端执行滚动排干和重新启动时，作业可以在节点之间重复移动，并可以放置在即将排干的节点上。
在一个场景中，某个特定服务的所有作业都在一个节点上运行，排干该节点将导致该节点上运行的所有作业同时停止，从而导致该服务的停机。
每次排干一个节点并等待新的部署位置是冗长乏味的，而且容易出错。
同时排干多个节点可能会导致停机，原因是排干节点之间缺乏协调。
排干正在运行batch作业的节点可能会导致作业在完成工作之前停止，这可能需要重新启动它们以重新执行工作。
排干节点将导致在节点上运行的system作业立即被排干。

综上所述，在Nomad v0.8之前，协调零停机时间排干需要操作人员大量的手工监督，因为他们无法控制单个任务的排干。

与Update节的区别

理解update和migrate节之间的区别是很重要的，因为它们有相似的参数，但在Nomad中用于不同的用例。

update节用于处理作业版本之间的转换。它的目的是帮助协调诸如滚动部署和canary部署之类的事情。开发人员可能对它更感兴趣，因为他们想要控制如何将作业从一个版本升级到另一个版本。

migrate节定义了调度程序在集群更改现有作业时的行为。由于这些作业已经在集群中运行，操作人员可以使用migrate节来定义在以不影响作业服务质量的方式排干节点时应该如何重新调度作业。在节点排干的情况下，作业的相同版本在节点之间迁移，因此migrate节不提供auto_revert、canary和stagger等参数。