kubernetes之詳解Etcd集群（一）

前言

隨著kubernetes項(xiàng)目的日益火熱，該項(xiàng)目中用到的etcd組件作為一個(gè)高可用強(qiáng)一致性的服務(wù)發(fā)現(xiàn)存儲(chǔ)倉(cāng)庫(kù)，漸漸的被開(kāi)發(fā)人員所關(guān)注。

在云計(jì)算時(shí)代，如何讓服務(wù)快速、透明的接入到計(jì)算集群中，如何讓共享配置信息快速被集群中的所有節(jié)點(diǎn)發(fā)現(xiàn)，如何構(gòu)建一套高可用、安全、易于部署以及快速響應(yīng)的服務(wù)集群成為了需要解決的問(wèn)題。

Etcd為解決這類問(wèn)題帶來(lái)便捷。

官方地址：?https://coreos.com/etcd/

項(xiàng)目地址：?https://github.com/coreos/etcd

Etcd是什么

Etcd是一個(gè)高可用的鍵值存儲(chǔ)系統(tǒng)，主要用于共享配置和服務(wù)發(fā)現(xiàn)，它通過(guò)Raft一致性算法處理日志復(fù)制以保證強(qiáng)一致性，我們可以理解它為一個(gè)高可用強(qiáng)一致性的服務(wù)發(fā)現(xiàn)存儲(chǔ)倉(cāng)庫(kù)。

在kubernetes集群中，etcd主要用于配置共享和服務(wù)發(fā)現(xiàn)

Etcd主要解決的是分布式系統(tǒng)中數(shù)據(jù)一致性的問(wèn)題，而分布式系統(tǒng)中的數(shù)據(jù)分為控制數(shù)據(jù)和應(yīng)用數(shù)據(jù)，etcd處理的數(shù)據(jù)類型為控制數(shù)據(jù)，對(duì)于很少量的應(yīng)用數(shù)據(jù)也可以進(jìn)行處理。

Etcd和Zookeeper的比較

Zookeeper有如下缺點(diǎn)

1.復(fù)雜。ZooKeeper的部署維護(hù)復(fù)雜，管理員需要掌握一系列的知識(shí)和技能；而Paxos強(qiáng)一致性算法也是素來(lái)以復(fù)雜難懂而聞名于世（ETCD使用[Raft]協(xié)議， ZK使用ZAB，類PAXOS協(xié)議）；另外，ZooKeeper的使用也比較復(fù)雜，需要安裝客戶端，官方只提供了Java和C兩種語(yǔ)言的接口。

2.Java編寫。這里不是對(duì)Java有偏見(jiàn)，而是Java本身就偏向于重型應(yīng)用，它會(huì)引入大量的依賴。而運(yùn)維人員則普遍希望保持強(qiáng)一致、高可用的機(jī)器集群盡可能簡(jiǎn)單，維護(hù)起來(lái)也不易出錯(cuò)。

3.發(fā)展緩慢。Apache基金會(huì)項(xiàng)目特有的“Apache Way”在開(kāi)源界飽受爭(zhēng)議，其中一大原因就是由于基金會(huì)龐大的結(jié)構(gòu)以及松散的管理導(dǎo)致項(xiàng)目發(fā)展緩慢。

相較之下，Etcd

1.簡(jiǎn)單。使用Go語(yǔ)言編寫部署簡(jiǎn)單；使用HTTP作為接口使用簡(jiǎn)單；使用Raft算法保證強(qiáng)一致性讓用戶易于理解。

2.數(shù)據(jù)持久化。etcd默認(rèn)數(shù)據(jù)一更新就進(jìn)行持久化。

3.安全。etcd支持SSL客戶端安全認(rèn)證。

Etcd的架構(gòu)與術(shù)語(yǔ)

流程分析

通常一個(gè)用戶的請(qǐng)求發(fā)送過(guò)來(lái)，會(huì)經(jīng)過(guò)HTTP Server轉(zhuǎn)發(fā)給Store進(jìn)行具體的事務(wù)處理，如果涉及到節(jié)點(diǎn)的修改，則需要交給Raft模塊進(jìn)行狀態(tài)的變更，日志的記錄。

然后再同步給別的etcd節(jié)點(diǎn)確認(rèn)數(shù)據(jù)提交，最后進(jìn)行數(shù)據(jù)提交，再次同步。

工作原理

Etcd使用Raft協(xié)議來(lái)維護(hù)集群內(nèi)各個(gè)節(jié)點(diǎn)狀態(tài)的一致性。簡(jiǎn)單說(shuō)，ETCD集群是一個(gè)分布式系統(tǒng)，由多個(gè)節(jié)點(diǎn)相互通信構(gòu)成整體對(duì)外服務(wù)，每個(gè)節(jié)點(diǎn)都存儲(chǔ)了完整的數(shù)據(jù)，并且通過(guò)Raft協(xié)議保證每個(gè)節(jié)點(diǎn)維護(hù)的數(shù)據(jù)是一致的。

Etcd主要分為四個(gè)部分

HTTP Server： 用于處理用戶發(fā)送的API請(qǐng)求以及其他etcd節(jié)點(diǎn)的同步與心跳信息請(qǐng)求

Store:??用于處理 etcd 支持的各類功能的事務(wù)，包括數(shù)據(jù)索引、節(jié)點(diǎn)狀態(tài)變更、監(jiān)控與反饋、事件處理與執(zhí)行等等，是 etcd 對(duì)用戶提供的大多數(shù) API 功能的具體實(shí)現(xiàn)。

Raft： Raft 強(qiáng)一致性算法的具體實(shí)現(xiàn)，是 etcd 的核心。

WAL：Write Ahead Log（預(yù)寫式日志/日志先行），是 etcd 的數(shù)據(jù)存儲(chǔ)方式，也是一種實(shí)現(xiàn)事務(wù)日志的標(biāo)準(zhǔn)方法。etcd通過(guò) WAL 進(jìn)行持久化存儲(chǔ)，所有的數(shù)據(jù)提交前都會(huì)事先記錄日志。Snapshot 是為了防止數(shù)據(jù)過(guò)多而進(jìn)行的狀態(tài)快照；Entry 表示存儲(chǔ)的具體日志內(nèi)容。

服務(wù)發(fā)現(xiàn)

服務(wù)發(fā)現(xiàn)要解決的也是分布式系統(tǒng)中最常見(jiàn)的問(wèn)題之一，即在同一個(gè)分布式集群中的進(jìn)程或服務(wù)，要如何才能找到對(duì)方并建立連接。本質(zhì)上來(lái)說(shuō)，服務(wù)發(fā)現(xiàn)就是想要了解集群中是否有進(jìn)程在監(jiān)聽(tīng) udp 或 tcp 端口，并且通過(guò)名字就可以查找和連接。要解決服務(wù)發(fā)現(xiàn)的問(wèn)題，需要具備以下三點(diǎn)：

1.一個(gè)強(qiáng)一致性、高可用的服務(wù)存儲(chǔ)目錄。基于 Raft 算法的 etcd 天生就是這樣一個(gè)強(qiáng)一致性高可用的服務(wù)存儲(chǔ)目錄。

2.一種注冊(cè)服務(wù)和監(jiān)控服務(wù)健康狀態(tài)的機(jī)制。用戶可以在 etcd 中注冊(cè)服務(wù)，并且對(duì)注冊(cè)的服務(wù)設(shè)置key TTL，定時(shí)保持服務(wù)的心跳以達(dá)到監(jiān)控健康狀態(tài)的效果。

3.一種查找和連接服務(wù)的機(jī)制。通過(guò)在 etcd 指定的主題下注冊(cè)的服務(wù)也能在對(duì)應(yīng)的主題下查找到。為了確保連接，我們可以在每個(gè)服務(wù)機(jī)器上都部署一個(gè) Proxy 模式的 etcd，這樣就可以確保能訪問(wèn) etcd 集群的服務(wù)都能互相連接。

例如隨著 Docker 容器的流行，多種微服務(wù)共同協(xié)作，構(gòu)成一個(gè)相對(duì)功能強(qiáng)大的架構(gòu)的案例越來(lái)越多。透明化的動(dòng)態(tài)添加這些服務(wù)的需求也日益強(qiáng)烈。通過(guò)服務(wù)發(fā)現(xiàn)機(jī)制，在 etcd 中注冊(cè)某個(gè)服務(wù)名字的目錄，在該目錄下存儲(chǔ)可用的服務(wù)節(jié)點(diǎn)的 IP。在使用服務(wù)的過(guò)程中，只要從服務(wù)目錄下查找可用的服務(wù)節(jié)點(diǎn)去使用即可。

Etcd集群中的術(shù)語(yǔ)

Raft: etcd所采用的保證分布式系統(tǒng)強(qiáng)一致的算法

Node: 一個(gè)Raft狀態(tài)機(jī)實(shí)例

Member: 一個(gè)etcd實(shí)例,管理一個(gè)Node，可以為客戶端請(qǐng)求提供服務(wù)

Cluster: 多個(gè)Member構(gòu)成的可以協(xié)同工作的etcd集群

Peer: 同一個(gè)集群中，其他Member的稱呼

Client: 向etcd集群發(fā)送HTTP請(qǐng)求的客戶端

WAL: 預(yù)寫日志，是etcd用于持久化存儲(chǔ)的日志格式

Snapshot: etcd防止WAL文件過(guò)多而設(shè)置的快照，存儲(chǔ)etcd數(shù)據(jù)狀態(tài)

Proxy: etcd的一種模式，可以為etcd提供反向代理服務(wù)

Leader: Raft算法中通過(guò)競(jìng)選而產(chǎn)生的處理所有數(shù)據(jù)提交的節(jié)點(diǎn)

Follower: Raft算法中競(jìng)選失敗的節(jié)點(diǎn)，作為從屬節(jié)點(diǎn)，為算法提供強(qiáng)一致性保證

Candidate: Follower超過(guò)一定時(shí)間接收不到Leader節(jié)點(diǎn)的心跳的時(shí)候，會(huì)轉(zhuǎn)變?yōu)镃andidate(候選者)開(kāi)始Leader競(jìng)選

Term: 某個(gè)節(jié)點(diǎn)稱為L(zhǎng)eader到下一次競(jìng)選開(kāi)始的時(shí)間周期,稱為Term(任界，任期)

Index: 數(shù)據(jù)項(xiàng)編號(hào), Raft中通過(guò)Term和Index來(lái)定位數(shù)據(jù)

Raft算法

Raft 是一種為了管理復(fù)制日志的一致性算法。它提供了和 Paxos 算法相同的功能和性能，但是它的算法結(jié)構(gòu)和 Paxos 不同，使得 Raft 算法更加容易理解并且更容易構(gòu)建實(shí)際的系統(tǒng)。一致性算法允許一組機(jī)器像一個(gè)整體一樣工作，即使其中一些機(jī)器出現(xiàn)故障也能夠繼續(xù)工作下去。正因?yàn)槿绱耍恢滦运惴ㄔ跇?gòu)建可信賴的大規(guī)模軟件系統(tǒng)中扮演著重要的角色。

Raft算法分為三部分

Leader選舉、日志復(fù)制和安全性

Raft算法特性：

1.強(qiáng)領(lǐng)導(dǎo)者: 和其他一致性算法相比，Raft 使用一種更強(qiáng)的領(lǐng)導(dǎo)能力形式。比如，日志條目只從領(lǐng)導(dǎo)者發(fā)送給其他的服務(wù)器。這種方式簡(jiǎn)化了對(duì)復(fù)制日志的管理并且使得 Raft 算法更加易于理解。

2.領(lǐng)導(dǎo)選舉： Raft 算法使用一個(gè)隨機(jī)計(jì)時(shí)器來(lái)選舉領(lǐng)導(dǎo)者。這種方式只是在任何一致性算法都必須實(shí)現(xiàn)的心跳機(jī)制上增加了一點(diǎn)機(jī)制。在解決沖突的時(shí)候會(huì)更加簡(jiǎn)單快捷。

3.成員關(guān)系調(diào)整： Raft 使用一種共同一致的方法來(lái)處理集群成員變換的問(wèn)題，在這種方法下，處于調(diào)整過(guò)程中的兩種不同的配置集群中大多數(shù)機(jī)器會(huì)有重疊，這就使得集群在成員變換的時(shí)候依然可以繼續(xù)工作。

Leader選舉

Raft 狀態(tài)機(jī)

Raft集群中的每個(gè)節(jié)點(diǎn)都處于一種基于角色的狀態(tài)機(jī)中。具體來(lái)說(shuō)，Raft定義了節(jié)點(diǎn)的三種角色： Follower、Candidate和Leader。

1.Leader(領(lǐng)導(dǎo)者):?Leader節(jié)點(diǎn)在集群中有且僅能有一個(gè)，它負(fù)責(zé)向所有的Follower節(jié)點(diǎn)同步日志數(shù)據(jù)

2.Follower(跟隨者): Follower節(jié)點(diǎn)從Leader節(jié)點(diǎn)獲取日志，提供數(shù)據(jù)查詢功能，并將所有修改請(qǐng)求轉(zhuǎn)發(fā)給Leader節(jié)點(diǎn)

3.Candidate(候選者): 當(dāng)集群中的Leader節(jié)點(diǎn)不存在或者失聯(lián)之后，其他Follower節(jié)點(diǎn)轉(zhuǎn)換為Candidate，然后開(kāi)始新的Leader節(jié)點(diǎn)選舉

這三種角色狀態(tài)之間的轉(zhuǎn)換，如下圖：

一個(gè) Raft 集群包含若干個(gè)服務(wù)器節(jié)點(diǎn)；通常是 5 個(gè)，這允許整個(gè)系統(tǒng)容忍 2 個(gè)節(jié)點(diǎn)的失效。在任何時(shí)刻，每一個(gè)服務(wù)器節(jié)點(diǎn)都處于這三個(gè)狀態(tài)之一：領(lǐng)導(dǎo)人、跟隨者或者候選人。在通常情況下，系統(tǒng)中只有一個(gè)領(lǐng)導(dǎo)人并且其他的節(jié)點(diǎn)全部都是跟隨者。跟隨者都是被動(dòng)的：他們不會(huì)發(fā)送任何請(qǐng)求，只是簡(jiǎn)單的響應(yīng)來(lái)自領(lǐng)導(dǎo)者或者候選人的請(qǐng)求。領(lǐng)導(dǎo)人處理所有的客戶端請(qǐng)求（如果一個(gè)客戶端和跟隨者聯(lián)系，那么跟隨者會(huì)把請(qǐng)求重定向給領(lǐng)導(dǎo)人）

在節(jié)點(diǎn)初始啟動(dòng)的時(shí)候，所有節(jié)點(diǎn)的Raft狀態(tài)機(jī)都會(huì)處于Follower狀態(tài)。當(dāng)Follower在一定的時(shí)間周期內(nèi)沒(méi)有收到來(lái)自Leader節(jié)點(diǎn)的心跳數(shù)據(jù)包的時(shí)候，節(jié)點(diǎn)會(huì)將自己的狀態(tài)切換為Candidate，并向集群中其他Follower節(jié)點(diǎn)發(fā)送投票請(qǐng)求，F(xiàn)ollower都會(huì)將自己的票投給收到的第一個(gè)投票請(qǐng)求節(jié)點(diǎn)。當(dāng)Candidate收到來(lái)自集群中超過(guò)半數(shù)節(jié)點(diǎn)的投票后，會(huì)成為新的Leader節(jié)點(diǎn)。

Leader節(jié)點(diǎn)將接受并保存用戶發(fā)送的數(shù)據(jù)，并向其他的Follower節(jié)點(diǎn)同步日志。

Follower只響應(yīng)來(lái)自其他服務(wù)器的請(qǐng)求。如果Follower接收不到消息，那么他就會(huì)變成候選人并發(fā)起一次選舉。獲得集群中大多數(shù)選票的候選人將成為L(zhǎng)eader。在一個(gè)任期(Term)內(nèi),領(lǐng)導(dǎo)人一直都會(huì)是領(lǐng)導(dǎo)人直到自己宕機(jī)了。

Leader節(jié)點(diǎn)依靠定時(shí)向所有Follower發(fā)送心跳數(shù)據(jù)來(lái)保持地位。當(dāng)急群眾的Leader節(jié)點(diǎn)出現(xiàn)故障的時(shí)候，F(xiàn)ollower會(huì)重新選舉新的節(jié)點(diǎn)，保證整個(gè)集群正常運(yùn)行。

每次成功的選舉，新的Leader的Term（任期）值都會(huì)比之前的Leader增加1。當(dāng)集群中由于網(wǎng)絡(luò)或者其他原因出現(xiàn)分裂后又重新合并的時(shí)候，集群中可能會(huì)出現(xiàn)多于一個(gè)的Leader節(jié)點(diǎn)，此時(shí)，Term值更高的節(jié)點(diǎn)才會(huì)成為真正的Leader。

Raft算法中的Term（任期）

關(guān)于Term，如下圖：

Raft會(huì)把時(shí)間分割成任意長(zhǎng)度的任期。并且任期用連續(xù)的整數(shù)來(lái)標(biāo)記。每一段任期都是從一次選舉開(kāi)始，一個(gè)或者多個(gè)候選人嘗試成為領(lǐng)導(dǎo)者。如果一個(gè)候選人贏得選舉，然后他就會(huì)在接下來(lái)的任期中充當(dāng)Leader的職責(zé)。在某些情況下，一次選舉會(huì)造成選票瓜分，這樣，這一個(gè)任期將沒(méi)有Leader。如果沒(méi)有Leader，那么新的一輪選舉就馬上開(kāi)始，也就是新的任期就會(huì)開(kāi)始。Raft保證了在一個(gè)Term任期內(nèi)，有且只有一個(gè)Leader。

日志復(fù)制

所謂日志復(fù)制，是指主節(jié)點(diǎn)將每次操作形成日志條目，并持久化到本地磁盤，然后通過(guò)網(wǎng)絡(luò)IO發(fā)送給其他節(jié)點(diǎn)。

一旦一個(gè)領(lǐng)導(dǎo)人被選舉出來(lái)，他就開(kāi)始為客戶端提供服務(wù)。客戶端的每一個(gè)請(qǐng)求都包含一條被復(fù)制狀態(tài)機(jī)執(zhí)行的指令。領(lǐng)導(dǎo)人把這條指令作為一條新的日志條目附加到日志中去，然后并行的發(fā)起附加條目 RPCs 給其他的服務(wù)器，讓他們復(fù)制這條日志條目。

Raft 算法保證所有已提交的日志條目都是持久化的并且最終會(huì)被所有可用的狀態(tài)機(jī)執(zhí)行。當(dāng)主節(jié)點(diǎn)收到包括自己在內(nèi)超過(guò)半數(shù)節(jié)點(diǎn)成功返回，那么認(rèn)為該日志是可提交的(committed），并將日志輸入到狀態(tài)機(jī)，將結(jié)果返回給客戶端。

在正常的操作中，領(lǐng)導(dǎo)人和跟隨者的日志保持一致性，所以附加日志 RPC 的一致性檢查從來(lái)不會(huì)失敗。然而，領(lǐng)導(dǎo)人崩潰的情況會(huì)使得日志處于不一致的狀態(tài)（老的領(lǐng)導(dǎo)人可能還沒(méi)有完全復(fù)制所有的日志條目）。這種不一致問(wèn)題會(huì)在一系列的領(lǐng)導(dǎo)人和跟隨者崩潰的情況下加劇。跟隨者的日志可能和新的領(lǐng)導(dǎo)人不同的方式。跟隨者可能會(huì)丟失一些在新的領(lǐng)導(dǎo)人中有的日志條目，他也可能擁有一些領(lǐng)導(dǎo)人沒(méi)有的日志條目，或者兩者都發(fā)生。丟失或者多出日志條目可能會(huì)持續(xù)多個(gè)任期。這就引出了另一個(gè)部分，就是安全性

安全性

截止此刻，選主以及日志復(fù)制并不能保證節(jié)點(diǎn)間數(shù)據(jù)一致。試想，當(dāng)一個(gè)某個(gè)節(jié)點(diǎn)掛掉了，一段時(shí)間后再次重啟，并當(dāng)選為主節(jié)點(diǎn)。而在其掛掉這段時(shí)間內(nèi)，集群若有超過(guò)半數(shù)節(jié)點(diǎn)存活，集群會(huì)正常工作，那么會(huì)有日志提交。這些提交的日志無(wú)法傳遞給掛掉的節(jié)點(diǎn)。當(dāng)掛掉的節(jié)點(diǎn)再次當(dāng)選主節(jié)點(diǎn)，它將缺失部分已提交的日志。在這樣場(chǎng)景下，按Raft協(xié)議，它將自己日志復(fù)制給其他節(jié)點(diǎn)，會(huì)將集群已經(jīng)提交的日志給覆蓋掉。這顯然是錯(cuò)誤的

其他協(xié)議解決這個(gè)問(wèn)題的辦法是，新當(dāng)選的主節(jié)點(diǎn)會(huì)詢問(wèn)其他節(jié)點(diǎn)，和自己數(shù)據(jù)對(duì)比，確定出集群已提交數(shù)據(jù)，然后將缺失的數(shù)據(jù)同步過(guò)來(lái)。這個(gè)方案有明顯缺陷，增加了集群恢復(fù)服務(wù)的時(shí)間（集群在選舉階段不可服務(wù)），并且增加了協(xié)議的復(fù)雜度。Raft解決的辦法是，在選主邏輯中，對(duì)能夠成為主的節(jié)點(diǎn)加以限制，確保選出的節(jié)點(diǎn)已定包含了集群已經(jīng)提交的所有日志。如果新選出的主節(jié)點(diǎn)已經(jīng)包含了集群所有提交的日志，那就不需要從和其他節(jié)點(diǎn)比對(duì)數(shù)據(jù)了。簡(jiǎn)化了流程，縮短了集群恢復(fù)服務(wù)的時(shí)間。

這里存在一個(gè)問(wèn)題，加以這樣限制之后，還能否選出主呢？答案是：只要仍然有超過(guò)半數(shù)節(jié)點(diǎn)存活，這樣的主一定能夠選出。因?yàn)橐呀?jīng)提交的日志必然被集群中超過(guò)半數(shù)節(jié)點(diǎn)持久化，顯然前一個(gè)主節(jié)點(diǎn)提交的最后一條日志也被集群中大部分節(jié)點(diǎn)持久化。當(dāng)主節(jié)點(diǎn)掛掉后，集群中仍有大部分節(jié)點(diǎn)存活，那這存活的節(jié)點(diǎn)中一定存在一個(gè)節(jié)點(diǎn)包含了已經(jīng)提交的日志了。

Etcd的代理節(jié)點(diǎn)（proxy）

Etcd針對(duì)Raft的角色模型進(jìn)行了擴(kuò)展，增加了Proxy角色。proxy模式的本職就是啟一個(gè)HTTP代理服務(wù)器，把客戶發(fā)到這個(gè)服務(wù)器的請(qǐng)求轉(zhuǎn)發(fā)給別的 etcd 節(jié)點(diǎn)。

作為Proxy角色的節(jié)點(diǎn)不會(huì)參與Leader的選舉，只是將所有接收到的用戶查詢和修改請(qǐng)求轉(zhuǎn)發(fā)到任意一個(gè)Follower或者Leader節(jié)點(diǎn)上。

Proxy節(jié)點(diǎn)可以在啟動(dòng)Etcd的時(shí)候通過(guò)"--proxy on"參數(shù)指定。在使用了"節(jié)點(diǎn)自發(fā)現(xiàn)"服務(wù)的集群中，可以設(shè)置一個(gè)固定的"參選節(jié)點(diǎn)數(shù)目"，超過(guò)這個(gè)數(shù)目的成員自動(dòng)轉(zhuǎn)換為Proxy節(jié)點(diǎn)。

一旦節(jié)點(diǎn)成為Proxy之后，便不再參與所有Leader選舉和Raft狀態(tài)變化。除非將這個(gè)節(jié)點(diǎn)重啟并指定為成員的Follower節(jié)點(diǎn)

etcd 作為一個(gè)反向代理把客戶的請(qǐng)求轉(zhuǎn)發(fā)給可用的 etcd 集群。這樣，你就可以在每一臺(tái)機(jī)器都部署一個(gè) Proxy 模式的 etcd 作為本地服務(wù)，如果這些 etcd Proxy 都能正常運(yùn)行，那么你的服務(wù)發(fā)現(xiàn)必然是穩(wěn)定可靠的。

完整的Etcd角色狀態(tài)轉(zhuǎn)換過(guò)程如下圖：

kubernetes項(xiàng)目中，Etcd用來(lái)做什么，為什么選擇它

etcd在kubernetes集群是用來(lái)存放數(shù)據(jù)并通知變動(dòng)的。

Kubernetes中沒(méi)有用到數(shù)據(jù)庫(kù)，它把關(guān)鍵數(shù)據(jù)都存放在etcd中，這使kubernetes的整體結(jié)構(gòu)變得非常簡(jiǎn)單。

在kubernetes中，數(shù)據(jù)是隨時(shí)發(fā)生變化的，比如說(shuō)用戶提交了新任務(wù)、增加了新的Node、Node宕機(jī)了、容器死掉了等等，都會(huì)觸發(fā)狀態(tài)數(shù)據(jù)的變更。狀態(tài)數(shù)據(jù)變更之后呢，Master上的kube-scheduler和kube-controller-manager，就會(huì)重新安排工作，它們的工作安排結(jié)果也是數(shù)據(jù)。這些變化，都需要及時(shí)地通知給每一個(gè)組件。etcd有一個(gè)特別好用的特性，可以調(diào)用它的api監(jiān)聽(tīng)其中的數(shù)據(jù)，一旦數(shù)據(jù)發(fā)生變化了，就會(huì)收到通知。有了這個(gè)特性之后，kubernetes中的每個(gè)組件只需要監(jiān)聽(tīng)etcd中數(shù)據(jù)，就可以知道自己應(yīng)該做什么。kube-scheduler和kube-controller-manager呢，也只需要把最新的工作安排寫入到etcd中就可以了，不用自己費(fèi)心去逐個(gè)通知了

試想一下，如果沒(méi)有etcd，那么要怎樣做？這里的本質(zhì)是：數(shù)據(jù)的傳遞有兩種方式，一種是消息的方式，比如說(shuō)NodeA有了新的任務(wù)，Master直接給NodeA發(fā)一個(gè)消息，中間不經(jīng)過(guò)任何人；一種是輪詢的方式，大家都把數(shù)據(jù)寫到同一個(gè)地方，每個(gè)人自覺(jué)地盯著看，及時(shí)發(fā)現(xiàn)變化。前者演化出rabbitmq這樣的消息隊(duì)列系統(tǒng)，后者演化出一些有訂閱功能的分布式系統(tǒng)。

第一種方式的問(wèn)題是，所有要通信的組件之間都要建立長(zhǎng)連接，并且要處理各種異常情況，比例如連接斷開(kāi)、數(shù)據(jù)發(fā)送失敗等。不過(guò)有了消息隊(duì)列(message queue)這樣的中間件之后，問(wèn)題就簡(jiǎn)單多了，組件都和mq建立連接即可，將各種異常情況都在mq中處理。

那么為什么kubernetes沒(méi)有選用mq而是選用etcd呢？mq和etcd是本質(zhì)上完全不同的系統(tǒng)，mq的作用消息傳遞，不儲(chǔ)存數(shù)據(jù)（消息積壓不算儲(chǔ)存，因?yàn)闆](méi)有查詢的功能），etcd是個(gè)分布式存儲(chǔ)（它的設(shè)計(jì)目標(biāo)是分布式鎖，順帶有了存儲(chǔ)功能），是一個(gè)帶有訂閱功能的key-value存儲(chǔ)。如果使用mq，那么還需要引入數(shù)據(jù)庫(kù)，在數(shù)據(jù)庫(kù)中存放狀態(tài)數(shù)據(jù)。

選擇etcd還有一個(gè)好處，etcd使用raft協(xié)議實(shí)現(xiàn)一致性，它是一個(gè)分布式鎖，可以用來(lái)做選舉。如果在kubernetes中部署了多個(gè)kube-schdeuler，那么同一時(shí)刻只能有一個(gè)kube-scheduler在工作，否則各自安排各自的工作，就亂套了。怎樣保證只有一個(gè)kube-schduler在工作呢？那就是前文說(shuō)到的通過(guò)etcd選舉出一個(gè)leader。

Kubernates

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。