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 = 2migrate {# 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等參數。

結論

使用Nomad 0.8，我們發布了高級節點排干功能，通過讓操作人員和開發人員控制集群范圍內的、協調的遷移方式來幫助他們。這篇文章展示了高級節點排干如何推動所有的智能安全地向Nomad進行服務遷移，允許開發人員專注于構建他們的服務，而操作人員專注于確保運行這些服務的基礎設施是穩定的。

總結

以上是生活随笔為你收集整理的HashiCorp Nomad中的高级节点排干的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。