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模式的原理圖：