概述算法
我清晰地記得曾經讀到過的一篇博文，上面是這樣寫的，「雲端教父AWS雲端架構策略副總裁Adrian Cockcroft曾指出，二者雖然都是運用容器技術，但最大的差別是，Docker是要解決應用程序開發（Developing）問題，而Kubernetes是要解決更上層的應用程序運維問題（Operation）。開發問題是早期的痛點，但隨着企業愈來愈依賴容器技術，內部應用愈來愈可能是雲原生應用時，運維會是企業IT的新痛點。」大佬的一番話，明確地指出K8S的生存土壤！編程
學習一項技術，除了須要明確這項技術的應用場景和發展方向以外，最主要的是理解她的工做原理。後端
K8s的工做原理 api
Kubernetes（k8s）是跨主機集羣的自動部署、擴展以及運行應用程序容器的開源平臺，這些操做包括部署，調度和節點集羣間擴展。大二下學期我曽用過Docker容器技術部署容器，經歷過compose的變種，對於應用版本之間的兼容性問題深惡痛絕。咱們能夠將Docker當作Kubernetes內部使用的低級別組件。Kubernetes不只僅支持Docker，還支持Rocket（沒有接觸過），這是另外一種容器技術。
wikipedia給出的定義：K8s是用於自動部署、擴展和管理容器化（containerized）應用程序的開源系統。Google設計並捐贈給Cloud Native Computing Foundation（今屬Linux基金會）來使用的。它支持一系列容器工具, 包括Docker等。CNCF於2017年宣佈首批Kubernetes認證服務提供商（KCSPs），包含IBM、華爲、MIRANTIS、inwinSTACK迎棧科技等[5]服務商。
在《Kubernetes權威指南（第二版）》中給出的定義：她是一個全新的基於容器技術的分佈式架構領先方案，她提供了強大的自動化機制，系統後期的運維難度和運維成本大幅度下降。她是Google的大閨女Borg（http://dockone.io/article/726）的開源版本。使用K8s提供的解決方案，能夠節省大概30%的開發成本，能夠將精力更加集中於業務自己。安全
使用Kubernetes能夠：網絡
自動化容器的部署和複製
隨時擴展或收縮容器規模
將容器組織成組，而且提供容器間的負載均衡
很容易地升級應用程序容器的新版本
提供容器彈性，若是容器失效就替換它，等等...架構
集羣
在集羣管理方面，K8s將集羣中的機器劃分爲一個Master節點和一羣工做節點Node。Master節點上運行着集羣管理相關的一組進程kube-apiserver、kube-controller-manager和kube-scheduler。這些進程自動化實現了整個集羣的資源管理、Pod調度、彈性伸縮、安全控制、系統監控和糾錯等管理功能。
上圖能夠看到以下組件，使用特別的圖標表示Service和Label：
Kubernetes Master（Kubernetes主節點）
Node（節點）
Pod
Container（容器）
Label(label)（標籤）
Replication Controller（複製控制器）
Service（enter image description here）（服務）
Kubernetes Master
Master指的是集羣控制節點。每一個K8s集羣裏須要有一個Ms節點負責整個集羣的管理和控制。Kubernetes Master提供集羣的獨特視角，而且擁有一系列組件。
-
Kubernetes API Server（kube-apiserver），侍衛大統領！提供HTTP Rest接口的關鍵服務進程，是K8s裏全部資源的增刪改查等操做的惟一入口，也是集羣控制的入口進程。API Server提供能夠用來和集羣交互的Rest端點。
-
Kubernetes Controller Master（kube-controller-manager）掌印大太監，大總管！K8s裏全部資源對象的自動化控制中心。
-
Kubernetes Scheduler（kube-scheduler），御馬間的調度室！負責資源調度（Pod調度）的進程。建立和複製Pod的Replication Controller。
Node
節點（上圖橘色方框）是物理或者虛擬機器，做爲Kubernetes worker，一般稱爲Minion。每一個節點都運行以下Kubernetes關鍵組件。
1. Kubelet：與Master節點協做，是主節點的代理，負責Pod對應容器的建立，啓動，中止等任務。默認狀況下Kubelet會向Master註冊本身。Kubelet按期向主機點彙報加入集羣的Node的各種信息。
2. Kube-proxy：Kubernetes Service使用其將連接路由到Pod，做爲外部負載均衡器使用，在必定數量的Pod之間均衡流量。好比，對於負載均衡Web流量頗有用。
3. Docker或Rocket：Kubernetes使用的容器技術來建立容器。
Pod
Pod是K8s最重要也是最基礎的概念！每一個Pod都有一個特殊的被稱爲「根容器」的Pause容器，此容器與引入業務無關而且不易死亡。且以它的狀態表明整個容器組的狀態！Pause容器對應的鏡像屬於K8s平臺的一部分，除了Pause容器，每一個Pod還包含一個或多個用戶業務容器。Pod其實有兩種類型：普通的Pod及靜態Pod（static Pod）,static Pod並不存放在Kubemetes的eted存儲裏，而是存放在某個具體的Node上的一個具體文件中，而且只在此Node上啓動運行。而普通的Pod一旦被建立，就會被放入到etcd中存儲，確後會被KubernetesMaster調度到某個具體的Node上並進行綁定（Binding），隨後該Pod被對應的Node上的kubelet進程實例化成一組相關的Docker容器並啓動起來。在默認狀況下，當Pod裏的某個容器中止時，Kubemetes會自動檢測到這個問題而且從新啓動這個Pod（重啓Podel）的全部容器），若是Pod所在的Node完機，則會將這個Node上的全部Pod從新調度到其餘節點上。Pod（上圖綠色方框）安排在節點上，包含一組容器和卷。同一個Pod裏的容器共享同一個網絡命名空間，可使用localhost互相通訊。
Endpoint（Pod IP + ContainerPort） pod ip：一個Pod裏多個容器共享Pod IP地址。K8s要求底層網絡支持集羣內任意兩個Pod之間的TCP/IP直接通訊，使用虛擬二層網絡技術（Flannel（沒有接觸過 ），OpenvSwitch）實現。在Vmware中相似的二層交換技術是VSwitch，固然了，如今整個數據中心網絡二層逐步從vSwitch—>OpenvSwitch。
Lable
Lable相似Docker中的tag，一個是對「特殊」鏡像、容器、卷組等各類資源作標記，一個是attach到各類諸如Node、Pod、Server、RC資源對象上。不一樣的是Lable是一對鍵值對！Lable相似Tag，可以使用K8s專有的標籤選擇器（Label Selector）進行組合查詢。
Replication Controller
Replication Controller，簡稱RC，她用來幹啥呢？就是經過她來實現Pod副本數量的自動控制！RC確保任意時間都有指定數量的Pod「副本」在運行。
若是爲某個Pod建立了RC而且指定3個副本，它會建立3個Pod，而且持續監控它們。若是某個Pod不響應，那麼Replication Controller會替換它，保持總數爲3。若是以前不響應的Pod恢復了，如今就有4個Pod了，那麼Replication Controller會將其中一個終止保持總數爲3。若是在運行中將副本總數改成5，Replication Controller會馬上啓動2個新Pod，保證總數爲5。還能夠按照這樣的方式縮小Pod，這個特性在執行滾動升級時頗有用。
注意：刪除RC，不會影響該RC已經建立好的Pod。在邏輯上Pod副本和RC是解耦和的！建立RC時，須要指定Pod模板（用來建立Pod副本的模板）和Label（RC須要監控的Pod標籤）。
由Replication Controller衍生出Deployment，與RC類似90%，目的是更好地解決Pod編排。暫時不討論。
Horizontal Pod Autoscaler，簡稱HPA，Pod橫向自動擴容智能控件。與RC，Deployment同樣，也屬於K8s的一種資源對象。她的實現原理是經過追蹤分析RC控制的全部目標Pod的負載變化狀況，來肯定是否針對性地調整目標Pod的副本數。
(7) Service
Service
微服務架構中的一個「微服務」，她是正真的新娘，而以前的Pod，RC等資源對象其實都是嫁衣。
每一個Pod都會被分配一個單獨的IP地址，並且每一個Pod都提供了一個獨立的Endpoint（Pod lP + ContainerPort）以被客戶端訪問，如今多個Pod副本組成了一個集羣來提供服務，客戶端要想訪問集羣，通常的作法是部署一個負載均衡器（軟件或硬件），爲這組Pod開啓一個對外的服務端口如8000端口，而且將這些Pod的Endpoint列表加入8000端口的轉發列表中，客戶端就能夠經過負載均衡器的對外IP地址 + 服務端口來訪問此服務，而客戶端的請求最後會被轉發到哪一個Pod，則由負載均衡器的算法所決定。
K8s的server定義了一個服務的訪問入口地址，前端（Pod）經過入口地址訪問其背後的一組由Pod副本組成的集羣實例，service與其後端Pod副本集羣之間經過Label Selector 實現「無縫對接」。
能夠將Server抽象成特殊的扁平的雙向管道，Service藉助Label Selector保證了前端容器正確可靠地指向對應的後臺容器。 RC的做用保證了Service的服務能力和服務質量始終處於預期的標準。
Kubemetes也遵循了上述常規作法，運行在每一個Node上的kube-proxy進程其實就是一個智能的軟件負載均衡器，它負責把對Service的請求轉發到後端的某個Pod實例上，並在內部實現服務的負載均衡與會話保持機制。但Kubernetes發明了一種很巧妙又影響深遠的設計：Service不是共用一個負載均衡器的IP地址，而是每一個Service分配了一個全局惟一的虛擬IP地址，這個虛擬IP被稱爲ClusterIP。這樣一來，每一個服務就變成了具有惟一IP地址的「通訊節點」，服務調用就變成了最基礎的TCP網絡通訊問題。
Pod的Endpoint地址會隨着Pod的銷燬和從新建立而發生改變，由於新Pod的IP地址與以前舊Pod的不一樣。而Service一旦建立，Kubemetes就會自動爲它分配一個可用的Cluster IP，並且在Service的整個生命週期內，它的ClusterIP不會發生改變。因而，服務發現這個棘手的問題Kubemetes的架構裏也得以輕鬆解決：只要用Service的Name與Service的Cluster IP地址作一個DNS域名映射便可完美解決問題。