?
? ????? PHP ??? ???? ??? ?? ??
當您運行一群Docker引擎時，管理節(jié)點是管理群集和存儲群集狀態(tài)的關(guān)鍵組件。理解管理節(jié)點的一些關(guān)鍵特性對于正確部署和維護群體非常重要。
請參閱節(jié)點如何工作以簡要概述Docker群集模式以及管理器和工作器節(jié)點之間的區(qū)別。
操作群中的管理者節(jié)點
Swarm管理器節(jié)點使用Raft一致性算法來管理群體狀態(tài)。你只需要理解Raft的一些一般概念就可以管理一個群體。
管理器節(jié)點的數(shù)量沒有限制。決定要實現(xiàn)多少個管理節(jié)點是性能和容錯之間的折中。將管理器節(jié)點添加到群集使群集更容錯。但是，其他管理器節(jié)點會降低寫入性能，因為更多節(jié)點必須確認提議來更新群集狀態(tài)。這意味著更多的網(wǎng)絡(luò)往返流量。
Raft要求大多數(shù)管理者（也稱為法定人數(shù)）同意對群體提出更新，例如節(jié)點添加或刪除。成員資格操作受到與狀態(tài)復(fù)制相同的限制。
維持管理人員的法定人數(shù)
如果群體失去了管理人員的法定人數(shù)，群體就無法執(zhí)行管理任務(wù)。如果你的群體擁有多個管理器，則總是有兩個以上的管理器。為了維持法定人數(shù)，大多數(shù)管理器必須可用。建議使用奇數(shù)的管理器，因為下一個偶數(shù)不會使仲裁容易保留。例如，無論您是3或4位管理器，您仍然只能失去1位管理器并維持法定人數(shù)。如果你有5或6個管理器，你仍然只能失去兩個。
即使群體失去了管理人員的法定人數(shù)，現(xiàn)有工作人員節(jié)點上的群集任務(wù)也會繼續(xù)運行。但是，不能添加，更新或刪除群集節(jié)點，并且無法啟動，停止，移動或更新新的或現(xiàn)有的任務(wù)。
如果您確實失去了管理人員的法定人數(shù)，請參閱恢復(fù)失敗故障排除步驟的法定人數(shù)。
配置管理器通過靜態(tài)IP地址進行通告
啟動群集時，必須指定該--advertise-addr標志以將您的地址通告給群中的其他管理節(jié)點。有關(guān)更多信息，請參閱以群集模式運行Docker引擎。由于管理器節(jié)點旨在成為基礎(chǔ)架構(gòu)的穩(wěn)定組件，因此您應(yīng)該使用廣告地址的固定IP地址來防止群集在重新啟動計算機時變得不穩(wěn)定。
如果整個群體重新啟動并且每個管理節(jié)點隨后都獲得新的IP地址，則任何節(jié)點都無法聯(lián)系現(xiàn)有的管理員。因此，當節(jié)點嘗試以舊IP地址相互聯(lián)系時，群集被掛起。
工作節(jié)點的動態(tài)IP地址正常。
添加管理器節(jié)點以實現(xiàn)容錯
您應(yīng)該維護群體中的奇數(shù)個管理器以支持管理器節(jié)點故障。擁有奇數(shù)個管理器可確保在網(wǎng)絡(luò)分區(qū)期間，如果將網(wǎng)絡(luò)分為兩組，則法定人數(shù)仍然可用于處理請求的可能性較高。如果您遇到兩個以上的網(wǎng)絡(luò)分區(qū)，則不保證達到法定人數(shù)。
Swarm Size | Majority | Fault Tolerance |
|---|---|---|
1 | 1 | 0 |
2 | 2 | 0 |
3 | 2 | 1 |
4 | 3 | 1 |
5 | 3 | 2 |
6 | 4 | 2 |
7 | 4 | 3 |
8 | 5 | 3 |
9 | 5 | 4 |
例如，在一個有5個節(jié)點的群體中，如果失去3個節(jié)點，則沒有法定人數(shù)。因此，在恢復(fù)其中一個不可用的管理節(jié)點或使用災(zāi)難恢復(fù)命令恢復(fù)群集之前，無法添加或刪除節(jié)點。請參閱從災(zāi)難中恢復(fù)。
雖然可以將群集縮放到單個管理器節(jié)點，但不可能降級最后一個管理器節(jié)點。這可以確保您保持對群體的訪問權(quán)限，并且群體仍然可以處理請求?？s小到單個管理員是不安全的操作，不建議實施。如果在降級操作過程中最后一個節(jié)點意外地離開群集，則群集將變?yōu)椴豢捎?，直到重新啟動?jié)點或重新啟動--force-new-cluster。
您管理與群成員docker swarm和docker node子系統(tǒng)。有關(guān)如何添加工作節(jié)點并將工作節(jié)點提升為管理者的更多信息，請參閱向群添加節(jié)點。
分布式管理節(jié)點
除了維護奇數(shù)個管理器節(jié)點之外，放置管理器時還要注意數(shù)據(jù)中心的拓撲結(jié)構(gòu)。為了獲得最佳的容錯性，可以在至少3個可用區(qū)中分配管理器節(jié)點，以支持整套機器或常見維護方案的故障。如果您在任何區(qū)域出現(xiàn)故障，群集應(yīng)維持管理器節(jié)點的法定數(shù)量以處理請求并重新平衡工作負載。
Swarm manager nodes | Repartition (on 3 Availability zones) |
|---|---|
3 | 1-1-1 |
5 | 2-2-1 |
7 | 3-2-2 |
9 | 3-3-3 |
運行僅限manager的節(jié)點
默認情況下，管理節(jié)點也可以作為工作節(jié)點。這意味著調(diào)度程序可以將任務(wù)分配給管理器節(jié)點。對于為管理人員分配任務(wù)的小型和非關(guān)鍵群體，只要您使用cpu和內(nèi)存資源約束來安排服務(wù)，則風險相對較低。
但是，由于管理器節(jié)點使用Raft一致性算法以一致的方式復(fù)制數(shù)據(jù)，因此它們對資源匱乏很敏感。你應(yīng)該隔離群體中的管理人員，使其免受可能阻礙群體心跳或領(lǐng)導(dǎo)者選舉等群體操作的過程。
為了避免干擾管理器節(jié)點操作，可以刪除管理器節(jié)點以使其不可用作worker節(jié)點：
docker node update --availability drain <NODE>
當您排空節(jié)點時，調(diào)度程序?qū)⒐?jié)點上運行的任何任務(wù)重新分配給群中的其他可用工作節(jié)點。它也阻止調(diào)度器將任務(wù)分配給節(jié)點。
添加工作節(jié)點以實現(xiàn)負載平衡
為群體添加節(jié)點以平衡群體的負載。只要工作節(jié)點與服務(wù)的要求相匹配，復(fù)制服務(wù)任務(wù)將隨著時間的推移盡可能均勻地分布在整個群體中。將服務(wù)限制為僅在特定類型的節(jié)點（例如具有特定數(shù)量的CPU或內(nèi)存量的節(jié)點）上運行時，請記住，不符合這些要求的工作節(jié)點將無法運行這些任務(wù)。
監(jiān)測群體健康
您可以nodes通過/nodesHTTP端點以JSON格式查詢Docker API 來監(jiān)控管理器節(jié)點的健康狀況。有關(guān)更多信息，請參閱節(jié)點API文檔。
從命令行運行docker node inspect <id-node>查詢節(jié)點。例如，要查詢作為管理器的節(jié)點的可達性：
docker node inspect manager1 --format "{{ .ManagerStatus.Reachability }}"reachable要將節(jié)點的狀態(tài)查詢?yōu)榻邮苋蝿?wù)的worker，請執(zhí)行以下操作：
docker node inspect manager1 --format "{{ .Status.State }}"ready從這些命令中，我們可以看到，manager1它既是reachable的manager又是ready的worker。
一個unreachable健康的狀態(tài)意味著這個特定的管理器節(jié)點是從其他管理器節(jié)點無法訪問。在這種情況下，您需要采取措施恢復(fù)無法訪問的管理器：
重新啟動守護進程并查看管理器是否回到可訪問狀態(tài)。
重新啟動機器。
如果既不重新啟動也不重新啟動工作，則應(yīng)該添加另一個管理器節(jié)點或?qū)⒐ぷ魅藛T提升為管理器節(jié)點。您還需要從使用
docker node demote <NODE>和設(shè)置的管理器中干凈地刪除失敗的節(jié)點條目docker node rm <id-node>。
或者，您還可以從管理器節(jié)點獲得群集運行狀況的概述，其中包括docker node ls：
docker node ls ID HOSTNAME MEMBERSHIP STATUS AVAILABILITY MANAGER STATUS 1mhtdwhvsgr3c26xxbnzdc3yp node05 Accepted Ready Active 516pacagkqp2xc3fk9t1dhjor node02 Accepted Ready Active Reachable 9ifojw8of78kkusuc4a6c23fx * node01 Accepted Ready Active Leader ax11wdpwrrb6db3mfjydscgk7 node04 Accepted Ready Active bb1nrq2cswhtbg4mrsqnlx1ck node03 Accepted Ready Active Reachable di9wxgz8dtuh9d2hn089ecqkf node06 Accepted Ready Active
管理節(jié)點的故障排除
您不應(yīng)該通過raft從另一個節(jié)點復(fù)制目錄來重新啟動管理器節(jié)點。數(shù)據(jù)目錄對于節(jié)點ID是唯一的。一個節(jié)點只能使用一次節(jié)點ID加入群。節(jié)點ID空間應(yīng)該是全局唯一的。
清晰的地重新加入管理器節(jié)點到集群：
要將節(jié)點降級為工作人員，請運行
docker node demote <NODE>。
2. 若要從群集中刪除節(jié)點，請運行docker node rm <NODE>...
3. 使用以下方法將節(jié)點重新加入到具有新狀態(tài)的群集中。docker swarm join...
有關(guān)將管理器節(jié)點加入群的更多信息，請參閱將群節(jié)點加入群。
強制刪除節(jié)點
在大多數(shù)情況下，您應(yīng)該關(guān)閉一個節(jié)點，然后使用該docker node rm命令將其從群集中刪除。如果某個節(jié)點變得無法訪問，無響應(yīng)或受損，則可以通過傳遞該--force標志強制刪除該節(jié)點而不關(guān)閉該節(jié)點。例如，如果node9變得受到影響：
$ docker node rm node9 Error response from daemon: rpc error: code = 9 desc = node node9 is not down and can't be removed $ docker node rm --force node9 Node node9 removed from swarm
在強制刪除管理器節(jié)點之前，必須先將其降級為輔助角色。如果您降級或刪除管理者，請確保您總是有奇數(shù)個管理者節(jié)點。
備份群
Docker管理器節(jié)點將swarm狀態(tài)和管理器日志存儲在/var/lib/docker/swarm/目錄中。在1.13及更高版本中，這些數(shù)據(jù)包括用于加密Raft日志的密鑰。沒有這些鍵，你將無法恢復(fù)群。
您可以使用任何管理器備份群。使用以下步驟。
如果群體啟用了自動鎖定功能，則需要解鎖密鑰才能從備份恢復(fù)群集。必要時檢索解鎖鑰匙并將其存放在安全的地方。如果您不確定，請閱讀鎖定群集以保護其加密密鑰。
2. 在備份數(shù)據(jù)之前在Manager上停止Docker，以便在備份過程中不會更改任何數(shù)據(jù)?？梢栽诠芾砥鬟\行時進行備份（一個“hot”的備份），但不建議這樣做，并且恢復(fù)時結(jié)果的可預(yù)測性會降低。當管理器關(guān)閉時，其他節(jié)點將繼續(xù)生成不屬于此備份的群集數(shù)據(jù)。
注意：務(wù)必保持群體管理器的法定人數(shù)。在管理器關(guān)閉期間，如果更多節(jié)點丟失，則群體更容易丟失法定人數(shù)。你所經(jīng)營的管理器數(shù)是一種權(quán)衡。如果您定期關(guān)閉管理員進行備份，請考慮運行5管理器群，以便在備份運行時丟失額外的管理器，而不會中斷服務(wù)。
備份整個
/var/lib/docker/swarm目錄。
重新啟動管理器。
要恢復(fù)，請參閱從備份恢復(fù)。
災(zāi)后恢復(fù)
從備份恢復(fù)
按備份群組中的說明備份群組后，使用以下步驟將數(shù)據(jù)恢復(fù)到新群組。
關(guān)閉群集將要恢復(fù)的目標主機上的Docker。
2. 刪除/var/lib/docker/swarm新群體上目錄的內(nèi)容。
3. 使用備份的內(nèi)容還原目錄/var/lib/docker/swarm。 注意：新節(jié)點將使用與舊的節(jié)點相同的加密密鑰進行磁盤存儲。目前無法更改磁盤上的存儲加密密鑰。對于啟用了自動鎖定的群組，解鎖密鑰也與舊群組相同，并且需要解鎖密鑰才能恢復(fù)。
在新節(jié)點上啟動Docker。必要時解鎖群。使用以下命令重新初始化群集，以便此節(jié)點不會嘗試連接到屬于舊群集的節(jié)點，并且可能不再存在。
$ docker swarm init --force-new-cluster
2. 驗證群體的狀態(tài)是否符合預(yù)期。這可能包括特定于應(yīng)用程序的測試或僅檢查輸出docker service ls以確保所有預(yù)期的服務(wù)都存在。
3. 如果您使用自動鎖定，請旋轉(zhuǎn)解鎖鍵。
4. 添加管理器和工作者節(jié)點，使您的新團隊達到運營能力。
5. 在新群體上恢復(fù)先前的備份方案。
從失去法定人數(shù)恢復(fù)
Swarm對故障具有恢復(fù)能力，并且該群可以從任何數(shù)量的臨時節(jié)點故障（機器重啟或重啟時崩潰）或其他瞬時錯誤中恢復(fù)。但是，如果群體失去法定人數(shù)，群體無法自動恢復(fù)?，F(xiàn)有工作節(jié)點上的任務(wù)將繼續(xù)運行，但管理任務(wù)不可行，包括擴展或更新服務(wù)以及加入或從群集中刪除節(jié)點?；謴?fù)的最佳方法是將丟失的管理器節(jié)點重新聯(lián)機。如果這是不可能的，繼續(xù)閱讀一些恢復(fù)你的群的選項。
在一群N管理人員中，管理器節(jié)點的法定人數(shù)（大多數(shù)）必須始終可用。例如，在一個擁有5名管理器的群體中，至少有3人必須開展業(yè)務(wù)并相互溝通。換句話說，群體可以容忍(N-1)/2永遠的失敗，超過這個失敗的群體管理請求不能被處理。這些類型的故障包括數(shù)據(jù)損壞或硬件故障。
如果你失去了管理人員的法定人數(shù)，你不能管理群體。如果您失去了法定人數(shù)，并且您嘗試對群體執(zhí)行任何管理操作，則會發(fā)生錯誤：
Error response from daemon: rpc error: code = 4 desc = context deadline exceeded
從丟失法定數(shù)量中恢復(fù)的最佳方法是將故障節(jié)點重新聯(lián)機。如果你不能這樣做，從這個狀態(tài)恢復(fù)的唯一方法就是使用--force-new-cluster來自管理節(jié)點的動作。這將除去命令運行的管理器之外的所有管理器。達到法定人數(shù)是因為現(xiàn)在只有一名經(jīng)理。促使節(jié)點成為管理器，直到你擁有理想的管理器數(shù)量。
# From the node to recover docker swarm init --force-new-cluster --advertise-addr node01:2377
當您運行docker swarm init命令的--force-new-cluster標志，您運行命令的Docker引擎將成為能夠管理和運行服務(wù)的單個節(jié)點群的管理節(jié)點。管理器擁有有關(guān)服務(wù)和任務(wù)的所有信息，工作節(jié)點仍然是群集的一部分，服務(wù)仍然在運行。您將需要添加或重新添加管理器節(jié)點，以實現(xiàn)您以前的任務(wù)分發(fā)，并確保您有足夠的管理器來保持高可用性和防止丟失仲裁。
強制群體重新平衡
一般來說，你不需要強迫群體重新平衡任務(wù)。當您向群體中添加新節(jié)點或在某段時間不可用后節(jié)點重新連接群體時，群體不會自動將工作負荷分配給閑置節(jié)點。這是一個設(shè)計決定。如果群體為了平衡而周期性地將任務(wù)轉(zhuǎn)移到不同節(jié)點，那么使用這些任務(wù)的客戶端將會中斷。我們的目標是避免為了整個群體的平衡而中斷運行服務(wù)。當新任務(wù)啟動時，或者當運行任務(wù)的節(jié)點變?yōu)椴豢捎脮r，這些任務(wù)將被分配給不太繁忙的節(jié)點。目標是最終平衡，對最終用戶造成的影響最小。
在Docker 1.13及更高版本中，可以使用--forceor -f標志docker service update來強制服務(wù)在可用的工作節(jié)點上重新分配其任務(wù)。這將導(dǎo)致服務(wù)任務(wù)重新啟動?？蛻舳藨?yīng)用程序可能會中斷。如果您已配置它，您的服務(wù)將使用滾動更新。
如果您使用較早的版本，并且希望在工作人員之間達到均衡的負載，并且不介意中斷正在運行的任務(wù)，則可以通過臨時縮放服務(wù)來強制群集重新平衡。使用docker service inspect --pretty <servicename>看服務(wù)的配置比例。在您使用時docker service scale，具有最少任務(wù)數(shù)量的節(jié)點將用于接收新的工作負載。群體中可能有多個負載不足的節(jié)點。您可能需要通過幾次適度增量擴展服務(wù)，以實現(xiàn)所有節(jié)點間的平衡。
當負載達到您的滿意度時，您可以將服務(wù)縮減至原始比例。您可以使用docker service ps來評估跨節(jié)點的服務(wù)當前余額。