1.?Kubernetes簡介
Kubernetes是谷歌開源的容器集群管理系統(tǒng)鲁驶，是Google多年大規(guī)模容器管理技術Borg的開源版本臊泰，主要功能包括:
- 基于容器的應用部署缔御、維護和滾動升級
- 負載均衡和服務發(fā)現(xiàn)
- 跨機器和跨地區(qū)的集群調(diào)度
- 自動伸縮
- 無狀態(tài)服務和有狀態(tài)服務?
- 廣泛的Volume支持?
- 插件機制保證擴展性
Kubernetes發(fā)展非常迅速惜颇，已經(jīng)成為容器編排領域的領導者皆刺。
2.?Kubernetes 架構(gòu)及組件介紹
2.1 kubernetes 架構(gòu)
Kubernetes架構(gòu)如圖所示：
Kubernetes主要由以下幾個核心組件構(gòu)成：
- etcd 保存整個集群的狀態(tài)；
- apiserver 提供了資源操作的唯一入口凌摄，并提供認證羡蛾、授權(quán)、訪問控制锨亏、API注冊和發(fā)現(xiàn)等機制痴怨；
- controller manager 負責維護集群的狀態(tài)，比如故障檢測器予、自動擴展浪藻、滾動更新等；
- scheduler 負責資源的調(diào)度乾翔，按照預定的調(diào)度策略將實例（Pod）調(diào)度到相應的主機上爱葵；
- kubelet 負責維護容器的生命周期，同時也負責存儲卷和網(wǎng)絡的管理反浓；
- container runtime 負責鏡像管理以及容器的真正執(zhí)行萌丈，在我們系統(tǒng)中指的是Docker
- kube-proxy 負責為應用提供集群內(nèi)部的服務發(fā)現(xiàn)和負載均衡
推薦的插件
- helm - kubernetes包管理工具
-?kube-dns/coreDNS 負責為整個集群提供DNS服務
-?Ingress Controller 為服務提供外網(wǎng)入口
-?Heapster 提供資源監(jiān)控
-?Dashboard 提供GUI
-?Federation 提供跨可用區(qū)的集群
-?Fluentd-elasticsearch 提供集群日志采集、存儲與查詢
2.2 Kubernetes組件介紹
2.2.1 etcd
etcd是基于Raft一致性算法開發(fā)的分布式key-value存儲雷则，可用于服務發(fā)現(xiàn)辆雾、共享配置以及一致性保障（如數(shù)據(jù)庫選主、分布式鎖等）
etcd主要功能：
-?基本的key-value存儲
-?監(jiān)聽機制
-?key的過期及續(xù)約機制月劈，用于監(jiān)控和服務發(fā)現(xiàn)
-?原子CAS和CAD乾颁，用于分布式鎖和leader選舉
Etcd基于RAFT的一致性
leader節(jié)點選舉方法
-?初始啟動時，節(jié)點處于follower狀態(tài)并被設定一個election timeout艺栈，如果在這一時間周期內(nèi)沒有收到來自leader的心跳檢測英岭，節(jié)點將發(fā)起選舉，將自己切換為candidate（候選人）節(jié)點之后湿右，向集群中的其他follow節(jié)點發(fā)送請求诅妹，詢問其是否選舉自己為leader
-?當收到來自集群中過半數(shù)節(jié)點的接受投票后，節(jié)點即成為leader毅人，開始接收保存client的數(shù)據(jù)并向其他的follower節(jié)點同步日志吭狡。如果沒有達成一致，則candidate節(jié)點隨機選擇一個等待時間（150ms ～ 300ms）再次發(fā)起投票丈莺，得到集群中半數(shù)以上的follower接受的candidate將成為leader
-?leader節(jié)點依靠定時向follower節(jié)點發(fā)送心跳檢測來保持其地位
-?任何時候如果其他follower在election timeout期間沒有收到來自leader的心跳檢測划煮，同樣會將自己的狀態(tài)切換為candidate并發(fā)起選舉。每成功選舉一次缔俄，新leader的步進數(shù)（Term）都會比之前l(fā)eader的步進數(shù)加1
失效處理
-?leader失效：其他沒有收到心跳檢測的節(jié)點將發(fā)起新的選舉弛秋，當leader恢復后由于步進數(shù)小自動成為follower（日志會被新leader的日志覆蓋）
-?follower節(jié)點不可用：follower節(jié)點不可用的情況相對比較容易解決器躏。因為集群中的日志內(nèi)容始終是從leader節(jié)點同步，只要這一節(jié)點再次加入集群時重新從leader節(jié)點處復制日志即可
-?多個候選人（candidate）：沖突后candidate將隨機選擇一個等待時間（150ms ～ 300ms）再次發(fā)起投票蟹略，得到集群中半數(shù)以上的follower接受的candidate將成為leader
講到這里可能有同學發(fā)現(xiàn)Etcd和Zookeeper登失、Consul等一致性協(xié)議實現(xiàn)框架有些類似，的確這些中間件是比較類似的挖炬，關于其中的異同點揽浙，大家可以自行查閱資料。
2.2.2 kube-apiserver
kube-apiserver是Kubernetes最重要的核心組件之一意敛，主要提供了如下功能：
-?提供集群管理的REST API接口馅巷，包括認證授權(quán)、數(shù)據(jù)校驗以及集群狀態(tài)變更等
-?提供同其他模塊之間的數(shù)據(jù)交互(其他模塊通過API Server查詢或修改數(shù)據(jù)草姻，只有API Server才直接操作etcd)
2.2.3 kube-scheduler
kube-scheduler負責分配調(diào)度Pod到集群內(nèi)的節(jié)點上钓猬，它監(jiān)聽kube-apiserver，查詢還未分配Node的Pod碴倾，然后根據(jù)調(diào)度策略為這些Pod分配節(jié)點
通過以下三種方式可以指定Pod只運行在特定的Node節(jié)點上
-?nodeSelector:只調(diào)度到匹配指定label的Node上?
-?nodeAffinity:功能更豐富的Node選擇器逗噩，比如支持集合操作?
-?podAffinity:調(diào)度到滿足條件的Pod所在的Node上
2.2.4 kube-controller-manager
kube-controller-manager是Kubernetes的大腦掉丽，通過kube-apiserver監(jiān)控整個集群的狀態(tài)跌榔，并確保集群處于預期的工作狀態(tài)，它由一系列的控制器組成捶障，這些控制器主要包括三組：
1. 必須啟動的控制器
-?eploymentController
-?DaemonSetController
-?NamesapceController
-?ReplicationController
-?RelicaSet
-?JobController
...
2. 默認啟動的控制器
-?NodeController
-?ServiceController
-?PVBinderController
...
3. 默認禁止的可選控制器
-?BootstrapSignerController
-?TokenCleanerController
2.2.5 Kubelet
每個Node節(jié)點上都運行一個kubelet守護進程僧须，默認監(jiān)聽10250端口，接收并執(zhí)行master發(fā)來的指令项炼，管理Pod及Pod中的容器担平。每個kubelet進程會在API Server上注冊節(jié)點自身信息，定期向master節(jié)點匯報節(jié)點的資源使用情況
節(jié)點管理?
主要是節(jié)點自注冊和節(jié)點狀態(tài)更新:
- Kubelet可以通過設置啟動參數(shù) --register-node 來確定是否向API Server注冊自己;?
-?如果Kubelet沒有選擇自注冊模式锭部，則需要用戶自己配置Node資源信息暂论，同時需要在Kubelet上配置集群中API Server的信息;
-?Kubelet在啟動時通過API Server注冊節(jié)點信息，并定時向API Server發(fā)送節(jié)點狀態(tài)消息拌禾，API Server在接收到新消息后取胎，將信息寫入etcd
容器健康檢查
Pod通過兩類探針檢查容器的健康狀態(tài)
-?LivenessProbe 存活探針：通過該探針判斷容器是否健康，告訴Kubelet一個容器什么時候處于不健康的狀態(tài)湃窍。如果LivenessProbe探針探測到容器不健康闻蛀，則kubelet將刪除該容器，并根據(jù)容器的重啟策略做相應的處理您市。如果一個容器不包含LivenessProbe探針觉痛，那么kubelet認為該容器的LivenessProbe探針返回的值永遠是“Success”。
-?ReadinessProbe 就緒探針：用于判斷容器是否啟動完成且準備接收請求茵休。如果 ReadinessProbe 探針探測到失敗薪棒，則Pod的狀態(tài)將被修改手蝎。Endpoint Controller將從Service的Endpoint中刪除包含該容器所在Pod的IP地址的Endpoint條目。
以下是Pod的啟動流程：
2.2.6 kube-proxy
每臺機器上都運行一個kube-proxy服務盗尸，它監(jiān)聽API Server中service和Pod的變化情況柑船，并通過userspace、iptables泼各、ipvs等proxier來為服務配置負載均衡
代理模式（proxy-mode）提供如下三種類型：
1）userspace
最早的負載均衡方案鞍时，它在用戶空間監(jiān)聽一個端口，所有請求通過 iptables 轉(zhuǎn)發(fā)到這個端口扣蜻，然后在其內(nèi)部負載均衡到實際的 Pod懂缕。service的請求會先從用戶空間進入內(nèi)核iptables，然后再回到用戶空間（kube-proxy）铆遭，由kube-proxy完成后端Endpoints的選擇和代理工作膘螟，這樣流量從用戶空間進出內(nèi)核帶來的性能損耗是不可接受的，所以產(chǎn)生了iptables的代理模式?
2）iptables:
iptables mode完全使用iptables來完成請求過濾和轉(zhuǎn)發(fā)芳肌。但是如果集群中存在大量的Service/Endpoint灵再，那么Node上的iptables rules將會非常龐大，添加或者刪除iptables規(guī)則會引起較大的延遲亿笤。
3） ipvs:
為了解決存在大量iptables規(guī)則時的網(wǎng)絡延遲的問題翎迁，Kubernetes引入了ipvs的模式，（ipvs是LVS - Linux Virtual Server 的重要組成部分净薛，最早是由中國的章文嵩博士推出的一個開源項目汪榔，提供軟件負載均衡的解決方案），下面是ipvs模式的原理圖：
