1、描述zookeeper集群中leader，follower，observer幾種角色 Zookeeper： 分散式系統：是一個硬體或軟體組件分佈在網路中的不同的電腦之上，彼此間僅通過消息傳遞進行通信和協作的系統。 特征： 分佈性、對等性、併發性、缺乏全局時鐘、故障必然會發生 典型問題： 通信異 ...
1、描述zookeeper集群中leader，follower，observer幾種角色
Zookeeper：
分散式系統：是一個硬體或軟體組件分佈在網路中的不同的電腦之上，彼此間僅通過消息傳遞進行通信和協作的系統。
特征：
分佈性、對等性、併發性、缺乏全局時鐘、故障必然會發生
典型問題：
通信異常、網路分區、三態(成功、失敗、超時)、節點故障
zookeeper是一個開源的分面式協調服務，由知名互聯網公司Yahoo創建，它是Chubby的開源實現；換句話講，zk是一個典型的分散式數據一致性解決方案，分散式應用程式可以基於它實現數據的發佈/訂閱、負載均衡、名稱服務、分散式協調/通知、集群管理、Master選舉、分散式鎖和分散式隊列；
基本概念：
集群角色：Leader, Follower, Observer
Leader：選舉產生，讀/寫；
Follower：參與選舉，可被選舉，讀服務；
Observer：參與選舉，不可被選舉，提供讀服務；
會話：ZK中，客戶端<-->服務端，TCP長連接；
sessionTimeout
數據節點(ZNode)：即zk數據模型中的數據單元；zk的數據都存儲於記憶體中，數據模型為樹狀結構(ZNode Tree)；每個ZNode都會保存自己的數據於記憶體中；
持久節點：僅顯式刪除才消失
臨時節點：會話中止即自動消失
版本（version）：ZK會為每個ZNode維護一個稱之為Stat的數據結構，記錄了當前ZNode的三個數據版本
version：當前版本
cversion：當前znode的子節點的版本
aversion：當前znode的ACL的版本
ACL：ZK使用ACL機制進行許可權控制
CREATE， READ，WRITE，DELETE，ADMIN
事件監聽器(Watcher)：
ZK上，由用戶指定的觸發機制，在某些事件產生時，ZK能夠將通知給相關的客戶端；
ZAB協議：Zookeeper Atomic Broadcast，ZK原子廣播協議；
ZAB協議中存在三種狀態：
(1) Looking,
(2) Following，
(3) Leading
四個階段：
選舉:election
發現：discovery
同步：sync
廣播：Broadcast
2、完成zookeeper分散式集群的搭建
安裝：
wget http://mirrors.tuna.tsinghua.edu.cn/apache/zookeeper/
部署方式：單機模式、偽分散式模式、分散式模式
http://zookeeper.apache.org
zoo.cfg配置參數：
tickTime=2000 #心跳檢測時間2秒
dataDir=/data/zookeeper #數據目錄
ClientPort=2181#監聽埠
initLimit=5#初始同步階段經過多少個tick時長
syncLimit=2#請求信息經過多少個tick時長
指定主機的語法格式：
server.ID=IP:port:port
ID：各主機的數字標識，一般從1開始
IP:各主機的IP
節點信息：stat
cZxid = 0x14 #表示節點由那個事務創建的
ctime = Wed Sep 14 16:12:44 CST 2016
mZxid = 0x14 #最近更新事務節點的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, 一次性地觸發通知機制；
mv zoo_sample.cfg zoo.cfg #修改配置文件名
./zkServer.sh start #啟動zk
zkCli.sh 連接zk
zkCli命令：
create, ls, ls2, stat, delete, rmr, get, set, ...
監控zk的四字命令：
ruok, stat, srvr, conf, cons, wchs, envi ...
zoo.cfg配置文件的參數：
基本配置參數：
clientPort=2181
dataDir=/data/zookeeper
dataLogDir：事務日誌文件路徑；
tickTime：
存儲配置：
preAllocSize：為事務日誌預先分配的磁碟空間量；預設65535KB；
snapCount：每多少次事務後執行一次快照操作；每事務的平均大小在100位元組；
autopurget.snapRetainCount：
autopurge.purgeInterval：purge操作的時間間隔，0表示不啟動；
fsync.warningthresholdms：zk進行事務日誌fsync操作時消耗的時長報警閾值；
weight.X=N：判斷quorum時投票許可權，預設1；
網路配置：
maxClientCnxns：每客戶端IP的最大併發連接數；
clientPortAddress：zk監聽IP地址；
minSessionTimeout：
maxSessionTimeout：
集群配置：
initLimit：Follower連入Leader並完成數據同步的時長；
syncLimit：心跳檢測的最大延遲；
leaderServes：預設zk的leader接收讀寫請求，額外還要負責協調各Follower發來的事務等；因此，為使得leader集中處理zk集群內部信息，建議不讓leader直接提供服務；
cnxTimeout：Leader選舉期間，各伺服器創建TCP連接的超時時長；
ellectionAlg：選舉演算法，目前僅支持FastLeaderElection演算法一種；
server.id=[hostname]:port:port[:observer]
集群內各伺服器的屬性參數
第一個port：follower與leader進行通信和數據同步時所使用埠；
第二個port：leader選舉時使用的埠；
observer：定義指定的伺服器為observer；
註意：運行為集群模式時，每個節點在其數據目錄中應該有一個myid文件，其內容僅為當前server的id；
典型應用場景：
數據發佈/訂閱
負載均衡
命名服務
分散式協調/通知
集群管理
Master選舉
集群工作模式
在三台主機中安裝jdk，解壓zk包，創建數據目錄。
tar -xf zookeeper-3.4.14.tar.gz -C /usr/local
cd /usr/local/
ln -s zookeeper-3.4.14/ ./zookeeper
mkdir /data/zookeeper
修改配置文件，拷貝至其他節點
#因為zk識別不了主節點。需要創建id文件
echo 1 > /data/zookeeper/myid
echo 2 > /data/zookeeper/myid
echo 3 > /data/zookeeper/myid
/usr/local/zookeeper/bin/zkServer.sh start #啟動各節點
3、總結kubernetes幾個重要組件以及組件的作用
Kubernetes主要組件有：kubectl (客戶端)
API Server、Controller Manager、Scheduler、Etcd (Master節點)
kubelet、kube-proxy (Slave Node節點)
API Server
API Server是Kubernetes的核心組件，是各個組件通信的渠道，
API Server集群控制的入口，提供了 RESTful API 介面的關鍵服務進程，是 Kubernetes 里所有資源的增刪改查等操作的唯一入口。創建一個資源對象如Deployment、Service、RC、ConfigMap等，都是要通過API Server的。
操作API Server的方式：1，通過命令行的kubectl命令，
2，通過寫代碼的方式，如client-go這樣的操作Kubernetes的第三方包來操作集群。
總之，最終，都是通過API Server對集群進行操作的。通過API Server，我們就可以往Etcd中寫入數據。Etcd中存儲著集群的各種數據。
如下圖：存儲Kubernetes集群信息的Etcd
資源配額控制的入口
Kubernetes可以從各個層級對資源進行配額控制。如容器的CPU使用量、Pod的CPU使用量、namespace的資源數量等。這也是通過API Server進行配置的。將這些資源配額情況寫入到Etcd中。
Controller Manager
Controller Manager作用是通過API Server監控Etcd中的節點信息，定時通過API Server讀取Etcd中的節點信息，監控到異常就會自動進行某種操作。
Node Controller通過API Server監控Etcd中存儲的關於節點的各類信息，會定時通過API Server讀取這些節點的信息，這些節點信息是由kubelet定時推給API Server的，由API Server寫入到Etcd中。
這些節點信息包括：節點健康狀況、節點資源、節點名稱、節點地址信息、操作系統版本、Docker版本、kubelet版本等。監控到節點信息若有異常情況，則會對節點進行某種操作，如節點狀態變為故障狀態，則刪除節點與節點相關的Pod等資源的信息。
Namespace Controller
用戶是可以通過API Server創建新的namespace並保存在Etcd中的。Namespace Controller會定時通過API Server讀取這些Namespace信息並做對應的對於Namespace的一些操作。
ResourceQuota Controller
將期望的資源配額信息通過API Server寫入到Etcd中。然後ResourceQuota Controller會定時的統計這些信息，在系統請求資源的時候就會讀取這些統計信息，如果不合法就不給分配該資源，則創建行為會報錯。
Scheduler
Kubernetes的調度器，負責 Pod 資源調度。Scheduler監聽API Server，當需要創建新的Pod時。Scheduler負責選擇該Pod與哪個Node進行綁定。將此綁定信息通過API Server寫入到Etcd中。
若此時與Node A進行了綁定，那麼A上的Kubelet就會從API Server上監聽到此事件，那麼該Kubelet就會做相應的創建工作。
(Kubelet除了監聽API Server做相應的操作之外，還定時推送它所在節點的信息給API Server)
此調度涉及到三個對象，待調度的Pod，可用的Node，調度演算法。簡單的說，就是使用某種調度演算法為待調度的Pod找到合適的運行此Pod的Node。
Kubelet
Kubelet負責 Pod 對應的容器的創建，啟動等任務，同時與Master節點密切協作。
每個Node節點上都會有一個Kubelet負責Master下發到該節點的具體任務，管理該節點上的Pod和容器。而且會在創建之初向API Server註冊自身的信息，定時彙報節點的信息。它還通過cAdvisor監控容器和節點資源。
節點管理
Kubelet在創建之初就會向API Server做自註冊，然後會定時報告節點的信息給API Server寫入到Etcd中。預設為10秒。
Pod管理
Kubelet會監聽API Server，如果發現對Pod有什麼操作，它就會作出相應的動作。例如發現有Pod與本Node進行了綁定。那麼Kubelet就會創建相應的Pod且調用Docker Client下載image並運行container。
容器健康檢查
有三種方式對容器做健康檢查：
1.在容器內部運行一個命令，如果該命令的退出狀態碼為0，則表明容器健康。
2.TCP檢查。
3.HTTP檢查。
cAdvisor資源監控
Kubelet通過cAdvisor對該節點的各類資源進行監控。如果集群需要這些監控到的資源信息，可以安裝一個組件Heapster。
Heapster會進行集群級別的監控，它會通過Kubelet獲取到所有節點的各種資源信息，然後通過帶著關聯標簽的Pod分組這些信息。
如果再配合InfluxDB與Grafana，那麼就成為一個完整的集群監控系統了。
Kube-proxy
實現 Kubernetes Service 的通信與負載均衡機制的重要組件。
負責接收並轉發請求。Kube-proxy的核心功能是將到Service的訪問請求轉發到後臺的某個具體的Pod。
無論是通過ClusterIP+Port的方式，還是NodeIP+NodePort的方式訪問Service，最終都會被節點的Iptables規則重定向到Kube-proxy監聽服務代理埠，該代理埠實際上就是SocketServer在本地隨機打開的一個埠，SocketServer是Kube-proxy為每一個服務都會創建的“服務代理對象”的一部分。
當Kube-proxy監聽到Service的訪問請求後，它會找到最適合的Endpoints，然後將請求轉發過去。具體的路由選擇依據Round Robin演算法及Service的Session會話保持這兩個特性。
Kubelet是Kubernetes中的重要組件之一。如果把APIServer、Controller Manager、Scheduler比做大腦的話，那麼Kubelet毫無疑問就是雙手。它是做具體工作的組件。
Etcd
Etcd一種k-v存儲倉庫，可用於服務發現程式。在Kubernetes中就是用Etcd來存儲各種k-v對象的。
所以我也認為Etcd是Kubernetes的一個重要組件。當我們無論是創建Deployment也好，還是創建Service也好，各種資源對象信息都是寫在Etcd中了。
各個組件是通過API Server進行交流的，然而數據的來源是Etcd。所以維持Etcd的高可用是至關重要的。如果Etcd壞了，任何程式也無法正常運行了。
總結
Kubernetes的這些組件各自分別有著重要的功能。它們之間協同工作，共同保證了Kubernetes對於容器化應用的自動管理。
其中API Server起著橋梁的作用，各個組件都要通過它進行交互。Controller Manager像是集群的大管家，管理著許多事務。Scheduler就像是一個調度亭，負責Pod的調度工作。
Kubelet則在每個節點上都有，像是一個執行者，真正創建、修改、銷毀Pod的工作都是由它來具體執行。
Kube-proxy像是負載均衡器，在外界需要對Pod進行訪問時它作為代理進行路由工作，將具體的訪問分給某一具體的Pod實例。
Etcd則是Kubernetes的數據中心，用來存儲Kubernetes創建的各類資源對象信息。
這些組件缺一不可，無論少了哪一個Kubernetes都不能進行正常的工作。這裡大概講了下各組件的功能，感興趣的可以分析Kubernetes的源碼，github中就有。
————————————————
版權聲明：本文為CSDN博主「愛若手握流沙」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/qmw19910301/article/details/87298462
