kubernetes基本框架和基本概念
- Kubernetes是什么蟹略？我(們)為什么使用？
- Kubernetes主要概念
- Kubernetes總體結(jié)構(gòu)
- Kubernetes核心原理
- Kubernetes網(wǎng)絡(luò)模型
Kubernetes是什么唧取？我(們)為什么使用唬滑？
Kubernetes是Google(基于borg)開源的容器集群管理系統(tǒng)，其提供應(yīng)用部署、維護蛋叼、 擴展機制等功能，利用Kubernetes能方便地管理跨機器運行容器化的應(yīng)用剂陡，其主要功能如下：
使用Docker對應(yīng)用程序包裝(package)狈涮、實例化(instantiate)、運行(run)鸭栖。
以集群的方式運行歌馍、管理跨機器的容器。
解決Docker跨機器容器之間的通訊問題晕鹊。
Kubernetes的自我修復(fù)機制使得容器集群總是運行在用戶期望的狀態(tài)松却。
為什么使用？
- 開發(fā)人員各司其職溅话，輕裝上陣（架構(gòu)師負責服務(wù)組件提煉晓锻，開發(fā)工程師負責業(yè)務(wù)代碼的開發(fā)，運維或系統(tǒng)公司師負責部署與運維）
- 全面擁抱微服務(wù)框架
- 使用Kubernetes我們系統(tǒng)可以隨時的整體遷移
- Kubernetes系統(tǒng)具備了超強的橫向擴容能力
Kubernetes概念
-
Master: 集群控制節(jié)點飞几，master節(jié)點上運行著一組關(guān)鍵的進程
- Kubernetes API Server(kube-apiserver), 提供 HTTP Rest 接口的關(guān)鍵服務(wù)程序砚哆，kubernets里所有資源增、刪屑墨、改躁锁、查等操作的唯一入口，也是集群控制的入口進程
- Kubernetes Controller Manager(kube-controller-manager)卵史，所有資源對象的自動化控制中心（資源對象的大總管）
- Kubernetes Scheduler(kube-scheduler)战转，資源調(diào)度(pod)的進程（調(diào)度室）
- etcd Server，Kubernetes 里所有資源對象的數(shù)據(jù)全部是保持在etcd中
-
Node： Node是與Master而言的工作主機以躯，可以使物理主機槐秧、VM等，運行Kubelet、kube-proxy和docker Engine
- kubelet: pod對應(yīng)容器的創(chuàng)建色鸳、暫停等任務(wù)
- kube-proxy: k8s service 的通信與負載均衡機制的重要組件
- Docker Engine dokcer 引擎社痛，本機容器的創(chuàng)建與管理
Pods：最小部署單元，可包含多個容器命雀，是連接在一起的容器組合并共享文件卷蒜哀。它們是最小的部署單元，由 Kubernetes 統(tǒng)一創(chuàng)建撵儿、調(diào)度、管理狐血。Pods是可以直接創(chuàng)建的淀歇，但推薦的做法是使用 Replication Controller，即使是創(chuàng)建一個 Pod匈织。
-
Labels： Label以key/value形式附加到Pos浪默、Service、RC缀匕、Node等上面纳决，每個對象可以定義多個label，以提供Label Selector來選擇對象乡小， Label Selector有兩種形式：
- 基于等式阔加，name=redis-slave選擇k/v都相等的，env!=production選擇k=env但是v!=production的
- 基于集合满钟，name [not] in (redis-master,redis-slave)胜榔，類似于SQL中in
-
Replication controllers： 管理 Pods 的生命周期。它們確保指定數(shù)量的 Pods 會一直運行湃番，還有實現(xiàn)資源伸縮夭织。
- 定義RC實現(xiàn)Pod的創(chuàng)建與副本數(shù)量的自動控制
- RC 通過Lable Selector機制實現(xiàn)對副本的自動控制
- 通過改變RC的Pod副本數(shù)量，實現(xiàn)Pod的擴容或縮容
- 通過改變RC里Pod模板中的鏡像版本牵辣，實現(xiàn)Pod的滾動更新
Deployment: 1.2引入摔癣，為了更好地解決pod的編排問題，內(nèi)部使用了Replica Set 實現(xiàn)纬向；它相對于RC的最大的升級是可以隨時知道當前Pod部署的進度
Horizontal Pod Autocaler(HPA): Pod橫向自動擴容择浊，通過追蹤分析RC控制的所有目標Pod的負載變化情況，確定是否需要針對性地調(diào)整目標Pod的副本數(shù)
Services：抽象服務(wù)出口逾条。它就像一個基礎(chǔ)版本的負載均衡器琢岩。
-
Volume ：Pod中能夠被多個容器訪問的共享目錄，其生命周期與Pod相同跟容器無關(guān)师脂。
- EmptyDir担孔，Pod分配到Node時創(chuàng)建的江锨，初始內(nèi)容為空，Pod從Node中移除時EmptyDir數(shù)據(jù)永久刪除糕篇。主要用于臨時空間啄育、CheckPoint臨時保存目錄等
- hostPath，在Pod上掛載宿主機上的文件或目錄拌消，主要用于需要永久保存的
- gcePersistentDisk,使用谷歌計算引擎上永久磁盤上的文件挑豌，寫入數(shù)據(jù)永久保存。
- awsElasticBlockStore墩崩，使用Amazon提供的EBS Volume
- nfs氓英，使用NFS(網(wǎng)絡(luò)文件系統(tǒng))提供的共享目錄
- iscsi，使用iSCSI設(shè)備
- glusterfs鹦筹，使用開源GlusterFS網(wǎng)絡(luò)文件系統(tǒng)
- rbd铝阐，使用Linux塊設(shè)備共享存儲
- gitRepo，通過掛載一個空目錄铐拐，從Git庫clone一個> - git repository給Pod使用
- secret徘键，一個secret volume用于為Pod提供加密的信息
- persistent Volume, "網(wǎng)絡(luò)存儲"，獨立于“計算資源”而存在的實體資源余舶，可以看做一個與Kubernetes無關(guān)的網(wǎng)盤
Annotation：與Lable類似啊鸭，也使用key/value 鍵值對的形式定義锹淌，不同于Lable定義Kubernetes的元數(shù)據(jù)匿值，它是用戶任意定義的附加信息，以便于外部工具進行查找
Kubernetes總體結(jié)構(gòu)
Master組件：
- ApiServer：作為kubernetes系統(tǒng)的入口赂摆，封裝了核心對象的增刪改查操作挟憔。
- Scheduler：插件式的調(diào)度器，負責集群的資源調(diào)度烟号，為新建的pod分配機器绊谭。
-
Controller：負責管理各種控制器。如- - ReplicationController汪拥，
EndPointController等达传。
Node組件：
- kubelet：負責管控docker容器，如啟動/停止迫筑、監(jiān)控運行狀態(tài)等宪赶。
- proxy：負責為pod提供代理。它會定期從etcd獲取所有的service脯燃，并根據(jù)service信息創(chuàng)建代理搂妻。
公共組件：
- Etcd
- flannel
Kubernetes核心原理
API Server
提供集群管理的API接口；
api-server進程提供http(8080)/https(6443)兩個端口供訪問辕棚；成為集群內(nèi)各個功能模塊之間數(shù)據(jù)交互和通信的中心樞紐欲主；? 集群內(nèi)部功能模塊通過API Server將信息存入etcd邓厕，其他模塊通過API ? Server（用get、list或watch）讀取這些信息扁瓢，實現(xiàn)模塊之間的信息交互详恼。
擁有完備的集群安全機制。
Controller Manager
-
Replication Controller
- 確保在任何時候集群中一個rc下的pod都保持一定數(shù)量的pod副本處于正常運行狀態(tài)引几。
- 重新調(diào)度单雾、彈性伸縮。
- 滾動更新（Rolling Updates）
-
Node Controller
負責發(fā)現(xiàn)她紫、管理和監(jiān)控集群中的各個Node節(jié)點硅堆。
-
ResourceQuota Controller
資源配額管理確保制定對象在任何時候都不會超量占用系統(tǒng)資源。
三個維度配額：容器（C/M）贿讹、Pod渐逃、namespace（pod、rc民褂、service茄菊、resourceQuota、Secret赊堪、PV） -
Endpoint Controller
定期關(guān)聯(lián)service和pod(關(guān)聯(lián)信息由endpoint對象維護)面殖，保證service到pod的映射總是最新的。
-
Services Controller
監(jiān)聽Service的變化
Scheduler
- 負責Pod調(diào)度
- 通過調(diào)度算法為待調(diào)度Pod列表的每個Pod從 Node列表中選擇一個最合適的Node
預(yù)選策略：
- NoDiskConflict
- PodFitsResources
- PodSelectorMatches
- PodFitsHost
- CheckNodeLabel…
…..
Kubelet
負責本Node節(jié)點上的Pod的創(chuàng)建哭廉、修改脊僚、監(jiān)控、刪除等遵绰，同時定時同步本Node的狀態(tài)信息到API Server
kube-Proxy
實現(xiàn)Service的代理及軟件模式的負載均衡器
Kubernetes網(wǎng)絡(luò)模型
容器到容器通信辽幌，共享網(wǎng)絡(luò)空間；
同Node上pod間通信椿访，通過docker0網(wǎng)橋乌企；
不同Node上pod間通信？
隧道方案
通過隧道成玫，或者說Overlay Networking的方式：
Weave加酵，UDP廣播，本機建立新的BR哭当，通過PCAP互通猪腕。
Open vSwitch（OVS），基于VxLAN和GRE協(xié)議荣病，但是性能方面損失比較嚴重码撰。
Flannel，UDP廣播个盆，VxLan脖岛。
隧道方案在IaaS層的網(wǎng)絡(luò)中應(yīng)用也比較多朵栖，大家共識是隨著節(jié)點規(guī)模的增長復(fù)雜度會提升，而且出了網(wǎng)絡(luò)問題跟蹤起來比較麻煩柴梆，大規(guī)模集群情況下這是需要考慮的一個點陨溅。
路由方案
還有另外一類方式是通過路由來實現(xiàn)，比較典型的代表有：
Calico绍在，基于BGP協(xié)議的路由方案门扇，支持很細致的ACL控制，對混合云親和度比較高偿渡。
Macvlan臼寄，從邏輯和Kernel層來看隔離性和性能最優(yōu)的方案，基于二層隔離溜宽，所以需要二層路由器支持吉拳，大多數(shù)云服務(wù)商不支持，所以混合云上比較難以實現(xiàn)适揉。
路由方案一般是從3層或者2層實現(xiàn)隔離和跨主機容器互通的留攒，出了問題也很容易排查。
Flannel方案
- 首先連上etcd嫉嘀，利用etcd管理可以分配的IP地址段資源炼邀，同事監(jiān)控etcd中每個Pod的實際地址，并在內(nèi)存中建立一個Pod節(jié)點路由表剪侮，然后下連docker0和物理網(wǎng)絡(luò)拭宁，使用內(nèi)存中的Pod節(jié)點路由表，將docker0發(fā)給它的數(shù)據(jù)包包裝起來票彪，利用物理網(wǎng)絡(luò)連接將數(shù)據(jù)包投遞到目標flanneld上红淡。
- Flannel之間的底層通信協(xié)議可選余地很多，有UDP降铸、VxLan、AWS VPC等摇零，只要能通到對端的Flannel就可以推掸。源flanneld加包，目標flanneld解包驻仅，對于docker0是透明的谅畅。一般以UDP為主。
