隨著Docker技術的發展和廣泛流行，雲原生應用和容器排程管理系統也成為IT領域大熱的詞彙。事實上，雲原生應用的思想，在Docker技術火爆之前，已經由雲端計算技術的領導者和分散式系統架構的推廣者廣泛傳播，例如雲原生應用的12要素早在2011年就由Heroku的工程師提出了；只不過以虛擬機器技術作為雲原生應用的基礎實施，由於虛擬機器映象大、映象標準不統一以及打包流程和工具不統一，無法業界廣泛接受的雲原生應用標準，限制了雲原生應用的流行。而Docker的出現正好解決了這些限制雲原生應用構建、交付和執行的瓶頸，使得構建雲原生應用成為了使用Docker的開發者自然而然的選擇。

單機的Docker引擎和單一的容器映象只能解決單一服務的打包和測試問題。而要執行生產級的企業級應用，就需要容器排程管理系統。在這裡面，Docker技術就彷彿運送系統零件的集裝箱，把雲原生應用的各個標準化零件交付到各個企業的不同碼頭，而容器排程管理系統就是企業應用的執行車間，把不同的零件組裝、執行、維護起來。

Kubernetes(k8s)是Google開源的容器叢集管理系統（谷歌內部:Borg）。在Docker技術的基礎上，為容器化的應用提供部署執行、資源排程、服務發現和動態伸縮等一系列完整功能，提高了大規模容器叢集管理的便捷性。

Kubernetes是為生產環境而設計的容器排程管理系統，對於負載均衡、服務發現、高可用、滾動升級、自動伸縮等容器雲平臺的功能要求有原生支援。由於Kubernetes在K和s間有8個字母，因此常簡稱K8s。

Kubernetes的系統架構

一個K8s叢集是由分散式儲存（etcd）、服務節點（Minion，etcd現在稱為Node）和控制節點（Master）構成的。所有的叢集狀態都儲存在etcd中，Master節點上則執行叢集的管理控制模組。Node節點是真正執行應用容器的主機節點，在每個Minion節點上都會執行一個Kubelet代理，控制該節點上的容器、映象和儲存卷等。

•Kubernetes的核心概念

1.Master

　　k8s叢集的管理節點，負責管理叢集，提供叢集的資源資料訪問入口。擁有Etcd儲存服務（可選），執行Api Server程序，Controller Manager服務程序及Scheduler服務程序，關聯工作節點Node。Kubernetes API server提供HTTP Rest介面的關鍵服務程序，是Kubernetes裡所有資源的增、刪、改、查等操作的唯一入口。也是叢集控制的入口程序；Kubernetes Controller Manager是Kubernetes所有資源物件的自動化控制中心；Kubernetes Schedule是負責資源排程（Pod排程）的程序

2.Node

　　Node是Kubernetes叢集架構中執行Pod的服務節點（亦叫agent或minion）。Node是Kubernetes叢集操作的單元，用來承載被分配Pod的執行，是Pod執行的宿主機。關聯Master管理節點，擁有名稱和IP、系統資源資訊。執行docker eninge服務，守護程序kunelet及負載均衡器kube-proxy.

• 每個Node節點都執行著以下一組關鍵程序
• kubelet：負責對Pod對於的容器的建立、啟停等任務
• kube-proxy：實現Kubernetes Service的通訊與負載均衡機制的重要元件
• Docker Engine（Docker）：Docker引擎，負責本機容器的建立和管理工作

　　Node節點可以在執行期間動態增加到Kubernetes叢集中，預設情況下，kubelet會想master註冊自己，這也是Kubernetes推薦的Node管理方式，kubelet程序會定時向Master彙報自身情報，如作業系統、Docker版本、CPU和記憶體，以及有哪些Pod在執行等等，這樣Master可以獲知每個Node節點的資源使用情況，冰實現高效均衡的資源排程策略。、

3.Pod

　　運行於Node節點上，若干相關容器的組合。Pod內包含的容器執行在同一宿主機上，使用相同的網路名稱空間、IP地址和埠，能夠通過localhost進行通。Pod是Kurbernetes進行建立、排程和管理的最小單位，它提供了比容器更高層次的抽象，使得部署和管理更加靈活。一個Pod可以包含一個容器或者多個相關容器。

　　Pod其實有兩種型別：普通Pod和靜態Pod，後者比較特殊，它並不存在Kubernetes的etcd儲存中，而是存放在某個具體的Node上的一個具體檔案中，並且只在此Node上啟動。普通Pod一旦被建立，就會被放入etcd儲存中，隨後會被Kubernetes Master排程到摸個具體的Node上進行繫結，隨後該Pod被對應的Node上的kubelet程序例項化成一組相關的Docker容器冰啟動起來，在。在預設情況下，當Pod裡的某個容器停止時，Kubernetes會自動檢測到這個問起並且重啟這個Pod（重啟Pod裡的所有容器），如果Pod所在的Node宕機，則會將這個Node上的所有Pod重新排程到其他節點上。

4.Replication Controller

　　Replication Controller用來管理Pod的副本，保證叢集中存在指定數量的Pod副本。叢集中副本的數量大於指定數量，則會停止指定數量之外的多餘容器數量，反之，則會啟動少於指定數量個數的容器，保證數量不變。Replication Controller是實現彈性伸縮、動態擴容和滾動升級的核心。

5.Service

　　Service定義了Pod的邏輯集合和訪問該集合的策略，是真實服務的抽象。Service提供了一個統一的服務訪問入口以及服務代理和發現機制，關聯多個相同Label的Pod，使用者不需要了解後臺Pod是如何執行。

外部系統訪問Service的問題

　　首先需要弄明白Kubernetes的三種IP這個問題

　　　　Node IP：Node節點的IP地址

　　　　Pod IP： Pod的IP地址

　　　　Cluster IP：Service的IP地址

　　首先,Node IP是Kubernetes叢集中節點的物理網絡卡IP地址，所有屬於這個網路的伺服器之間都能通過這個網路直接通訊。這也表明Kubernetes叢集之外的節點訪問Kubernetes叢集之內的某個節點或者TCP/IP服務的時候，必須通過Node IP進行通訊

　　其次，Pod IP是每個Pod的IP地址，他是Docker Engine根據docker0網橋的IP地址段進行分配的，通常是一個虛擬的二層網路。

　　最後Cluster IP是一個虛擬的IP，但更像是一個偽造的IP網路，原因有以下幾點

• Cluster IP僅僅作用於Kubernetes Service這個物件，並由Kubernetes管理和分配P地址
• Cluster IP無法被ping，他沒有一個“實體網路物件”來響應
• Cluster IP只能結合Service Port組成一個具體的通訊埠，單獨的Cluster IP不具備通訊的基礎，並且他們屬於Kubernetes叢集這樣一個封閉的空間。

Kubernetes叢集之內，Node IP網、Pod IP網於Cluster IP網之間的通訊，採用的是Kubernetes自己設計的一種程式設計方式的特殊路由規則。

6.Label

　Kubernetes中的任意API物件都是通過Label進行標識，Label的實質是一系列的Key/Value鍵值對，其中key於value由使用者自己指定。Label可以附加在各種資源物件上，如Node、Pod、Service、RC等，一個資源物件可以定義任意數量的Label，同一個Label也可以被新增到任意數量的資源物件上去。Label是Replication Controller和Service執行的基礎，二者通過Label來進行關聯Node上執行的Pod。

我們可以通過給指定的資源物件捆綁一個或者多個不同的Label來實現多維度的資源分組管理功能，以便於靈活、方便的進行資源分配、排程、配置等管理工作。

一些常用的Label如下：

• 版本標籤："release":"stable","release":"canary"......
• 環境標籤："environment":"dev","environment":"qa","environment":"production"
• 架構標籤："tier":"frontend","tier":"backend","tier":"middleware"
• 分割槽標籤："partition":"customerA","partition":"customerB"
• 質量管控標籤："track":"daily","track":"weekly"

　　Label相當於我們熟悉的標籤，給某個資源物件定義一個Label就相當於給它大了一個標籤，隨後可以通過Label Selector（標籤選擇器）查詢和篩選擁有某些Label的資源物件，Kubernetes通過這種方式實現了類似SQL的簡單又通用的物件查詢機制。

　　Label Selector在Kubernetes中重要使用場景如下:

• • 　　kube-Controller程序通過資源物件RC上定義Label Selector來篩選要監控的Pod副本的數量，從而實現副本數量始終符合預期設定的全自動控制流程
  • 　　kube-proxy程序通過Service的Label Selector來選擇對應的Pod，自動建立起每個Service島對應Pod的請求轉發路由表，從而實現Service的智慧負載均衡
  • 　　通過對某些Node定義特定的Label，並且在Pod定義檔案中使用Nodeselector這種標籤排程策略，kuber-scheduler程序可以實現Pod”定向排程“的特性

Kubernetes架構和元件

•Kubernetes 元件:

　　Kubernetes Master控制組件，排程管理整個系統（叢集），包含如下元件:

　　1.Kubernetes API Server

　　　　作為Kubernetes系統的入口，其封裝了核心物件的增刪改查操作，以RESTful API介面方式提供給外部客戶和內部元件呼叫。維護的REST物件持久化到Etcd中儲存。

　　2.Kubernetes Scheduler

　　　　為新建立的Pod進行節點(node)選擇(即分配機器)，負責叢集的資源排程。元件抽離，可以方便替換成其他排程器。

　　3.Kubernetes Controller

　　　　負責執行各種控制器，目前已經提供了很多控制器來保證Kubernetes的正常執行。

　　4. Replication Controller

　　　　管理維護Replication Controller，關聯Replication Controller和Pod，保證Replication Controller定義的副本數量與實際執行Pod數量一致。

　　5. Node Controller

　　　　管理維護Node，定期檢查Node的健康狀態，標識出(失效|未失效)的Node節點。

　　6. Namespace Controller

　　　　管理維護Namespace，定期清理無效的Namespace，包括Namesapce下的API物件，比如Pod、Service等。

　　7. Service Controller

　　　　管理維護Service，提供負載以及服務代理。

　　8.EndPoints Controller

　　　　管理維護Endpoints，關聯Service和Pod，建立Endpoints為Service的後端，當Pod發生變化時，實時更新Endpoints。

　　9. Service Account Controller

　　　　管理維護Service Account，為每個Namespace建立預設的Service Account，同時為Service Account建立Service Account Secret。

　　10. Persistent Volume Controller

　　　　管理維護Persistent Volume和Persistent Volume Claim，為新的Persistent Volume Claim分配Persistent Volume進行繫結，為釋放的Persistent Volume執行清理回收。

　　11. Daemon Set Controller

　　　　管理維護Daemon Set，負責建立Daemon Pod，保證指定的Node上正常的執行Daemon Pod。

　　12. Deployment Controller

　　　　管理維護Deployment，關聯Deployment和Replication Controller，保證執行指定數量的Pod。當Deployment更新時，控制實現Replication Controller和　Pod的更新。

　　13.Job Controller

　　　　管理維護Job，為Jod建立一次性任務Pod，保證完成Job指定完成的任務數目

　　14. Pod Autoscaler Controller

　　　　實現Pod的自動伸縮，定時獲取監控資料，進行策略匹配，當滿足條件時執行Pod的伸縮動作。

•Kubernetes Node執行節點，執行管理業務容器，包含如下元件:

　　1.Kubelet

　　　　負責管控容器，Kubelet會從Kubernetes API Server接收Pod的建立請求，啟動和停止容器，監控容器執行狀態並彙報給Kubernetes API Server。

　　2.Kubernetes Proxy

　　　　負責為Pod建立代理服務，Kubernetes Proxy會從Kubernetes API Server獲取所有的Service資訊，並根據Service的資訊建立代理服務，實現Service到Pod的請求路由和轉發，從而實現Kubernetes層級的虛擬轉發網路。

　　3.Docker

　　　　Node上需要執行容器服務