title: Kubernetes之初探
subtitle: K8s的工作原理
date: 2018-09-18 18:26:37
K8s概述
我清晰地記得曾經讀到過的一篇博文，上面是這樣寫的，
“雲端教父AWS雲端架構策略副總裁Adrian Cockcroft曾指出，兩者雖然都是運用容器技術，但最大的差異是，Docker是要解決應用程序開發（Developing）問題，而Kubernetes是要解決更上層的應用程序運維問題（Operation）。開發問題是早期的痛點，但隨着企業越來越依賴容器技術，內部應用越來越多是雲原生應用時，運維會是企業IT的新痛點。”大佬的一番話，明確地指出K8S的生存土壤！
學習一項技術，除了需要明確這項技術的應用場景和發展方向之外，最主要的是理解她的工作原理。
K8s的工作原理
1. 什么是K8s
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的開源版本。使用K8s提供的解決方案，可以節省大概30%的開發成本，可以將精力更加集中於業務本身。
2. 用法
使用Kubernetes可以：
- 自動化容器的部署和復制
- 隨時擴展或收縮容器規模
- 將容器組織成組，並且提供容器間的負載均衡
- 很容易地升級應用程序容器的新版本
- 提供容器彈性，如果容器失效就替換它，等等...
3. 核心概念
1) 集群
在集群管理方面，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）（服務）
2) 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。
3) 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使用的容器技術來創建容器。
4) 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
5) Lable
Lable類似Docker中的tag，一個是對“特殊”鏡像、容器、卷組等各種資源做標記，一個是attach到各種諸如Node、Pod、Server、RC資源對象上。不同的是Lable是一對鍵值對！Lable類似Tag，可使用K8s專有的標簽選擇器（Label Selector）進行組合查詢。
6) 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
微服務架構中的一個“微服務”，她是正真的新娘，而之前的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域名映射即可完美解決問題。
版本問題
| 初始版本 | 2014年6月7日，4年前 |
|---|---|
| 穩定版本 | 1.10.3（2018年5月21日，3個月前) |
| 開發狀態 | 活躍 |
| 編程語言 | Go |
| 操作系統 | 跨平台 |
| 類型 | 集群管理 |
| 許可協議 | Apache許可證 2.0 |
| 網站 | kubernetes.io |
| 源代碼庫 | github.com/kubernetes/kubernetes |