Kubernetes 學習總結(1) Synopsis

同類產品
docker compose、docker swarm、docker machine、mesos、marathon

Kubernetes 項目地址
https://github.com/kubernetes/kubernetes/releases

Schema


核心組件:
1) API server ：接收、分析用戶請求，並處理用戶請求
2) Scheduler ：調度資源（經過初選、優選、選定三個階段調度建立container的請求）
3) Controller manager 控制器管理器：確保各控制器健康運行
Controller 控制器：持續監控容器資源的運行狀態，確保已建立的container資源健康運行（控制器包含多種)。控制器不停的在本地loop，若是發現問題，當即向API server請求，API server 調用Scheduler 再次優選出符合條件的node並運行相關container。
4）etcd 是一個高可用的鍵值存儲系統，Kubernetes使用它來存儲各個資源的狀態，從而實現了Restful的API。
5）Kubelet是 Master在每一個Node節點上面的agent，是Node節點上面最重要的模塊，它負責維護和管理該Node上面的全部container，可是若是容器不是經過Kubernetes建立的，它並不會管理。本質上，它負責使Pod的運行狀態與指望的狀態一致。kebelet 接收各類Task ,而後由本機上的Container Engine負責啓動容器 ，經常使用的Container Engine 有 docker 、rocker等。但若是node down掉全部容器就會關閉。
6）kube-proxy 實現了Kubernetes中的服務發現和反向代理功能。反向代理方面：kube-proxy支持TCP和UDP鏈接轉發，默認基於Round Robin算法將客戶端流量轉發到與service對應的一組後端pod。服務發現方面，kube-proxy使用etcd的watch機制，監控集羣中service和endpoint對象數據的動態變化，而且維護一個service到endpoint的映射關係，從而保證了後端pod的IP變化不會對訪問者形成影響。另外kube-proxy還支持session affinity。
7）runtime 指的是容器運行環境，目前Kubernetes支持docker和rkt兩種容器

Pod
K8s 上運行的最小單位是 Pod , k8s 直接調度的是Pod , pod是容器的外殼，它爲容器作了一層抽象的封裝。能夠將多個容器聯合起來，定義統一的網絡名稱空間，就構成了Pod。 同一個Pod中的容器共享同一個net ipc名稱空間，也能夠共享同一個存儲卷。
通常一個pod內只放一個container ，若是放了多個，通常都會有一個主容器，其它容器是爲了輔助該主容器運行。（一個容器內運行一個程序，因此有時就須要在另外一個容器內運行一個輔助程序，來輔助該主程序的運行）

Pod又分爲:
自主式pod(自我管理)
由Pod controller管理的pod

Pod Controller又有如下多種:
Replication Controller (保證pod數量與指望數量相符、滾動更新)
ReplicaSet (新版本中替換Replication Controller，但它通常不直接使用，通常使用它的直接聲明式更新的控制器deployment)
Deployment (只能管理無狀態pod、支持二級控制器HPA)
StatefulSet (管理有狀態pod)
DaemonSet(每一個node上運行一個副本，而不是隨意運行)
Job 、Cronjob (管理臨時短暫task運行程序的pod)

HPA(HorizontalPodAutoScaling) 自動水平擴展

Label
爲了方便pod的識別，方便分類管理，能夠在pod上進行Tag Label(添加meta info)。由selector 對各資源進行 label篩選。
Kubernetes 提供一個restfull 格式的API。用戶的請求-->發給master-->master上的scheduler 分析各node上資源的運行狀態--> 選定最合適的node ,將請求發給該node的 kubelet --> kubelet 控制本地的Container Engine 進行建立container 。

Service
就是 client 與pod之間的中間層，service_name 、service address 不會變。service是一個pod服務池的代理抽象，目前的實現方法是經過一個固定的虛擬IP及端口來定義，而且經過分佈在全部節點上的proxy來實現內部服務對pod的訪問。service是將虛擬IP經過iptables重定向到最終的pod上。Service 實質上就是一些iptables的DNAT規則 。
Client request先到service，而後再由service將request代理到後端相關的pod上。Service 關聯後端pod時，使用Labe屬性進行識別。
Service name到IP地址之間的解析由DNS負責。DNS是運行在一個專門的pod上。該運行了DNS的Pod屬於kubernetes的附件(AddOn)，它支持動態更新。
後期版本的iptables rule 會更新爲 lvs rule，由於iptables 的後端調度功能較弱。
例：Client —> SLB/ELB/ELA/NLB—> Nodes —> service name —> nginx —> service name —> tomcat —> service name —> mysql
Service 經常使用類型有兩種：供外部訪問，供內部訪問

網絡
三種網絡類型
Pods network: 默認 10.244.0.0/16
Service network:默認 10.96.0.0/12
Node network: 默認172.16.0.0/16

訪問流程：client Request —> Node network —> service network —> pod network

Pod內多containers通信能夠利用lo。
各Pods間containers通信：1) 物理橋橋接; 2) overylay network
Pods與service通信：先經過core_DNS解析，再由iptables轉發便可

kubernetes不提供網絡功能，由plugin提供。kubernetes由CNI來負責第三方plugin的網絡管理，提供Pod network/service network的管理。
常見的有：flannel(二層疊加網絡)、calico(三層BGP，支持各類策略)、canel(結合前兩種的功能)
說明：網絡策略即定義不一樣pod之間的container是否能夠互聯

Kebe-proxyKebe-proxy與API server聯繫，並負責service的管理，以及負責kubernetes cluster外部的訪問。service發生變化時由kube-proxy產生事件通知API server，從而同步數據。各Master上的數據存儲在共享存儲etcd中，防止數據丟失。