zookeeper，及k8s基礎概念

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

標籤：Linux

上一篇：使用 Helm Chart 部署及卸載 istio

下一篇：linux系統IO操作