【Kubernetes系列】第1篇 架構及組件介紹

1. Kubernetes簡介

Kubernetes是谷歌開源的容器集羣管理系統，是Google多年大規模容器管理技術Borg的開源版本，主要功能包括:

• 基於容器的應用部署、維護和滾動升級

• 負載均衡和服務發現

• 跨機器和跨地區的集羣調度

• 自動伸縮

• 無狀態服務和有狀態服務

• 普遍的Volume支持

• 插件機制保證擴展性

Kubernetes發展很是迅速，已經成爲容器編排領域的領導者。

2. Kubernetes 架構及組件介紹

2.1 kubernetes 架構

Kubernetes架構如圖所示：

Kubernetes主要由如下幾個核心組件構成：

• etcd 保存整個集羣的狀態；

• apiserver 提供了資源操做的惟一入口，並提供認證、受權、訪問控制、API註冊和發現等機制；

• controller manager 負責維護集羣的狀態，好比故障檢測、自動擴展、滾動更新等；

• scheduler 負責資源的調度，按照預約的調度策略將實例（Pod）調度到相應的主機上；

• kubelet 負責維護容器的生命週期，同時也負責存儲卷和網絡的管理；

• container runtime 負責鏡像管理以及容器的真正執行，在咱們系統中指的是Docker

• kube-proxy 負責爲應用提供集羣內部的服務發現和負載均衡

推薦的插件

• helm - kubernetes包管理工具
• kube-dns/coreDNS 負責爲整個集羣提供DNS服務
• Ingress Controller 爲服務提供外網入口
• Heapster 提供資源監控
• Dashboard 提供GUI
• Federation 提供跨可用區的集羣
• Fluentd-elasticsearch 提供集羣日誌採集、存儲與查詢

2.2 Kubernetes組件介紹

2.2.1 etcd

etcd是基於Raft一致性算法開發的分佈式key-value存儲，可用於服務發現、共享配置以及一致性保障（如數據庫選主、分佈式鎖等）

etcd主要功能：

• 基本的key-value存儲

• 監聽機制

• key的過時及續約機制，用於監控和服務發現

• 原子CAS和CAD，用於分佈式鎖和leader選舉

Etcd基於RAFT的一致性

leader節點選舉方法

• 初始啓動時，節點處於follower狀態並被設定一個election timeout，若是在這一時間週期內沒有收到來自leader的心跳檢測，節點將發起選舉，將本身切換爲candidate（候選人）節點以後，向集羣中的其餘follow節點發送請求，詢問其是否選舉本身爲leader

• 當收到來自集羣中過半數節點的接受投票後，節點即成爲leader，開始接收保存client的數據並向其餘的follower節點同步日誌。若是沒有達成一致，則candidate節點隨機選擇一個等待時間（150ms ～ 300ms）再次發起投票，獲得集羣中半數以上的follower接受的candidate將成爲leader

• leader節點依靠定時向follower節點發送心跳檢測來保持其地位

• 任什麼時候候若是其餘follower在election timeout期間沒有收到來自leader的心跳檢測，一樣會將本身的狀態切換爲candidate併發起選舉。每成功選舉一次，新leader的步進數（Term）都會比以前leader的步進數加1

失效處理

• leader失效：其餘沒有收到心跳檢測的節點將發起新的選舉，當leader恢復後因爲步進數小自動成爲follower（日誌會被新leader的日誌覆蓋）

• follower節點不可用：follower節點不可用的狀況相對比較容易解決。由於集羣中的日誌內容始終是從leader節點同步，只要這一節點再次加入集羣時從新從leader節點處複製日誌便可

• 多個候選人（candidate）：衝突後candidate將隨機選擇一個等待時間（150ms ～ 300ms）再次發起投票，獲得集羣中半數以上的follower接受的candidate將成爲leader

講到這裏可能有同窗發現Etcd和Zookeeper、Consul等一致性協議實現框架有些相似，的確這些中間件是比較相似的，關於其中的異同點，你們能夠自行查閱資料。

2.2.2 kube-apiserver

kube-apiserver是Kubernetes最重要的核心組件之一，主要提供了以下功能：

• 提供集羣管理的REST API接口，包括認證受權、數據校驗以及集羣狀態變動等

• 提供同其餘模塊之間的數據交互(其餘模塊經過API Server查詢或修改數據，只有API Server才直接操做etcd)

2.2.3 kube-scheduler

kube-scheduler負責分配調度Pod到集羣內的節點上，它監聽kube-apiserver，查詢還未分配Node的Pod，而後根據調度策略爲這些Pod分配節點

經過如下三種方式能夠指定Pod只運行在特定的Node節點上

• nodeSelector:只調度到匹配指定label的Node上

• nodeAffinity:功能更豐富的Node選擇器，好比支持集合操做

• podAffinity:調度到知足條件的Pod所在的Node上

2.2.4 kube-controller-manager

kube-controller-manager是Kubernetes的大腦，經過kube-apiserver監控整個集羣的狀態，並確保集羣處於預期的工做狀態，它由一系列的控制器組成，這些控制器主要包括三組：

1. 必須啓動的控制器

• eploymentController

• DaemonSetController

• NamesapceController

• ReplicationController

• RelicaSet

• JobController

• ...

2. 默認啓動的控制器

• NodeController

• ServiceController

• PVBinderController

• ...

3. 默認禁止的可選控制器

• BootstrapSignerController

• TokenCleanerController

2.2.5 Kubelet

每一個Node節點上都運行一個kubelet守護進程，默認監聽10250端口，接收並執行master發來的指令，管理Pod及Pod中的容器。每一個kubelet進程會在API Server上註冊節點自身信息，按期向master節點彙報節點的資源使用狀況

節點管理

主要是節點自注冊和節點狀態更新:

• Kubelet能夠經過設置啓動參數 --register-node 來肯定是否向API Server註冊本身;

• 若是Kubelet沒有選擇自注冊模式，則須要用戶本身配置Node資源信息，同時須要在Kubelet上配置集羣中API Server的信息;

• Kubelet在啓動時經過API Server註冊節點信息，並定時向API Server發送節點狀態消息，API Server在接收到新消息後，將信息寫入etcd

容器健康檢查

Pod經過兩類探針檢查容器的健康狀態

• LivenessProbe 存活探針：經過該探針判斷容器是否健康，告訴Kubelet一個容器何時處於不健康的狀態。若是LivenessProbe探針探測到容器不健康，則kubelet將刪除該容器，並根據容器的重啓策略作相應的處理。若是一個容器不包含LivenessProbe探針，那麼kubelet認爲該容器的LivenessProbe探針返回的值永遠是「Success」。

• ReadinessProbe 就緒探針：用於判斷容器是否啓動完成且準備接收請求。若是 ReadinessProbe 探針探測到失敗，則Pod的狀態將被修改。Endpoint Controller將從Service的Endpoint中刪除包含該容器所在Pod的IP地址的Endpoint條目。

如下是Pod的啓動流程：

2.2.6 kube-proxy

每臺機器上都運行一個kube-proxy服務，它監聽API Server中service和Pod的變化狀況，並經過userspace、iptables、ipvs等proxier來爲服務配置負載均衡

代理模式（proxy-mode）提供以下三種類型：

1) userspace

最先的負載均衡方案，它在用戶空間監聽一個端口，全部請求經過 iptables 轉發到這個端口，而後在其內部負載均衡到實際的 Pod。service的請求會先從用戶空間進入內核iptables，而後再回到用戶空間（kube-proxy），由kube-proxy完成後端Endpoints的選擇和代理工做，這樣流量從用戶空間進出內核帶來的性能損耗是不可接受的，因此產生了iptables的代理模式

2) iptables:

iptables mode徹底使用iptables來完成請求過濾和轉發。可是若是集羣中存在大量的Service/Endpoint，那麼Node上的iptables rules將會很是龐大，添加或者刪除iptables規則會引發較大的延遲。

3) ipvs:

爲了解決存在大量iptables規則時的網絡延遲的問題，Kubernetes引入了ipvs的模式，（ipvs是LVS - Linux Virtual Server 的重要組成部分，最先是由中國的章文嵩博士推出的一個開源項目，提供軟件負載均衡的解決方案），下面是ipvs模式的原理圖：