一、Kubernetes整體架構(gòu)
Kubernetes屬于主從分布式架構(gòu)盖灸，主要由Master Node和Worker Node組成，以及包括客戶端命令行工具kubectl和其它附加項处嫌。
Master Node：作為控制節(jié)點而涉，對集群進行調(diào)度管理；Master Node由API Server瞳秽、Scheduler瓣履、Cluster State Store和Controller-Manger Server所組成；
Worker Node：作為真正的工作節(jié)點练俐，運行業(yè)務(wù)應(yīng)用的容器袖迎；Worker Node包含kubelet、kube proxy和Container Runtime；kubectl：用于通過命令行與API Server進行交互燕锥，而對Kubernetes進行操作辜贵，實現(xiàn)在集群中進行各種資源的增刪改查等操作；
Add-on：是對Kubernetes核心功能的擴展归形，例如增加網(wǎng)絡(luò)和網(wǎng)絡(luò)策略等能力托慨。
二、Kubernetes基本組件
Kubernetes是一個輕便的和可擴展的開源平臺暇榴，用于管理容器化應(yīng)用和服務(wù)厚棵。通過Kubernetes能夠進行應(yīng)用的自動化部署和擴縮容。
2.1Master Node(主節(jié)點)：
2.1.1 API Server（API服務(wù)器）
APIServer負責對外提供RESTful的Kubernetes API服務(wù)蔼紧，它是系統(tǒng)管理指令的統(tǒng)一入口婆硬，任何對資源進行增刪改查的操作都要交給APIServer處理后再提交給etcd。
如架構(gòu)圖中所示歉井，kubectl（Kubernetes提供的客戶端工具柿祈，該工具內(nèi)部就是對Kubernetes API的調(diào)用）是直接和APIServer交互的。
2.1.2 Cluster state store（集群狀態(tài)存儲）
Kubernetes默認使用etcd作為集群整體存儲哩至，etcd是一個簡單的躏嚎、分布式的、一致的key-value存儲菩貌，Kubernetes使用它來存儲各個資源的狀態(tài)卢佣。
2.1.3 Controller-Manager Server（控制管理服務(wù)器）
如果說APIServer做的是“前臺”的工作的話，那controller manager就是負責“后臺”的箭阶。
每個資源一般都對應(yīng)有一個控制器虚茶，而controller manager就是負責管理這些控制器的。
比如我們通過APIServer創(chuàng)建一個pod仇参，當這個pod創(chuàng)建成功后嘹叫，APIServer的任務(wù)就算完成了。而后面保證Pod的狀態(tài)始終和我們預(yù)期的一樣的重任就由controller manager去保證了诈乒。
2.1.4 Scheduler（調(diào)度器）
scheduler的職責很明確罩扇，就是負責調(diào)度pod到合適的Node上。如果把scheduler看成一個黑匣子怕磨，那么它的輸入是pod和由多個Node組成的列表喂饥，輸出是Pod和一個Node的綁定，即將這個pod部署到這個Node上肠鲫。Kubernetes目前提供了調(diào)度算法员帮，但是同樣也保留了接口，用戶可以根據(jù)自己的需求定義自己的調(diào)度算法导饲。調(diào)度策略分為預(yù)選策略和優(yōu)選策略捞高，Pod的整個調(diào)度過程分為兩步：
1）預(yù)選Node：遍歷集群中所有的Node氯材，按照具體的預(yù)選策略篩選出符合要求的Node列表。如沒有Node符合預(yù)選策略規(guī)則棠枉，該Pod就會被掛起浓体，直到集群中出現(xiàn)符合要求的Node泡挺。
2）優(yōu)選Node：預(yù)選Node列表的基礎(chǔ)上辈讶，按照優(yōu)選策略為待選的Node進行打分和排序，從中獲取最優(yōu)Node娄猫。
2.1.5 儀表板（Dashboard）（可選）
Kubernetes提供網(wǎng)頁UI來簡化用戶與API服務(wù)器（API Server）的交互贱除。
2.2 Work Node（從節(jié)點）
2.2.1 Kubelet
Kubelet是Kubernetes中最主要的控制器，它是Pod和Node API的主要實現(xiàn)者媳溺，Kubelet負責驅(qū)動容器執(zhí)行層月幌。
在Kubernets中，Pod作為基本的執(zhí)行單元悬蔽，它可以擁有多個容器和存儲數(shù)據(jù)卷扯躺，能夠方便在每個容器中打包一個單一的應(yīng)用。Kubelet是Master在每個Node節(jié)點上面的agent蝎困，是Node節(jié)點上面最重要的模塊录语，它負責維護和管理該Node上面的所有容器，但是如果容器不是通過Kubernetes創(chuàng)建的禾乘，它并不會管理澎埠。本質(zhì)上，它負責使Pod得運行狀態(tài)與期望的狀態(tài)一致
2.2.2 Container Runtime(容器運行時)
runtime指的是容器運行環(huán)境始藕，目前Kubernetes支持docker和rkt兩種容器蒲稳。
2.2.3 Kube proxy
該模塊實現(xiàn)了Kubernetes中的服務(wù)發(fā)現(xiàn)和反向代理功能。
反向代理方面：kube-proxy支持TCP和UDP連接轉(zhuǎn)發(fā)伍派，默認基于Round Robin算法將客戶端流量轉(zhuǎn)發(fā)到與service對應(yīng)的一組后端pod江耀。
服務(wù)發(fā)現(xiàn)方面，kube-proxy使用etcd的watch機制诉植，監(jiān)控集群中service和endpoint對象數(shù)據(jù)的動態(tài)變化祥国，并且維護一個service到endpoint的映射關(guān)系，從而保證了后端pod的IP變化不會對訪問者造成影響倍踪。另外kube-proxy還支持session affinity系宫。
2.3 Kubectl
kubectl是Kubernetes集群的命令行接口。比如：
$ kubectl [command] [TYPE] [NAME] [flags]
comand：指定要對資源執(zhí)行的操作建车，例如create扩借、get、describe和delete
TYPE：指定資源類型缤至，資源類型是大小寫敏感的潮罪，開發(fā)者能夠以單數(shù)康谆、復(fù)數(shù)和縮略的形式。例如：
$ kubectl get pod pod1
$ kubectl get pods pod1
$ kubectl get po pod1
NAME：指定資源的名稱嫉到，名稱也大小寫敏感的沃暗。如果省略名稱，則會顯示所有的資源何恶，例如：
$kubectl get pods
flags：指定可選的參數(shù)孽锥。例如，可以使用-s或者–server參數(shù)指定Kubernetes API server的地址和端口细层。
三惜辑、Kubernetes術(shù)語說明
Pod
Pod安排在節(jié)點上，包含一組容器和存儲卷疫赎。同一個Pod里的容器共享同一個網(wǎng)絡(luò)命名空間盛撑，可以使用localhost互相通信。
Pod是短暫的捧搞，不是持續(xù)性實體抵卫。那么：
- 怎樣才能持久化容器數(shù)據(jù)，使其能夠跨重啟而存在呢胎撇？ Kubernetes支持卷的概念介粘，因此可以使用持久化的卷類型。
- 是否能手動創(chuàng)建Pod创坞，如果想要創(chuàng)建同一個容器的多份拷貝碗短，需要一個個分別創(chuàng)建出來么？以手動創(chuàng)建單個Pod题涨，也可以使用Replication Controller使用Pod模板創(chuàng)建出多份拷貝偎谁。
- 重啟時，IP地址可能會改變纲堵，怎樣才能從前端容器正確可靠地指向后臺容器呢巡雨？使用Service。
Lable
正如上圖所示席函，部分Pod帶有Label铐望。一個Label是attach到Pod的一對“鍵值對”，用來傳遞用戶定義的屬性茂附。
比如正蛙，你可能創(chuàng)建了一個"tier"和“app”標簽，通過Label（tier=frontend, app=myapp）來標記前端Pod容器营曼，使用Label（tier=backend, app=myapp）標記后臺Pod乒验。然后可以使用Selectors選擇帶有特定Label的Pod，并且將Service或者Replication Controller應(yīng)用到上面蒂阱。
Replication Controller
對應(yīng)上面的問題：“是否能手動創(chuàng)建Pod锻全，如果想要創(chuàng)建同一個容器的多份拷貝狂塘，需要一個個分別創(chuàng)建出來么？能否將Pods劃到邏輯組里鳄厌？”
Replication Controller確保任意時間都有指定數(shù)量的Pod“副本”在運行荞胡。如果為某個Pod創(chuàng)建了Replication Controller并且指定3個副本，它會創(chuàng)建3個Pod了嚎，并且持續(xù)監(jiān)控它們泪漂。如果某個Pod不響應(yīng)，那么Replication Controller會替換它新思，保持總數(shù)為3窖梁。
如下面的動畫所示：
如果之前不響應(yīng)的Pod恢復(fù)了赘风，現(xiàn)在就有4個Pod了夹囚，那么Replication Controller會將其中一個終止保持總數(shù)為3。
如果在運行中將副本總數(shù)改為5邀窃，Replication Controller會立刻啟動2個新Pod荸哟，保證總數(shù)為5。同樣也可以按照這樣的方式減少Pod的個數(shù)瞬捕。
這個特性在執(zhí)行滾動升級時很有用鞍历。
需要注意的是，當創(chuàng)建Replication Controller時肪虎，需要指定兩個東西：
Pod模板：用來創(chuàng)建Pod副本的模板
Label：Replication Controller需要監(jiān)控的Pod的標簽劣砍。
Service
假設(shè)現(xiàn)在已經(jīng)創(chuàng)建了Pod副本，那么在這些副本上如何均衡負載呢扇救？我們需要的是Service刑枝。
對應(yīng)上面的問題：“如果Pods是短暫的，那么重啟時IP地址可能會改變迅腔，怎么才能從前端容器正確可靠地指向后臺容器呢装畅？”
Service是定義一系列Pod以及訪問這些Pod的策略的一層抽象。
Service通過Label找到Pod組沧烈。因為Service是抽象的掠兄，所以在圖表里通常看不到它們的存在锌雀，這也就讓這一概念更難以理解蚂夕。
假設(shè)有2個后臺Pod，并且定義后臺Service的名稱為‘backend-service’腋逆，lable為（tier=backend, app=myapp）婿牍。backend-service 的Service會完成如下兩件重要的事情：
為Service創(chuàng)建一個本地集群的DNS入口，因此前端Pod只需要DNS查找主機名為 ‘backend-service’闲礼，就能夠解析出前端應(yīng)用程序可用的IP地址牍汹。
現(xiàn)在前端已經(jīng)得到了后臺服務(wù)的IP地址铐维，但是它應(yīng)該訪問2個后臺Pod的哪一個呢？Service在這2個后臺Pod之間提供透明的負載均衡慎菲，會將請求分發(fā)給其中的任意一個（如下面的動畫所示）嫁蛇。
通過每個Node上運行的代理（kube-proxy）完成。
下圖動態(tài)展示了Service的功能露该。該圖作了簡化睬棚。
另外還有有一個特別類型的Kubernetes Service，稱為'LoadBalancer'解幼，作為外部負載均衡器使用抑党，在一定數(shù)量的Pod之間均衡流量。
比如撵摆，對于負載均衡Web流量很有用底靠。
Node
節(jié)點（上圖橘色方框）是物理或者虛擬機器，作為Kubernetes worker特铝，通常稱為Minion暑中。每個節(jié)點都運行如下Kubernetes關(guān)鍵組件：
Kubelet：是主節(jié)點代理。
Kube-proxy：Service使用其將鏈接路由到Pod鲫剿，如上文所述鳄逾。
Docker或Rocket：Kubernetes使用的容器技術(shù)來創(chuàng)建容器。
Kubernetes Master
集群擁有一個Kubernetes Master（紫色方框）灵莲。
Kubernetes Master提供集群的獨特視角雕凹，并且擁有一系列組件，比如Kubernetes API Server政冻。
API Server提供可以用來和集群交互的REST端點枚抵。
master節(jié)點包括用來創(chuàng)建和復(fù)制Pod的Replication Controller。
集群
一個集群指容器運行所需要的云資源組合赠幕，關(guān)聯(lián)了若干服務(wù)器節(jié)點俄精、負載均衡、專有網(wǎng)絡(luò)等云資源榕堰。
節(jié)點
一臺服務(wù)器（可以是虛擬機實例或者物理服務(wù)器）已經(jīng)安裝了 Docker Engine竖慧，可以用于部署和管理容器；容器服務(wù)的 Agent 程序會安裝到節(jié)點上并注冊到一個集群上逆屡。集群中的節(jié)點數(shù)量可以伸縮圾旨。
容器
一個通過 Docker 鏡像創(chuàng)建的運行時實例，一個節(jié)點可運行多個容器魏蔗。
鏡像
Docker 鏡像是容器應(yīng)用打包的標準格式砍的，在部署容器化應(yīng)用時可以指定鏡像，鏡像可以來自于 Docker Hub莺治，阿里云容器 Hub廓鞠，或者用戶的私有 Registry帚稠。鏡像 ID 可以由鏡像所在倉庫 URI 和鏡像 Tag（缺省為 latest）唯一確認。
編排模板
編排模板包含了一組容器服務(wù)的定義和其相互關(guān)聯(lián)床佳，可以用于多容器應(yīng)用的部署和管理滋早。容器服務(wù)支持 Docker Compose 模板規(guī)范并有所擴展。
應(yīng)用
一個應(yīng)用可通過單個鏡像或一個編排模板創(chuàng)建砌们，每個應(yīng)用可包含1個或多個服務(wù)杆麸。
服務(wù)
一組基于相同鏡像和配置定義的容器，作為一個可伸縮的微服務(wù)浪感。
節(jié)點（Node）
Kubernetes 集群中的計算能力由 Node 提供昔头，Kubernetes 集群中的 Node 是所有 Pod 運行所在的工作主機，可以是物理機也可以是虛擬機影兽。工作主機的統(tǒng)一特征是上面要運行 kubelet 管理節(jié)點上運行的容器揭斧。
命名空間（Namespace）
命名空間為 Kubernetes 集群提供虛擬的隔離作用。Kubernetes 集群初始有 3 個命名空間赢笨，分別是默認命名空間 default未蝌、系統(tǒng)命名空間 kube-system 和 kube-public ，除此以外茧妒，管理員可以可以創(chuàng)建新的名字空間滿足需要。
Pod
Pod是 Kubernetes 部署應(yīng)用或服務(wù)的最小的基本單位左冬。一個Pod 封裝多個應(yīng)用容器（也可以只有一個容器）桐筏、存儲資源、一個獨立的網(wǎng)絡(luò) IP 以及管理控制容器運行方式的策略選項拇砰。
服務(wù)（Service）
Service 也是 Kubernetes 的基本操作單元梅忌，是真實應(yīng)用服務(wù)的抽象，每一個服務(wù)后面都有很多對應(yīng)的容器來提供支持除破，通過 Kube-Proxy 的 port 和服務(wù) selector 決定服務(wù)請求傳遞給后端的容器牧氮，對外表現(xiàn)為一個單一訪問接口，外部不需要了解后端如何運行瑰枫，這給擴展或維護后端帶來很大的好處踱葛。
部署（Deployment）
部署表示用戶對 Kubernetes 集群的一次更新操作。部署比 RS 應(yīng)用更廣光坝，可以是創(chuàng)建一個新的服務(wù)尸诽，更新一個新的服務(wù)，也可以是滾動升級一個服務(wù)盯另。滾動升級一個服務(wù)性含，實際是創(chuàng)建一個新的 RS，然后逐漸將新 RS 中副本數(shù)增加到理想狀態(tài)鸳惯，將舊 RS 中的副本數(shù)減小到 0 的復(fù)合操作商蕴；這樣一個復(fù)合操作用一個RS是不太好描述的叠萍，所以用一個更通用的 Deployment 來描述。不建議您手動管理利用 Deployment 創(chuàng)建的 RS绪商。
服務(wù)（Service）
Service 也是 Kubernetes 的基本操作單元俭令，是真實應(yīng)用服務(wù)的抽象，每一個服務(wù)后面都有很多對應(yīng)的容器來提供支持部宿，通過 Kube-Proxy 的 port 和服務(wù) selector 決定服務(wù)請求傳遞給后端的容器抄腔，對外表現(xiàn)為一個單一訪問接口，外部不需要了解后端如何運行理张，這給擴展或維護后端帶來很大的好處赫蛇。
標簽（labels）
Labels 的實質(zhì)是附著在資源對象上的一系列 Key/Value 鍵值對，用于指定對用戶有意義的對象的屬性雾叭，標簽對內(nèi)核系統(tǒng)是沒有直接意義的悟耘。標簽可以在創(chuàng)建一個對象的時候直接賦予，也可以在后期隨時修改织狐，每一個對象可以擁有多個標簽暂幼，但 key 值必須唯一。
存儲卷（Volume）
Kubernetes 集群中的存儲卷跟 Docker 的存儲卷有些類似移迫，只不過 Docker 的存儲卷作用范圍為一個容器旺嬉，而 Kubernetes 的存儲卷的生命周期和作用范圍是一個 Pod。每個 Pod 中聲明的存儲卷由 Pod 中的所有容器共享厨埋。支持使用 Persistent Volume Claim 即 PVC 這種邏輯存儲邪媳，使用者可以忽略后臺的實際存儲技術(shù)，具體關(guān)于 Persistent Volumn(pv)的配置由存儲管理員來配置荡陷。
持久存儲卷（Persistent Volume雨效，PV）和持久存儲卷聲明（Persistent Volume Claim，PVC）
PV 和 PVC 使得 Kubernetes 集群具備了存儲的邏輯抽象能力废赞，使得在配置 Pod 的邏輯里可以忽略對實際后臺存儲技術(shù)的配置徽龟，而把這項配置的工作交給 PV 的配置者。存儲的 PV 和 PVC 的這種關(guān)系唉地，跟計算的 Node 和 Pod 的關(guān)系是非常類似的据悔；PV 和 Node 是資源的提供者，根據(jù)集群的基礎(chǔ)設(shè)施變化而變化渣蜗，由 Kubernetes 集群管理員配置屠尊；而 PVC 和 Pod是資源的使用者，根據(jù)業(yè)務(wù)服務(wù)的需求變化而變化耕拷，由 Kubernetes 集群的使用者即服務(wù)的管理員來配置讼昆。
