1似踱、描述zookeeper集群中l(wèi)eader，follower墓臭，observer幾種角色
Zookeeper：
分布式系統(tǒng)：是一個(gè)硬件或軟件組件分布在網(wǎng)絡(luò)中的不同的計(jì)算機(jī)之上蘸鲸，彼此間僅通過消息傳遞進(jìn)行通信和協(xié)作的系統(tǒng)。
特征：
分布性起便、對等性棚贾、并發(fā)性窖维、缺乏全局時(shí)鐘、故障必然會(huì)發(fā)生
典型問題：
通信異常妙痹、網(wǎng)絡(luò)分區(qū)铸史、三態(tài)(成功、失敗怯伊、超時(shí))琳轿、節(jié)點(diǎn)故障
zookeeper是一個(gè)開源的分面式協(xié)調(diào)服務(wù)，由知名互聯(lián)網(wǎng)公司Yahoo創(chuàng)建耿芹，它是Chubby的開源實(shí)現(xiàn)崭篡；換句話講，zk是一個(gè)典型的分布式數(shù)據(jù)一致性解決方案吧秕，分布式應(yīng)用程序可以基于它實(shí)現(xiàn)數(shù)據(jù)的發(fā)布/訂閱琉闪、負(fù)載均衡、名稱服務(wù)砸彬、分布式協(xié)調(diào)/通知颠毙、集群管理、Master選舉砂碉、分布式鎖和分布式隊(duì)列蛀蜜；
基本概念：
集群角色：Leader, Follower, Observer
Leader：選舉產(chǎn)生，讀/寫增蹭；
Follower：參與選舉滴某，可被選舉，讀服務(wù)滋迈；
Observer：參與選舉霎奢，不可被選舉，提供讀服務(wù)杀怠；
會(huì)話：ZK中椰憋，客戶端<-->服務(wù)端，TCP長連接赔退；
sessionTimeout
數(shù)據(jù)節(jié)點(diǎn)(ZNode)：即zk數(shù)據(jù)模型中的數(shù)據(jù)單元；zk的數(shù)據(jù)都存儲(chǔ)于內(nèi)存中证舟，數(shù)據(jù)模型為樹狀結(jié)構(gòu)(ZNode Tree)硕旗；每個(gè)ZNode都會(huì)保存自己的數(shù)據(jù)于內(nèi)存中；
持久節(jié)點(diǎn)：僅顯式刪除才消失
臨時(shí)節(jié)點(diǎn)：會(huì)話中止即自動(dòng)消失
版本（version）：ZK會(huì)為每個(gè)ZNode維護(hù)一個(gè)稱之為Stat的數(shù)據(jù)結(jié)構(gòu)女责，記錄了當(dāng)前ZNode的三個(gè)數(shù)據(jù)版本
version：當(dāng)前版本
cversion：當(dāng)前znode的子節(jié)點(diǎn)的版本
aversion：當(dāng)前znode的ACL的版本
ACL：ZK使用ACL機(jī)制進(jìn)行權(quán)限控制
CREATE漆枚， READ，WRITE抵知，DELETE墙基，ADMIN
事件監(jiān)聽器(Watcher)：
ZK上软族，由用戶指定的觸發(fā)機(jī)制，在某些事件產(chǎn)生時(shí)残制，ZK能夠?qū)⑼ㄖo相關(guān)的客戶端立砸；
ZAB協(xié)議：Zookeeper Atomic Broadcast，ZK原子廣播協(xié)議初茶；
ZAB協(xié)議中存在三種狀態(tài)：
(1) Looking,
(2) Following颗祝，
(3) Leading
四個(gè)階段：
選舉:election
發(fā)現(xiàn)：discovery
同步：sync
廣播：Broadcast
2、完成zookeeper分布式集群的搭建
安裝：
wget?http://mirrors.tuna.tsinghua.edu.cn/apache/zookeeper/
部署方式：單機(jī)模式恼布、偽分布式模式螺戳、分布式模式
http://zookeeper.apache.org
zoo.cfg配置參數(shù)：
tickTime=2000 #心跳檢測時(shí)間2秒
dataDir=/data/zookeeper #數(shù)據(jù)目錄
ClientPort=2181#監(jiān)聽端口
initLimit=5#初始同步階段經(jīng)過多少個(gè)tick時(shí)長
syncLimit=2#請求信息經(jīng)過多少個(gè)tick時(shí)長
指定主機(jī)的語法格式：
server.ID=IP:port:port
ID：各主機(jī)的數(shù)字標(biāo)識(shí)，一般從1開始
IP:各主機(jī)的IP
節(jié)點(diǎn)信息：stat
cZxid = 0x14 #表示節(jié)點(diǎn)由那個(gè)事務(wù)創(chuàng)建的
ctime = Wed Sep 14 16:12:44 CST 2016
mZxid = 0x14 #最近更新事務(wù)節(jié)點(diǎn)的id
mtime = Wed Sep 14 16:12:44 CST 2016
pZxid = 0x14
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 8
numChildren = 0
Client：
Watcher, 一次性地觸發(fā)通知機(jī)制折汞；
mv zoo_sample.cfg zoo.cfg #修改配置文件名
./zkServer.sh start #啟動(dòng)zk
zkCli.sh 連接zk
zkCli命令：
create, ls, ls2, stat, delete, rmr, get, set, ...
監(jiān)控zk的四字命令：
ruok, stat, srvr, conf, cons, wchs, envi ...
zoo.cfg配置文件的參數(shù)：
基本配置參數(shù)：
clientPort=2181
dataDir=/data/zookeeper
dataLogDir：事務(wù)日志文件路徑吹菱；
tickTime：
存儲(chǔ)配置：
preAllocSize：為事務(wù)日志預(yù)先分配的磁盤空間量；默認(rèn)65535KB钉凌；
snapCount：每多少次事務(wù)后執(zhí)行一次快照操作惋增；每事務(wù)的平均大小在100字節(jié)；
autopurget.snapRetainCount：
autopurge.purgeInterval：purge操作的時(shí)間間隔堕伪，0表示不啟動(dòng)揖庄；
fsync.warningthresholdms：zk進(jìn)行事務(wù)日志fsync操作時(shí)消耗的時(shí)長報(bào)警閾值；
weight.X=N：判斷quorum時(shí)投票權(quán)限欠雌，默認(rèn)1蹄梢；
網(wǎng)絡(luò)配置：
maxClientCnxns：每客戶端IP的最大并發(fā)連接數(shù)；
clientPortAddress：zk監(jiān)聽IP地址富俄；
minSessionTimeout：
maxSessionTimeout：
集群配置：
initLimit：Follower連入Leader并完成數(shù)據(jù)同步的時(shí)長禁炒；
syncLimit：心跳檢測的最大延遲；
leaderServes：默認(rèn)zk的leader接收讀寫請求霍比，額外還要負(fù)責(zé)協(xié)調(diào)各Follower發(fā)來的事務(wù)等幕袱；因此，為使得leader集中處理zk集群內(nèi)部信息悠瞬，建議不讓leader直接提供服務(wù)们豌；
cnxTimeout：Leader選舉期間，各服務(wù)器創(chuàng)建TCP連接的超時(shí)時(shí)長浅妆；
ellectionAlg：選舉算法望迎，目前僅支持FastLeaderElection算法一種；
server.id=[hostname]:port:port[:observer]
集群內(nèi)各服務(wù)器的屬性參數(shù)
第一個(gè)port：follower與leader進(jìn)行通信和數(shù)據(jù)同步時(shí)所使用端口凌外；
第二個(gè)port：leader選舉時(shí)使用的端口辩尊；
observer：定義指定的服務(wù)器為observer；
注意：運(yùn)行為集群模式時(shí)康辑，每個(gè)節(jié)點(diǎn)在其數(shù)據(jù)目錄中應(yīng)該有一個(gè)myid文件摄欲，其內(nèi)容僅為當(dāng)前server的id轿亮；
典型應(yīng)用場景：
數(shù)據(jù)發(fā)布/訂閱
負(fù)載均衡
命名服務(wù)
分布式協(xié)調(diào)/通知
集群管理
Master選舉
集群工作模式
在三臺(tái)主機(jī)中安裝jdk，解壓zk包胸墙，創(chuàng)建數(shù)據(jù)目錄我注。
tar -xf zookeeper-3.4.14.tar.gz -C /usr/local
?cd /usr/local/
?ln -s zookeeper-3.4.14/ ./zookeeper
?mkdir /data/zookeeper
修改配置文件，拷貝至其他節(jié)點(diǎn)
#因?yàn)閦k識(shí)別不了主節(jié)點(diǎn)劳秋。需要?jiǎng)?chuàng)建id文件
echo 1 > /data/zookeeper/myid?
echo 2 > /data/zookeeper/myid
echo 3 > /data/zookeeper/myid
/usr/local/zookeeper/bin/zkServer.sh start #啟動(dòng)各節(jié)點(diǎn)
3仓手、總結(jié)kubernetes幾個(gè)重要組件以及組件的作用
Kubernetes主要組件有：kubectl (客戶端)
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?API Server、Controller Manager玻淑、Scheduler嗽冒、Etcd (Master節(jié)點(diǎn)) ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?kubelet、kube-proxy (Slave Node節(jié)點(diǎn))
API Server
API Server是Kubernetes的核心組件补履，是各個(gè)組件通信的渠道添坊，
API Server集群控制的入口，提供了 RESTful API?接口的關(guān)鍵服務(wù)進(jìn)程箫锤，是 Kubernetes 里所有資源的增刪改查等操作的唯一入口贬蛙。創(chuàng)建一個(gè)資源對象如Deployment、Service谚攒、RC阳准、ConfigMap等，都是要通過API Server的馏臭。
操作API Server的方式：1野蝇，通過命令行的kubectl命令，
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?2括儒，通過寫代碼的方式绕沈，如client-go這樣的操作Kubernetes的第三方包來操作集群。
總之帮寻，最終乍狐，都是通過API Server對集群進(jìn)行操作的。通過API Server固逗，我們就可以往Etcd中寫入數(shù)據(jù)浅蚪。Etcd中存儲(chǔ)著集群的各種數(shù)據(jù)。
如下圖：存儲(chǔ)Kubernetes集群信息的Etcd
資源配額控制的入口
Kubernetes可以從各個(gè)層級(jí)對資源進(jìn)行配額控制抒蚜。如容器的CPU使用量掘鄙、Pod的CPU使用量、namespace的資源數(shù)量等嗡髓。這也是通過API Server進(jìn)行配置的。將這些資源配額情況寫入到Etcd中收津。
Controller Manager
Controller Manager作用是通過API Server監(jiān)控Etcd中的節(jié)點(diǎn)信息饿这，定時(shí)通過API Server讀取Etcd中的節(jié)點(diǎn)信息浊伙，監(jiān)控到異常就會(huì)自動(dòng)進(jìn)行某種操作。
Node Controller通過API Server監(jiān)控Etcd中存儲(chǔ)的關(guān)于節(jié)點(diǎn)的各類信息长捧，會(huì)定時(shí)通過API Server讀取這些節(jié)點(diǎn)的信息嚣鄙，這些節(jié)點(diǎn)信息是由kubelet定時(shí)推給API Server的，由API Server寫入到Etcd中串结。
這些節(jié)點(diǎn)信息包括：節(jié)點(diǎn)健康狀況哑子、節(jié)點(diǎn)資源、節(jié)點(diǎn)名稱肌割、節(jié)點(diǎn)地址信息卧蜓、操作系統(tǒng)版本、Docker版本把敞、kubelet版本等弥奸。監(jiān)控到節(jié)點(diǎn)信息若有異常情況，則會(huì)對節(jié)點(diǎn)進(jìn)行某種操作奋早，如節(jié)點(diǎn)狀態(tài)變?yōu)楣收蠣顟B(tài)盛霎，則刪除節(jié)點(diǎn)與節(jié)點(diǎn)相關(guān)的Pod等資源的信息。?
Namespace Controller
用戶是可以通過API Server創(chuàng)建新的namespace并保存在Etcd中的耽装。Namespace Controller會(huì)定時(shí)通過API Server讀取這些Namespace信息并做對應(yīng)的對于Namespace的一些操作愤炸。
ResourceQuota Controller
將期望的資源配額信息通過API Server寫入到Etcd中。然后ResourceQuota Controller會(huì)定時(shí)的統(tǒng)計(jì)這些信息掉奄，在系統(tǒng)請求資源的時(shí)候就會(huì)讀取這些統(tǒng)計(jì)信息规个，如果不合法就不給分配該資源，則創(chuàng)建行為會(huì)報(bào)錯(cuò)挥萌。
Scheduler
Kubernetes的調(diào)度器绰姻，負(fù)責(zé) Pod 資源調(diào)度。Scheduler監(jiān)聽API Server引瀑，當(dāng)需要?jiǎng)?chuàng)建新的Pod時(shí)狂芋。Scheduler負(fù)責(zé)選擇該P(yáng)od與哪個(gè)Node進(jìn)行綁定。將此綁定信息通過API Server寫入到Etcd中憨栽。
若此時(shí)與Node A進(jìn)行了綁定帜矾，那么A上的Kubelet就會(huì)從API Server上監(jiān)聽到此事件，那么該Kubelet就會(huì)做相應(yīng)的創(chuàng)建工作屑柔。
(Kubelet除了監(jiān)聽API Server做相應(yīng)的操作之外屡萤，還定時(shí)推送它所在節(jié)點(diǎn)的信息給API Server)
此調(diào)度涉及到三個(gè)對象，待調(diào)度的Pod掸宛，可用的Node死陆，調(diào)度算法。簡單的說，就是使用某種調(diào)度算法為待調(diào)度的Pod找到合適的運(yùn)行此Pod的Node措译。
Kubelet
Kubelet負(fù)責(zé) Pod 對應(yīng)的容器的創(chuàng)建别凤，啟動(dòng)等任務(wù)，同時(shí)與Master節(jié)點(diǎn)密切協(xié)作领虹。
每個(gè)Node節(jié)點(diǎn)上都會(huì)有一個(gè)Kubelet負(fù)責(zé)Master下發(fā)到該節(jié)點(diǎn)的具體任務(wù)规哪，管理該節(jié)點(diǎn)上的Pod和容器。而且會(huì)在創(chuàng)建之初向API Server注冊自身的信息塌衰，定時(shí)匯報(bào)節(jié)點(diǎn)的信息诉稍。它還通過cAdvisor監(jiān)控容器和節(jié)點(diǎn)資源。
節(jié)點(diǎn)管理
Kubelet在創(chuàng)建之初就會(huì)向API Server做自注冊最疆，然后會(huì)定時(shí)報(bào)告節(jié)點(diǎn)的信息給API Server寫入到Etcd中杯巨。默認(rèn)為10秒。
Pod管理
Kubelet會(huì)監(jiān)聽API Server肚菠，如果發(fā)現(xiàn)對Pod有什么操作舔箭，它就會(huì)作出相應(yīng)的動(dòng)作。例如發(fā)現(xiàn)有Pod與本Node進(jìn)行了綁定蚊逢。那么Kubelet就會(huì)創(chuàng)建相應(yīng)的Pod且調(diào)用Docker Client下載image并運(yùn)行container层扶。
容器健康檢查
有三種方式對容器做健康檢查：
1.在容器內(nèi)部運(yùn)行一個(gè)命令，如果該命令的退出狀態(tài)碼為0烙荷，則表明容器健康镜会。
2.TCP檢查。
3.HTTP檢查终抽。
cAdvisor資源監(jiān)控
Kubelet通過cAdvisor對該節(jié)點(diǎn)的各類資源進(jìn)行監(jiān)控戳表。如果集群需要這些監(jiān)控到的資源信息，可以安裝一個(gè)組件Heapster昼伴。
Heapster會(huì)進(jìn)行集群級(jí)別的監(jiān)控匾旭，它會(huì)通過Kubelet獲取到所有節(jié)點(diǎn)的各種資源信息，然后通過帶著關(guān)聯(lián)標(biāo)簽的Pod分組這些信息圃郊。
如果再配合InfluxDB與Grafana价涝，那么就成為一個(gè)完整的集群監(jiān)控系統(tǒng)了。
Kube-proxy
實(shí)現(xiàn) Kubernetes Service 的通信與負(fù)載均衡機(jī)制的重要組件持舆。
負(fù)責(zé)接收并轉(zhuǎn)發(fā)請求色瘩。Kube-proxy的核心功能是將到Service的訪問請求轉(zhuǎn)發(fā)到后臺(tái)的某個(gè)具體的Pod。
無論是通過ClusterIP+Port的方式逸寓，還是NodeIP+NodePort的方式訪問Service居兆，最終都會(huì)被節(jié)點(diǎn)的Iptables規(guī)則重定向到Kube-proxy監(jiān)聽服務(wù)代理端口，該代理端口實(shí)際上就是SocketServer在本地隨機(jī)打開的一個(gè)端口竹伸，SocketServer是Kube-proxy為每一個(gè)服務(wù)都會(huì)創(chuàng)建的“服務(wù)代理對象”的一部分泥栖。
當(dāng)Kube-proxy監(jiān)聽到Service的訪問請求后，它會(huì)找到最適合的Endpoints，然后將請求轉(zhuǎn)發(fā)過去聊倔。具體的路由選擇依據(jù)Round Robin算法及Service的Session會(huì)話保持這兩個(gè)特性晦毙。
Kubelet是Kubernetes中的重要組件之一生巡。如果把APIServer耙蔑、Controller Manager、Scheduler比做大腦的話孤荣，那么Kubelet毫無疑問就是雙手甸陌。它是做具體工作的組件。
Etcd
Etcd一種k-v存儲(chǔ)倉庫盐股，可用于服務(wù)發(fā)現(xiàn)程序钱豁。在Kubernetes中就是用Etcd來存儲(chǔ)各種k-v對象的。
所以我也認(rèn)為Etcd是Kubernetes的一個(gè)重要組件疯汁。當(dāng)我們無論是創(chuàng)建Deployment也好牲尺，還是創(chuàng)建Service也好，各種資源對象信息都是寫在Etcd中了幌蚊。
各個(gè)組件是通過API Server進(jìn)行交流的谤碳，然而數(shù)據(jù)的來源是Etcd。所以維持Etcd的高可用是至關(guān)重要的溢豆。如果Etcd壞了蜒简，任何程序也無法正常運(yùn)行了。
總結(jié)
Kubernetes的這些組件各自分別有著重要的功能漩仙。它們之間協(xié)同工作搓茬，共同保證了Kubernetes對于容器化應(yīng)用的自動(dòng)管理。
其中API Server起著橋梁的作用队他，各個(gè)組件都要通過它進(jìn)行交互卷仑。Controller Manager像是集群的大管家，管理著許多事務(wù)麸折。Scheduler就像是一個(gè)調(diào)度亭锡凝，負(fù)責(zé)Pod的調(diào)度工作。
Kubelet則在每個(gè)節(jié)點(diǎn)上都有磕谅，像是一個(gè)執(zhí)行者私爷，真正創(chuàng)建、修改膊夹、銷毀Pod的工作都是由它來具體執(zhí)行衬浑。
Kube-proxy像是負(fù)載均衡器，在外界需要對Pod進(jìn)行訪問時(shí)它作為代理進(jìn)行路由工作放刨，將具體的訪問分給某一具體的Pod實(shí)例工秩。
Etcd則是Kubernetes的數(shù)據(jù)中心，用來存儲(chǔ)Kubernetes創(chuàng)建的各類資源對象信息。
這些組件缺一不可助币，無論少了哪一個(gè)Kubernetes都不能進(jìn)行正常的工作浪听。這里大概講了下各組件的功能，感興趣的可以分析Kubernetes的源碼眉菱，github中就有迹栓。
————————————————
版權(quán)聲明：本文為CSDN博主「愛若手握流沙」的原創(chuàng)文章，遵循 CC 4.0 BY-SA 版權(quán)協(xié)議俭缓，轉(zhuǎn)載請附上原文出處鏈接及本聲明克伊。
原文鏈接：https://blog.csdn.net/qmw19910301/article/details/87298462
