【Kubernetes系列】第1篇 架構及組件介紹
- 2019 年 10 月 5 日
- 筆記
1. Kubernetes簡介
Kubernetes是Google開源的容器集群管理系統，是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模式的原理圖：
