jinfeng_wang

【編者按】CoreOS是一個(gè)基于Docker的輕量級(jí)容器化Linux發(fā)行版，專為大型數(shù)據(jù)中心而設(shè)計(jì)，旨在通過(guò)輕量的系統(tǒng)架構(gòu)和靈活的應(yīng)用程序部署能力簡(jiǎn)化數(shù)據(jù)中心的維護(hù)成本和復(fù)雜度。CoreOS作為Docker生態(tài)圈中的重要一員，日益得到各大云服務(wù)商的重視，目前已經(jīng)完成了A輪融資，發(fā)展風(fēng)頭正勁。InfoQ希望《CoreOS實(shí)戰(zhàn)》系列文章能夠幫助讀者了解CoreOS以及相關(guān)的使用方法。如果說(shuō)Docker是下一代的虛擬機(jī)，那CoreOS就應(yīng)該是下一代的服務(wù)器Linux，InfoQ愿和您一起探索這個(gè)新生事物。另外，歡迎加入InfoQ Docker技術(shù)交流群，QQ群號(hào)：272489193。

1. 概述

etcd 是一個(gè)應(yīng)用在分布式環(huán)境下的 key/value 存儲(chǔ)服務(wù)。利用 etcd 的特性，應(yīng)用程序可以在集群中共享信息、配置或作服務(wù)發(fā)現(xiàn)，etcd 會(huì)在集群的各個(gè)節(jié)點(diǎn)中復(fù)制這些數(shù)據(jù)并保證這些數(shù)據(jù)始終正確。etcd 無(wú)論是在 CoreOS 還是 Kubernetes 體系中都是不可或缺的一環(huán)。筆者由于項(xiàng)目的原因?qū)?etcd 進(jìn)行了一些了解，也已經(jīng)使用了一段時(shí)間。同時(shí)在與同行的交流中常被問(wèn)到 etcd 是什么、與 ZooKeeper 有什么不同。那么借著 etcd 0.5.0 即將發(fā)布的機(jī)會(huì)，向感興趣的讀者介紹一下 etcd，希望可以幫助讀者了解 etcd 的工作原理以及具體實(shí)現(xiàn)，同時(shí)也作為 CoreOS 實(shí)戰(zhàn)的第二部分內(nèi)容為后面相關(guān)的部分進(jìn)行鋪墊。

隨著 etcd 0.5.0 alpha （本文完稿時(shí)為 etcd 0.5.0 alpha.3）版發(fā)布，etcd 將在未來(lái)幾周內(nèi)迎來(lái)一次重要的更新。在 0.5.0 版里除了修復(fù)現(xiàn)有穩(wěn)定版中的一系列 Bug 之外，一些新的特性和變更也將隨之發(fā)布。這些變化將提升 etcd 服務(wù)安全性、可靠性和可維護(hù)性。

新的特性包括

• 規(guī)范詞匯表；
• 新的 raft 算法實(shí)現(xiàn)；
• 新增 etcd node 身份標(biāo)記；
• WAL (Write-ahead logging) 增加 CRC 校驗(yàn)；
• API 中新增 member {list, add, remove} 接口，原來(lái)的 list machines 接口將被移除，未來(lái) etcd 集群中將不存在 machine 的稱呼；
• 兩個(gè)主要端口變更為 2379 (for client) 與 2380 (for peer/raft) 并成為 IANA 的注冊(cè)端口。

重要的變更包括

• 運(yùn)行時(shí)重構(gòu) (runtime reconfiguration)。用戶不需要重啟 etcd 服務(wù)即可實(shí)現(xiàn)對(duì) etcd 集群結(jié)構(gòu)進(jìn)行變更。
• 摒棄通過(guò)配置文件配置 etcd 屬性的方式，轉(zhuǎn)而以 CLI (command-line interface) flags 或環(huán)境變量的方式實(shí)現(xiàn) etcd 節(jié)點(diǎn)的配置。
• 每個(gè)節(jié)點(diǎn)可監(jiān)聽多個(gè)廣播地址。監(jiān)聽的地址由原來(lái)的一個(gè)擴(kuò)展到多個(gè)，用戶可以根據(jù)需求實(shí)現(xiàn)更加復(fù)雜的集群環(huán)境，如搭建一個(gè)混合了私有云與公有云服務(wù)的 etcd 集群。
• 新增 proxy mode。

2. 規(guī)范詞匯表

etcd 0.5.0 版首次對(duì) etcd 代碼、文檔及 CLI 中使用的術(shù)語(yǔ)進(jìn)行了定義。

2.1. node

node 指一個(gè) raft 狀態(tài)機(jī)實(shí)例。每個(gè) node 都具有唯一的標(biāo)識(shí)，并在處于 leader 狀態(tài)時(shí)記錄其它節(jié)點(diǎn)的步進(jìn)數(shù)。

2.2. member

member 指一個(gè) etcd 實(shí)例。member 運(yùn)行在每個(gè) node 上，并向這一 node 上的其它應(yīng)用程序提供服務(wù)。

2.3. Cluster

Cluster 由多個(gè) member 組成。每個(gè) member 中的 node 遵循 raft 共識(shí)協(xié)議來(lái)復(fù)制日志。Cluster 接收來(lái)自 member 的提案消息，將其提交并存儲(chǔ)于本地磁盤。

2.4. Peer

同一 Cluster 中的其它 member。

2.5. Client

Client 指調(diào)用 Cluster API 的對(duì)象。

3. Raft 共識(shí)算法

etcd 集群的工作原理基于 raft 共識(shí)算法 (The Raft Consensus Algorithm)。etcd 在 0.5.0 版本中重新實(shí)現(xiàn)了 raft 算法，而非像之前那樣依賴于第三方庫(kù) go-raft 。raft 共識(shí)算法的優(yōu)點(diǎn)在于可以在高效的解決分布式系統(tǒng)中各個(gè)節(jié)點(diǎn)日志內(nèi)容一致性問(wèn)題的同時(shí)，也使得集群具備一定的容錯(cuò)能力。即使集群中出現(xiàn)部分節(jié)點(diǎn)故障、網(wǎng)絡(luò)故障等問(wèn)題，仍可保證其余大多數(shù)節(jié)點(diǎn)正確的步進(jìn)。甚至當(dāng)更多的節(jié)點(diǎn)（一般來(lái)說(shuō)超過(guò)集群節(jié)點(diǎn)總數(shù)的一半）出現(xiàn)故障而導(dǎo)致集群不可用時(shí)，依然可以保證節(jié)點(diǎn)中的數(shù)據(jù)不會(huì)出現(xiàn)錯(cuò)誤的結(jié)果。

3.1. 集群建立與狀態(tài)機(jī)

raft 集群中的每個(gè)節(jié)點(diǎn)都可以根據(jù)集群運(yùn)行的情況在三種狀態(tài)間切換：follower, candidate 與 leader。leader 向 follower 同步日志，follower 只從 leader 處獲取日志。在節(jié)點(diǎn)初始啟動(dòng)時(shí)，節(jié)點(diǎn)的 raft 狀態(tài)機(jī)將處于 follower 狀態(tài)并被設(shè)定一個(gè) election timeout，如果在這一時(shí)間周期內(nèi)沒有收到來(lái)自 leader 的 heartbeat，節(jié)點(diǎn)將發(fā)起選舉：節(jié)點(diǎn)在將自己的狀態(tài)切換為 candidate 之后，向集群中其它 follower 節(jié)點(diǎn)發(fā)送請(qǐng)求，詢問(wèn)其是否選舉自己成為 leader。當(dāng)收到來(lái)自集群中過(guò)半數(shù)節(jié)點(diǎn)的接受投票后，節(jié)點(diǎn)即成為 leader，開始接收保存 client 的數(shù)據(jù)并向其它的 follower 節(jié)點(diǎn)同步日志。leader 節(jié)點(diǎn)依靠定時(shí)向 follower 發(fā)送 heartbeat 來(lái)保持其地位。任何時(shí)候如果其它 follower 在 election timeout 期間都沒有收到來(lái)自 leader 的 heartbeat，同樣會(huì)將自己的狀態(tài)切換為 candidate 并發(fā)起選舉。每成功選舉一次，新 leader 的步進(jìn)數(shù)都會(huì)比之前 leader 的步進(jìn)數(shù)大1。

圖 3-1 raft 狀態(tài)切換示意圖

3.2. 選舉

3.2.1. 一個(gè) candidate 成為 leader 需要具備三個(gè)要素：

• 獲得集群多數(shù)節(jié)點(diǎn)的同意；
• 集群中不存在比自己步進(jìn)數(shù)更高的 candidate；
• 集群中不存在其他 leader。

3.2.2. 下面為一個(gè) etcd 集群選舉過(guò)程的簡(jiǎn)單描述：

? 初始狀態(tài)下集群中的所有節(jié)點(diǎn)都處于 follower 狀態(tài)。

? 某一時(shí)刻，其中的一個(gè) follower 由于沒有收到 leader 的 heartbeat 率先發(fā)生 election timeout 進(jìn)而發(fā)起選舉。

? 只要集群中超過(guò)半數(shù)的節(jié)點(diǎn)接受投票，candidate 節(jié)點(diǎn)將成為即切換 leader 狀態(tài)。

? 成為 leader 節(jié)點(diǎn)之后，leader 將定時(shí)向 follower 節(jié)點(diǎn)同步日志并發(fā)送 heartbeat。

3.3. 節(jié)點(diǎn)異常

集群中各個(gè)節(jié)點(diǎn)的狀態(tài)隨時(shí)都有可能發(fā)生變化。從實(shí)際的變化上來(lái)分類的話，節(jié)點(diǎn)的異常大致可以分為四種類型：

• leader 不可用；
• follower 不可用；
• 多個(gè) candidate 或多個(gè) leader；
• 新節(jié)點(diǎn)加入集群。

3.3.1. leader 不可用

下面將說(shuō)明當(dāng)集群中的 leader 節(jié)點(diǎn)不可用時(shí)，raft 集群是如何應(yīng)對(duì)的。

? 一般情況下，leader 節(jié)點(diǎn)定時(shí)發(fā)送 heartbeat 到 follower 節(jié)點(diǎn)。

? 由于某些異常導(dǎo)致 leader 不再發(fā)送 heartbeat ，或 follower 無(wú)法收到 heartbeat 。

? 當(dāng)某一 follower 發(fā)生 election timeout 時(shí)，其狀態(tài)變更為 candidate，并向其他 follower 發(fā)起投票。

? 當(dāng)超過(guò)半數(shù)的 follower 接受投票后，這一節(jié)點(diǎn)將成為新的 leader，leader 的步進(jìn)數(shù)加1并開始向 follower 同步日志。

? 當(dāng)一段時(shí)間之后，如果之前的 leader 再次加入集群，則兩個(gè) leader 比較彼此的步進(jìn)數(shù)，步進(jìn)數(shù)低的 leader 將切換自己的狀態(tài)為 follower。

? 較早前 leader 中不一致的日志將被清除，并與現(xiàn)有 leader 中的日志保持一致。

3.3.2. follower 節(jié)點(diǎn)不可用

follower 節(jié)點(diǎn)不可用的情況相對(duì)容易解決。因?yàn)榧褐械娜罩緝?nèi)容始終是從 leader 節(jié)點(diǎn)同步的，只要這一節(jié)點(diǎn)再次加入集群時(shí)重新從 leader 節(jié)點(diǎn)處復(fù)制日志即可。

? 集群中的某個(gè) follower 節(jié)點(diǎn)發(fā)生異常，不再同步日志以及接收 heartbeat。

? 經(jīng)過(guò)一段時(shí)間之后，原來(lái)的 follower 節(jié)點(diǎn)重新加入集群。

? 這一節(jié)點(diǎn)的日志將從當(dāng)時(shí)的 leader 處同步。

3.3.3. 多個(gè) candidate 或多個(gè) leader

在集群中出現(xiàn)多個(gè) candidate 或多個(gè) leader 通常是由于數(shù)據(jù)傳輸不暢造成的。出現(xiàn)多個(gè) leader 的情況相對(duì)少見，但多個(gè) candidate 比較容易出現(xiàn)在集群節(jié)點(diǎn)啟動(dòng)初期尚未選出 leader 的“混沌”時(shí)期。

? 初始狀態(tài)下集群中的所有節(jié)點(diǎn)都處于 follower 狀態(tài)。

? 兩個(gè)節(jié)點(diǎn)同時(shí)成為 candidate 發(fā)起選舉。

? 兩個(gè) candidate 都只得到了少部分 follower 的接受投票。

? candidate 繼續(xù)向其他的 follower 詢問(wèn)。

? 由于一些 follower 已經(jīng)投過(guò)票了，所以均返回拒絕接受。

? candidate 也可能向一個(gè) candidate 詢問(wèn)投票。

? 在步進(jìn)數(shù)相同的情況下，candidate 將拒絕接受另一個(gè) candidate 的請(qǐng)求。

? 由于第一次未選出 leader，candidate 將隨機(jī)選擇一個(gè)等待間隔（150ms ~ 300ms）再次發(fā)起投票。

? 如果得到集群中半數(shù)以上的 follower 的接受，這一 candidate 將成為 leader。

? 稍后另一個(gè) candidate 也將再次發(fā)起投票。

? 由于集群中已經(jīng)選出 leader，candidate 將收到拒絕接受的投票。

? 在被多數(shù)節(jié)點(diǎn)拒絕之后，并已知集群中已存在 leader 后，這一 candidate 節(jié)點(diǎn)將終止投票請(qǐng)求、切換為 follower，從 leader 節(jié)點(diǎn)同步日志。

3.4. 日志

3.4.1. 復(fù)制

在 raft 集群中，所有日志都必須首先提交至 leader 節(jié)點(diǎn)。leader 在每個(gè) heartbeat 向 follower 同步日志，follower 在收到日志之后向 leader 反饋結(jié)果，leader 在確認(rèn)日志內(nèi)容正確之后將此條目提交并存儲(chǔ)于本地磁盤。

? 首先有一條 uncommitted 的日志條目提交至 leader 節(jié)點(diǎn)。

? 在下一個(gè) heartbeat，leader 將此條目復(fù)制給所有的 follower。

? 當(dāng)大多數(shù)節(jié)點(diǎn)記錄此條目之后，leader 節(jié)點(diǎn)認(rèn)定此條目有效，將此條目設(shè)定為已提交并存儲(chǔ)于本地磁盤。

? 在下一個(gè) heartbeat，leader 通知所有 follower 提交這一日志條目并存儲(chǔ)于各自的磁盤內(nèi)。

3.4.2. 容錯(cuò)

如果由于網(wǎng)絡(luò)的隔斷，造成集群中多數(shù)的節(jié)點(diǎn)在一段時(shí)間內(nèi)無(wú)法訪問(wèn)到 leader 節(jié)點(diǎn)。按照 raft 共識(shí)算法，沒有 leader 的那一組集群將會(huì)通過(guò)選舉投票出新的 leader，甚至?xí)趦蓚€(gè)集群內(nèi)產(chǎn)生不一致的日志條目。在集群重新完整連通之后，原來(lái)的 leader 仍會(huì)按照 raft 共識(shí)算法從步進(jìn)數(shù)更高的 leader 同步日志并將自己切換為 follower。

? 集群的理想狀態(tài)。

? 網(wǎng)絡(luò)間隔造成大多數(shù)的節(jié)點(diǎn)無(wú)法訪問(wèn) leader 節(jié)點(diǎn)。

? 新的日志條目添加到 leader 中。

? leader 節(jié)點(diǎn)將此條日志同步至能夠訪問(wèn)到 leader 的節(jié)點(diǎn)。

? follower 確認(rèn)日志被記錄，但是確認(rèn)記錄日志的 follower 數(shù)量沒有超過(guò)集群節(jié)點(diǎn)的半數(shù)，leader 節(jié)點(diǎn)并不將此條日志存檔。

? 在被隔斷的這部分節(jié)點(diǎn)，在 election timeout 之后，followers 中產(chǎn)生 candidate 并發(fā)起選舉。

? 多數(shù)節(jié)點(diǎn)接受投票之后，candidate 成為 leader。

? 一個(gè)日志條目被添加到新的 leader。

? 日志被復(fù)制給新 leader 的 follower。

? 多數(shù)節(jié)點(diǎn)確認(rèn)之后，leader 將日志條目提交并存儲(chǔ)。

? 在下一個(gè) heartbeat，leader 通知 follower 各自提交并保存在本地磁盤。

? 經(jīng)過(guò)一段時(shí)間之后，集群重新連通到一起，集群中出現(xiàn)兩個(gè) leader 并且存在不一致的日志條目。

? 新的 leader 在下一次 heartbeat timeout 時(shí)向所有的節(jié)點(diǎn)發(fā)送一次 heartbeat。

? #1 leader 在收到步進(jìn)數(shù)更高的 #2 leader heartbeat 時(shí)放棄 leader 地位并切換到 follower 狀態(tài)。

? 節(jié)點(diǎn)中所有未存檔的日志條目都將被丟棄。

? 未被復(fù)制的日志條目將會(huì)被同步給所有的 follower。

通過(guò)這種方式，只要集群中有效連接的節(jié)點(diǎn)超過(guò)總數(shù)的一半，集群將一直以這種規(guī)則運(yùn)行下去并始終確保各個(gè)節(jié)點(diǎn)中的數(shù)據(jù)始終一致。

4. 實(shí)現(xiàn)

4.1. etcd 結(jié)構(gòu)

一個(gè) etcd 節(jié)點(diǎn)的核心由三部分組成：

• Raft：raft 狀態(tài)機(jī)是對(duì) raft 共識(shí)算法的實(shí)現(xiàn)
• WAL：raft 日志存儲(chǔ)
• Storage：數(shù)據(jù)的存儲(chǔ)與索引

WAL (Write-ahead logging)，是用于向系統(tǒng)提供原子性和持久性的一系列技術(shù)。在使用 WAL 的系提供中，所有的修改在提交之前都要先寫入 log 文件中。etcd 的 WAL 由日志存儲(chǔ)與快照存儲(chǔ)兩部分組成，其中 Entry 負(fù)責(zé)存儲(chǔ)具體日志的內(nèi)容，而 Snapshot 負(fù)責(zé)在日志內(nèi)容發(fā)生變化的時(shí)候保存 raft 的狀態(tài)。WAL 會(huì)在本地磁盤的一個(gè)指定目錄下分別日志條目與快照內(nèi)容。

4.2. 服務(wù)

4.2.1. Clients

在默認(rèn)設(shè)定下，etcd 通過(guò)主機(jī)的 2379 端口向 Client 提供服務(wù)。如下圖：

每個(gè)主機(jī)上的應(yīng)用程序都可以通過(guò)主機(jī)的 2379 以 HTTP + JSON 的方式向 etcd 讀寫數(shù)據(jù)。寫入的數(shù)據(jù)會(huì)由 etcd 同步到集群的其它節(jié)點(diǎn)中。

4.2.2. Peers

在默認(rèn)設(shè)定下，etcd 通過(guò)主機(jī)的 2380 端口在各個(gè)節(jié)點(diǎn)中同步 raft 狀態(tài)及數(shù)據(jù)。

5. 創(chuàng)建

從方法上來(lái)劃分，創(chuàng)建 etcd 集群的方式分為兩種：Static （通過(guò)制定 peers 的 IP 和端口創(chuàng)建）與 Discovery （通過(guò)一個(gè)發(fā)現(xiàn)服務(wù)創(chuàng)建）。

Static 方式需要預(yù)先知道集群所有節(jié)點(diǎn)的 IP，所以適合小規(guī)模的集群或者搭建一個(gè)臨時(shí)的開發(fā)與測(cè)試環(huán)境。

Discovery 方式不需要預(yù)先了解其他節(jié)點(diǎn)的 IP。啟動(dòng)時(shí) etcd 通過(guò)訪問(wèn)一個(gè) Discovery URL 來(lái)注冊(cè)自己并獲取其他節(jié)點(diǎn)的信息。這種方式通常適合將 etcd 部署在某個(gè)云服務(wù)平臺(tái)或是一個(gè) DHCP 環(huán)境中。其中 Discovery 服務(wù)可以使用 CoreOS 提供的一個(gè)公共地址 https://discovery.etcd.io/new 來(lái)申請(qǐng)一個(gè) token，或者自己搭建一個(gè)這樣的服務(wù)并設(shè)定一個(gè) token。出于安全的考慮，這個(gè) token 應(yīng)該只在集群初始引導(dǎo)時(shí)短暫存在，因?yàn)榧航⒅髮⒉辉傩枰@一地址，而集群中節(jié)點(diǎn)的變更可以通過(guò) etcd 運(yùn)行時(shí)重構(gòu)的能力來(lái)進(jìn)行配置。

6. 運(yùn)行

下面我們嘗試使用 etcd 0.5.0 以 discovery 方式創(chuàng)建一個(gè) CoreOS 集群。當(dāng)然由于 etcd 0.5.0 尚未正式發(fā)布，所以我們目前還無(wú)法從官方渠道獲得打包 etcd 0.5.0 的 CoreOS 鏡像，但是我們可以修改引導(dǎo)文件，在 CoreOS 啟動(dòng)時(shí)將 etcd 0.5.0 下載至系統(tǒng)里進(jìn)行配置并啟動(dòng)。

CoreOS 官方提供了一個(gè)使用 vagrant + virtualbox 項(xiàng)目，供用戶在本地電腦中創(chuàng)建一個(gè)微型 CoreOS 集群。我們可以在這個(gè)項(xiàng)目的基礎(chǔ)上進(jìn)行修改來(lái)實(shí)現(xiàn)我們的需求。

6.1. Clone 項(xiàng)目到本地

git clone  https://github.com/coreos/coreos-vagrant.git cd coreos-vagrant cp config.rb.sample config.rb cp user-data.sample user-data

6.2. 通過(guò) CoreOS 提供的公共 discovery 服務(wù)申請(qǐng) token

curl https://discovery.etcd.io/new?size=3

https://discovery.etcd.io/780456e1317eb2db312b62ba1cb9a4f7

size = 3 表示這個(gè)集群節(jié)點(diǎn)總數(shù)為 3 個(gè)。

6.3. 修改 config.rb 文件

# Size of the CoreOS cluster created by Vagrant $num_instances=3

將啟動(dòng)的 CoreOS 實(shí)例數(shù)量定為 3 個(gè)

6.4. 修改 user-data 文件

6.4.1. 修改 etcd 參數(shù)：

etcd:     discovery: https://discovery.etcd.io/780456e1317eb2db312b62ba1cb9a4f7     advertise-client-urls: http://$public_ipv4:2379     initial-advertise-peer-urls: http://$public_ipv4:2380     listen-client-urls: http://$public_ipv4:2379     listen-peer-urls: http://$public_ipv4:2380 

6.4.2. 修改 etcd 服務(wù)內(nèi)容

- name: etcd.service       command: start       content: |         [Unit]         After=network-online.target         Requires=network-online.target                  [Service]         ExecStartPre=/usr/bin/wget -N -P /opt/bin https://github.com/coreos/etcd/releases/ download/v0.5.0-alpha.3/etcd-v0.5.0-alpha.3-linux-amd64.tar.gz         ExecStartPre=/usr/bin/tar -C /opt/bin -xvf /opt/bin/etcd-v0.5.0-alpha.3-linux-amd64.tar.gz         ExecStartPre=/usr/bin/chmod +x /opt/bin/etcd-v0.5.0-alpha.3-linux-amd64/etcd         ExecStart=/opt/bin/etcd-v0.5.0-alpha.3-linux-amd64/etcd          [Install]         WantedBy=multi-user.target 

修改的部分讓我們重新定制了 etcd 服務(wù)的內(nèi)容。在系統(tǒng)啟動(dòng)時(shí)，先將 etcd 0.5.0 的打包文件下載至指定目錄并在稍后將其啟動(dòng)。

6.4.3. 使用 vagrant 啟動(dòng)集群

vagrant up

稍后 vagrant 將幫助我們?cè)?VirtualBox 中創(chuàng)建三個(gè) CoreOS 實(shí)例。

6.4.4. 登錄到 CoreOS

登錄到其中的一個(gè)節(jié)點(diǎn)

vagrant ssh core-01

查看一下 etcd.service 的狀態(tài)，輸入：

systemctl status etcd.service

不出意外的話，可以看到其狀態(tài)為 active (running)

etcd.service    Loaded: loaded (/etc/systemd/system/etcd.service; disabled)   Drop-In: /run/systemd/system/etcd.service.d            └─20-cloudinit.conf    Active: active (running) since Sun 2014-11-16 13:10:59 UTC; 12min ago   Process: 894 ExecStartPre=/usr/bin/chmod +x /opt/bin/etcd-v0.5.0-alpha.3- linux-amd64/etcd (code=exited, status=0/SUCCESS)   Process: 890 ExecStartPre=/usr/bin/tar -C /opt/bin -xvf /opt/bin/etcd- v0.5.0-alpha.3-linux-amd64.tar.gz (code=exited, status=0/SUCCESS)   Process: 857 ExecStartPre=/usr/bin/wget -N -P /opt/bin  https://github.com/coreos/etcd/releases/download/v0.5.0-alpha.3/etcd-v0.5.0 -alpha.3-linux-amd64.tar.gz (code=exited, status=0/SUCCESS)  Main PID: 896 (etcd)    CGroup: /system.slice/etcd.service            └─896 /opt/bin/etcd-v0.5.0-alpha.3-linux-amd64/etcd 

6.4.5. 通過(guò) etcdctl 查詢集群狀態(tài)

etcdctl 可以幫助我們查詢一下集群中節(jié)點(diǎn)信息，輸入：

/opt/bin/etcd-v0.5.0-alpha.3-linux-amd64/etcdctl --peers 172.17.8.101:2379 member list

啟動(dòng)參數(shù) --peers 172.17.8.101:2379 表示通過(guò)本節(jié)點(diǎn)的 2379 端口訪問(wèn) etcd 接口，用戶可以根據(jù)自己的實(shí)際情況對(duì) IP 地址進(jìn)行修正。

正常情況下可看到如下輸出：

b4f4d25ed56d7a44: name=b74c24773df147e1be8e1e35defaad38 peerURLs= http://172.17.8.101:2380 clientURLs=http://172.17.8.101:2379 b7404cc414e7affa: name=001db0fc02184af5b293e2cb21c86a11 peerURLs= http://172.17.8.102:2380 clientURLs=http://172.17.8.102:2379 f609956c55a6809e: name=2840dc331d224360a097b781c876c9e5 peerURLs= http://172.17.8.103:2380 clientURLs=http://172.17.8.103:2379

這樣，我們就在本地創(chuàng)建了一個(gè)基于 etcd 0.5.0 的 CoreOS 集群。

7. 預(yù)告

作為 CoreOS 及管理工具介紹的第三部分，筆者將向大家介紹 CoreOS 集群的重要管理工具 fleet ，通過(guò) fleet 用戶可以在 CoreOS 實(shí)現(xiàn)簡(jiǎn)單的 Orchestration 功能，敬請(qǐng)期待。