1、核心概念
一、Node
Node做爲集羣中的工做節點，運行真正的應用程序，在Node上Kubernetes管理的最小運行單元是Pod。Node上運行着Kubernetes的Kubelet、kube-proxy服務進程，這些服務進程負責Pod的建立、啓動、監控、重啓、銷燬、以及實現軟件模式的負載均衡。
Node包含的信息：
- Node地址：主機的IP地址，或Node ID。
- Node的運行狀態：Pending、Running、Terminated三種狀態。
- Node Condition：…
- Node系統容量：描述Node可用的系統資源，包括CPU、內存、最大可調度Pod數量等。
- 其餘：內核版本號、Kubernetes版本等。
查看Node信息：
kubectl describe node
二、Pod
Pod是Kubernetes最基本的操做單元，包含一個或多個緊密相關的容器，一個Pod能夠被一個容器化的環境看做應用層的「邏輯宿主機」；一個Pod中的多個容器應用一般是緊密耦合的，Pod在Node上被建立、啓動或者銷燬；每一個Pod裏運行着一個特殊的被稱之爲Pause的容器，其餘容器則爲業務容器，這些業務容器共享Pause容器的網絡棧和Volume掛載卷，所以他們之間通訊和數據交換更爲高效，在設計時咱們能夠充分利用這一特性將一組密切相關的服務進程放入同一個Pod中。
同一個Pod裏的容器之間僅需經過localhost就能互相通訊。
一個Pod中的應用容器共享同一組資源：
- PID命名空間：Pod中的不一樣應用程序能夠看到其餘應用程序的進程ID；
- 網絡命名空間：Pod中的多個容器可以訪問同一個IP和端口範圍；
- IPC命名空間：Pod中的多個容器可以使用SystemV IPC或POSIX消息隊列進行通訊；
- UTS命名空間：Pod中的多個容器共享一個主機名；
- Volumes（共享存儲卷）：Pod中的各個容器能夠訪問在Pod級別定義的Volumes；
Pod的生命週期經過Replication Controller來管理；經過模板進行定義，而後分配到一個Node上運行，在Pod所包含容器運行結束後，Pod結束。
Kubernetes爲Pod設計了一套獨特的網絡配置，包括：爲每一個Pod分配一個IP地址，使用Pod名做爲容器間通訊的主機名等。
三、Service
在Kubernetes的世界裏，雖然每一個Pod都會被分配一個單獨的IP地址，但這個IP地址會隨着Pod的銷燬而消失，這就引出一個問題：若是有一組Pod組成一個集羣來提供服務，那麼如何來訪問它呢？Service！
一個Service能夠看做一組提供相同服務的Pod的對外訪問接口，Service做用於哪些Pod是經過Label Selector來定義的。
- 擁有一個指定的名字（好比my-mysql-server）；
- 擁有一個虛擬IP（Cluster IP、Service IP或VIP）和端口號，銷燬以前不會改變，只能內網訪問；
- 可以提供某種遠程服務能力；
- 被映射到了提供這種服務能力的一組容器應用上；
若是Service要提供外網服務，需指定公共IP和NodePort，或外部負載均衡器；
NodePort 系統會在Kubernetes集羣中的每一個Node上打開一個主機的真實端口，這樣，可以訪問Node的客戶端就能經過這個端口訪問到內部的Service了
四、Volume
Volume是Pod中可以被多個容器訪問的共享目錄。
五、Label
Label以key/value的形式附加到各類對象上，如Pod、Service、RC、Node等，以識別這些對象，管理關聯關係等，如Service和Pod的關聯關係。
六、RC（Replication Controller）
- 目標Pod的定義；
- 目標Pod須要運行的副本數量；
- 要監控的目標Pod標籤（Lable）；
Kubernetes經過RC中定義的Lable篩選出對應的Pod實例，並實時監控其狀態和數量，若是實例數量少於定義的副本數量（Replicas），則會根據RC中定義的Pod模板來建立一個新的Pod，而後將此Pod調度到合適的Node上啓動運行，直到Pod實例數量達到預約目標。
2、Kubernetes整體架構
Master和Node
Kubernetes將集羣中的機器劃分爲一個Master節點和一羣工做節點（Node）。其中，Master節點上運行着集羣管理相關的一組進程etcd、API Server、Controller Manager、Scheduler，後三個組件構成了Kubernetes的總控中心，這些進程實現了整個集羣的資源管理、Pod調度、彈性伸縮、安全控制、系統監控和糾錯等管理功能，而且全都是自動完成。在每一個Node上運行Kubelet、Proxy、Docker daemon三個組件，負責對本節點上的Pod的生命週期進行管理，以及實現服務代理的功能。
流程 經過Kubectl提交一個建立RC的請求，該請求經過API Server被寫入etcd中，此時Controller Manager經過API Server的監聽資源變化的接口監聽到這個RC事件，分析以後，發現當前集羣中尚未它所對應的Pod實例，因而根據RC裏的Pod模板定義生成一個Pod對象，經過API Server寫入etcd，接下來，此事件被Scheduler發現，它當即執行一個複雜的調度流程，爲這個新Pod選定一個落戶的Node，而後經過API Server講這一結果寫入到etcd中，隨後，目標Node上運行的Kubelet進程經過API Server監測到這個「新生的」Pod，並按照它的定義，啓動該Pod並不辭辛苦地負責它的下半生，直到Pod的生命結束。
隨後，咱們經過Kubectl提交一個新的映射到該Pod的Service的建立請求，Controller Manager會經過Label標籤查詢到相關聯的Pod實例，而後生成Service的Endpoints信息，並經過API Server寫入到etcd中，接下來，全部Node上運行的Proxy進程經過API Server查詢並監聽Service對象與其對應的Endpoints信息，創建一個軟件方式的負載均衡器來實現Service訪問到後端Pod的流量轉發功能。
-
etcd 用於持久化存儲集羣中全部的資源對象，如Node、Service、Pod、RC、Namespace等；API Server提供了操做etcd的封裝接口API，這些API基本上都是集羣中資源對象的增刪改查及監聽資源變化的接口。
-
API Server 提供了資源對象的惟一操做入口，其餘全部組件都必須經過它提供的API來操做資源數據，經過對相關的資源數據「全量查詢」+「變化監聽」，這些組件能夠很「實時」地完成相關的業務功能。
-
Controller Manager 集羣內部的管理控制中心，其主要目的是實現Kubernetes集羣的故障檢測和恢復的自動化工做，好比根據RC的定義完成Pod的複製或移除，以確保Pod實例數符合RC副本的定義；根據Service與Pod的管理關係，完成服務的Endpoints對象的建立和更新；其餘諸如Node的發現、管理和狀態監控、死亡容器所佔磁盤空間及本地緩存的鏡像文件的清理等工做也是由Controller Manager完成的。
-
Scheduler 集羣中的調度器，負責Pod在集羣節點中的調度分配。
-
Kubelet 負責本Node節點上的Pod的建立、修改、監控、刪除等全生命週期管理，同時Kubelet定時「上報」本Node的狀態信息到API Server裏。
-
Proxy 實現了Service的代理與軟件模式的負載均衡器。
客戶端經過Kubectl命令行工具或Kubectl Proxy來訪問Kubernetes系統，在Kubernetes集羣內部的客戶端能夠直接使用Kuberctl命令管理集羣。Kubectl Proxy是API Server的一個反向代理，在Kubernetes集羣外部的客戶端能夠經過Kubernetes Proxy來訪問API Server。
API Server內部有一套完備的安全機制，包括認證、受權和准入控制等相關模塊。 轉自：https://www.cnblogs.com/menkeyi/p/7134460.html