來自公眾號：51CTO技術(shù)棧
作者簡介：十六年開發(fā)和架構(gòu)經(jīng)驗，曾擔(dān)任過惠普武漢交付中心技術(shù)專家勤讽，需求分析師蟋座，項目經(jīng)理，后在創(chuàng)業(yè)公司擔(dān)任技術(shù)/產(chǎn)品經(jīng)理脚牍。善于學(xué)習(xí)向臀，樂于分享。目前專注于技術(shù)架構(gòu)與研發(fā)管理莫矗。
“
互聯(lián)網(wǎng)技術(shù)飛速發(fā)展的今天飒硅，為了承載請求的高并發(fā)和業(yè)務(wù)的多樣性，微服務(wù)的架構(gòu)成了各個公司的標(biāo)配作谚。
每個微服務(wù)通過 Docker 進(jìn)行發(fā)布三娩，隨著業(yè)務(wù)的發(fā)展，系統(tǒng)中遍布著各種各樣的容器妹懒。于是雀监，容器的資源調(diào)度，部署運(yùn)行眨唬，擴(kuò)容縮容就是我們要面臨的問題会前。
基于 Kubernetes 作為容器集群的管理平臺被廣泛應(yīng)用，今天我們一起來看看 Kubernetes 的架構(gòu)中有那些常用的組件以及運(yùn)行原理匾竿。
Kubernetes 架構(gòu)概述
Kubernetes 是用來管理容器集群的平臺瓦宜。既然是管理集群，那么就存在被管理節(jié)點岭妖，針對每個 Kubernetes 集群都由一個 Master 負(fù)責(zé)管理和控制集群節(jié)點临庇。
我們通過 Master 對每個節(jié)點 Node 發(fā)送命令。簡單來說昵慌，Master 就是管理者假夺，Node 就是被管理者。
Node 可以是一臺機(jī)器或者一臺虛擬機(jī)斋攀。在 Node 上面可以運(yùn)行多個 Pod已卷，Pod 是 Kubernetes 管理的最小單位，同時每個 Pod 可以包含多個容器（Docker）淳蔼。
通過下面的 Kubernetes 架構(gòu)簡圖可以看到 Master 和 Node 之間的關(guān)系：Kubernetes 架構(gòu)簡圖
通常我們都是通過 kubectl 對 Kubernetes 下命令的侧蘸，它通過 APIServer 去調(diào)用各個進(jìn)程來完成對 Node 的部署和控制裁眯。
APIServer 的核心功能是對核心對象（例如：Pod，Service讳癌，RC）的增刪改查操作未状，同時也是集群內(nèi)模塊之間數(shù)據(jù)交換的樞紐。
它包括了常用的 API析桥，訪問（權(quán)限）控制，注冊艰垂，信息存儲（etcd）等功能泡仗。在它的下面我們可以看到 Scheduler，它將待調(diào)度的 Pod 綁定到 Node 上猜憎，并將綁定信息寫入 etcd 中娩怎。
etcd 包含在 APIServer 中，用來存儲資源信息胰柑。接下來就是 Controller Manager 了截亦，如果說 Kubernetes 是一個自動化運(yùn)行的系統(tǒng)，那么就需要有一套管理規(guī)則來控制這套系統(tǒng)柬讨。
Controller Manager 就是這個管理者崩瓤，或者說是控制者。它包括 8 個 Controller踩官，分別對應(yīng)著副本却桶，節(jié)點，資源蔗牡，命名空間颖系，服務(wù)等等。
緊接著辩越，Scheduler 會把 Pod 調(diào)度到 Node 上嘁扼，調(diào)度完以后就由 kubelet 來管理 Node 了。
kubelet 用于處理 Master 下發(fā)到 Node 的任務(wù)（即 Scheduler 的調(diào)度任務(wù)）黔攒，同時管理 Pod 及 Pod 中的容器趁啸。
在完成資源調(diào)度以后，kubelet 進(jìn)程也會在 APIServer 上注冊 Node 信息亏钩，定期向 Master 匯報 Node 信息莲绰，并通過 cAdvisor 監(jiān)控容器和節(jié)點資源。
由于姑丑，微服務(wù)的部署都是分布式的蛤签，所以對應(yīng)的 Pod 以及容器的部署也是。為了能夠方便地找到這些 Pod 或者容器栅哀，引入了 Service（kube-proxy）進(jìn)程震肮，它來負(fù)責(zé)反向代理和負(fù)載均衡的實施称龙。
上面就是 Kubernetes 架構(gòu)的簡易說明，涉及到了一些核心概念以及簡單的信息流動戳晌。
將一些功能收錄到了 APIServer 中鲫尊，這個簡圖比官網(wǎng)的圖顯得簡單一些，主要是方便大家記憶沦偎。
后面我們會用一個簡單的例子疫向，帶大家把 Kubernetes 的概念的由來做深入的了解。
從一個例子開始
假設(shè)使用 Kubernetes 部署 Tomcat 和 MySQL 服務(wù)到兩個 Node 上面豪嚎。其中 Tomcat 服務(wù)生成兩個實例也就是生成兩個 Pod搔驼，用來對其做水平擴(kuò)展。
MySQL 只部署一個實例侈询，也就是一個 Pod舌涨。可以通過外網(wǎng)訪問 Tomcat扔字，而 Tomcat 可以在內(nèi)網(wǎng)訪問 MySQL囊嘉。例子示意圖
這里我們假設(shè) Kubernetes 和 Docker 的安裝都已經(jīng)完成，并且鏡像文件都已經(jīng)準(zhǔn)備好了革为。重點看 Kubernetes 如何部署和管理容器扭粱。
kubectl 和 APIServer
既然我們要完成上面的例子，接下來就要部署兩個應(yīng)用震檩。
首先焊刹，根據(jù)要部署的應(yīng)用建立 Replication Controller（RC）。RC 是用來聲明應(yīng)用副本的個數(shù)恳蹲，也就是 Pod 的個數(shù)虐块。
按照上面的例子，Tomcat 的 RC 就是 2嘉蕾，MySQL 的 RC 就是 1贺奠。
由于 kubectl 作為用戶接口向 Kubernetes 下發(fā)指令，那么指令是通過“.yaml”的配置文件編寫的错忱。
定義 mysql-rc.yaml 的配置文件來描述 MySQL 的 RC：從上面的配置文件可以看出儡率，需要對這個 RC 定義一個名字，以及期望的副本數(shù)以清，以及容器中的鏡像文件儿普。然后通過 kubectl 作為客戶端的 cli 工具，執(zhí)行這個配置文件掷倔。通過 kubectl 執(zhí)行 RC 配置文件
執(zhí)行了上面的命令以后眉孩，Kubernetes 會幫助我們部署副本 MySQL 的 Pod 到 Node。
此時先不著急看結(jié)果，回到最開始的架構(gòu)圖浪汪，可以看到 kubectl 會向 Master 中的 APIServer 發(fā)起命令巴柿，看看 APIServer 的結(jié)構(gòu)和信息的傳遞吧。Kubernetes API Server 通過一個名為 kube-apiserver 的進(jìn)程提供服務(wù)死遭，該進(jìn)程運(yùn)行在 Master 上广恢。
可以通過 Master 的 8080 端口訪問 kube-apiserver 進(jìn)程，它提供 REST 服務(wù)呀潭。
因此可以通過命令行工具 kubectl 來與 Kubernetes APIServer 交互钉迷，它們之間的接口是 RESTful API。
APIServer 的架構(gòu)從上到下分為四層：
API 層：主要以 REST 方式提供各種 API 接口钠署，針對 Kubernetes 資源對象的 CRUD 和 Watch 等主要 API篷牌，還有健康檢查、UI踏幻、日志、性能指標(biāo)等運(yùn)維監(jiān)控相關(guān)的 API戳杀。
訪問控制層：負(fù)責(zé)身份鑒權(quán)该面，核準(zhǔn)用戶對資源的訪問權(quán)限，設(shè)置訪問邏輯（Admission Control）信卡。
注冊表層：選擇要訪問的資源對象隔缀。PS：Kubernetes 把所有資源對象都保存在注冊表（Registry）中，例如：Pod傍菇，Service猾瘸，Deployment 等等。
etcd 數(shù)據(jù)庫：保存創(chuàng)建副本的信息丢习。用來持久化 Kubernetes 資源對象的 Key-Value 數(shù)據(jù)庫牵触。
APIServer 分層架構(gòu)圖
當(dāng) kubectl 用 Create 命令建立 Pod 時，是通過 APIServer 中的 API 層調(diào)用對應(yīng)的 RESTAPI 方法咐低。
之后會進(jìn)入權(quán)限控制層揽思，通過 Authentication 獲取調(diào)用者身份，Authorization 獲取權(quán)限信息见擦。
AdmissionControl 中可配置權(quán)限認(rèn)證插件钉汗，通過插件來檢查請求約束凰慈。例如：啟動容器之前需要下載鏡像捌治，或者檢查具備某命名空間的資源。
還記得 mysql-rc.yaml 中配置需要生成的 Pod 的個數(shù)為 1审磁。到了 Registry 層會從 CoreRegistry 資源中取出 1 個 Pod 作為要創(chuàng)建的 Kubernetes 資源對象酒来。
然后將 Node卢未，Pod 和 Container 信息保存在 etcd 中去。這里的 etcd 可以是一個集群堰汉，由于里面保存集群中各個 Node/Pod/Container 的信息尝丐，所以必要時需要備份显拜，或者保證其可靠性。
Controller Manager爹袁，Scheduler 和 kubelet
前面通過 kubectl 根據(jù)配置文件远荠，向 APIServer 發(fā)送命令，在 Node 上面建立 Pod 和 Container失息。
在 APIServer譬淳，經(jīng)過 API 調(diào)用，權(quán)限控制盹兢，調(diào)用資源和存儲資源的過程邻梆。實際上還沒有真正開始部署應(yīng)用。
這里需要 Controller Manager绎秒，Scheduler 和 kubelet 的協(xié)助才能完成整個部署過程浦妄。
在介紹他們協(xié)同工作之前，要介紹一下在 Kubernetes 中的監(jiān)聽接口见芹。從上面的操作知道剂娄，所有部署的信息都會寫到 etcd 中保存。
實際上 etcd 在存儲部署信息的時候玄呛，會發(fā)送 Create 事件給 APIServer阅懦，而 APIServer 會通過監(jiān)聽（Watch）etcd 發(fā)過來的事件。其他組件也會監(jiān)聽（Watch）APIServer 發(fā)出來的事件徘铝。Kubernetes 就是用這種 List-Watch 的機(jī)制保持?jǐn)?shù)據(jù)同步的耳胎，如上圖：
這里有三個 List-Watch，分別是 kube-controller-manager（運(yùn)行在Master）惕它，kube-scheduler（運(yùn)行在 Master）怕午，kublete（運(yùn)行在 Node）。他們在進(jìn)程已啟動就會監(jiān)聽（Watch）APIServer 發(fā)出來的事件淹魄。
kubectl 通過命令行诗轻，在 APIServer 上建立一個 Pod 副本。
這個部署請求被記錄到 etcd 中揭北，存儲起來扳炬。
當(dāng) etcd 接受創(chuàng)建 Pod 信息以后，會發(fā)送一個 Create 事件給 APIServer搔体。
由于 Kubecontrollermanager 一直在監(jiān)聽 APIServer 中的事件恨樟。此時 APIServer 接受到了 Create 事件，又會發(fā)送給 Kubecontrollermanager疚俱。
-
Kubecontrollermanager 在接到 Create 事件以后劝术，調(diào)用其中的 Replication Controller 來保證 Node 上面需要創(chuàng)建的副本數(shù)量。
上面的例子 MySQL 應(yīng)用是 1 個副本，Tomcat 應(yīng)用是兩個副本养晋。一旦副本數(shù)量少于 RC 中定義的數(shù)量衬吆，Replication Controller 會自動創(chuàng)建副本∩總之它是保證副本數(shù)量的 Controller逊抡。PS：擴(kuò)容縮容的擔(dān)當(dāng)。
在 Controller Manager 創(chuàng)建 Pod 副本以后零酪，APIServer 會在 etcd 中記錄這個 Pod 的詳細(xì)信息冒嫡。例如在 Pod 的副本數(shù)，Container 的內(nèi)容是什么四苇。
同樣的 etcd 會將創(chuàng)建 Pod 的信息通過事件發(fā)送給 APIServer孝凌。
-
由于 Scheduler 在監(jiān)聽（Watch）APIServer，并且它在系統(tǒng)中起到了“承上啟下”的作用月腋，“承上”是指它負(fù)責(zé)接收創(chuàng)建的 Pod 事件蟀架，為其安排 Node；“啟下”是指安置工作完成后榆骚，Node 上的 kubelet 服務(wù)進(jìn)程接管后繼工作片拍，負(fù)責(zé) Pod 生命周期中的“下半生”。
換句話說寨躁，Scheduler 的作用是將待調(diào)度的 Pod 按照調(diào)度算法和策略綁定到集群中 Node 上，并將綁定信息寫入 etcd 中牙勘。
Scheduler 調(diào)度完畢以后會更新 Pod 的信息职恳，此時的信息更加豐富了。除了知道 Pod 的副本數(shù)量方面，副本內(nèi)容放钦。還知道部署到哪個 Node 上面了。
同樣恭金，將上面的 Pod 信息更新到 etcd 中操禀，保存起來。
etcd 將更新成功的事件發(fā)送給 APIServer横腿。
-
注意這里的 kubelet 是在 Node 上面運(yùn)行的進(jìn)程颓屑，它也通過 List-Watch 的方式監(jiān)聽（Watch）APIServer 發(fā)送的 Pod 更新的事件。實際上耿焊，在第 9 步的時候創(chuàng)建 Pod 的工作就已經(jīng)完成了揪惦。
為什么 kubelete 還要一直監(jiān)聽呢？原因很簡單罗侯，假設(shè)這個時候 kubectl 發(fā)命令器腋，需要把原來的 MySQL 的 1 個 RC 副本擴(kuò)充成 2 個。那么這個流程又會觸發(fā)一遍。
作為 Node 的管理者 kubelet 也會根據(jù)最新的 Pod 的部署情況調(diào)整 Node 端的資源纫塌。
又或者 MySQL 應(yīng)用的 RC 個數(shù)沒有發(fā)生變化诊县，但是其中的鏡像文件升級了，kubelet 也會自動獲取最新的鏡像文件并且加載措左。
聚焦 Scheduler抗悍，Controller Manager，kubelet
Controller Manager
Kubernetes 需要管理集群中的不同資源钳枕，所以針對不同的資源要建立不同的 Controller缴渊。每個 Controller 通過監(jiān)聽機(jī)制獲取 APIServer 中的事件（消息），它們通過 API Server 提供的（List-Watch）接口監(jiān)控集群中的資源鱼炒，并且調(diào)整資源的狀態(tài)衔沼。可以把它想象成一個盡職的管理者昔瞧，隨時管理和調(diào)整資源指蚁。比如 MySQL 所在的 Node 意外宕機(jī)了，Controller Manager 中的 Node Controller 會及時發(fā)現(xiàn)故障自晰，并執(zhí)行修復(fù)流程凝化。在部署了成百上千微服務(wù)的系統(tǒng)中，這個功能極大地協(xié)助了運(yùn)維人員酬荞。從此可以看出搓劫，Controller Manager 是 Kubernetes 資源的管理者，是運(yùn)維自動化的核心混巧。
它分為 8 個 Controller枪向，上面我們介紹了 Replication Controller，這里我們把其他幾個都列出來咧党，就不展開描述了秘蛔。
Controller Manager 中不同的 Controller 負(fù)責(zé)對不同資源的監(jiān)控和管理
Scheduler 與 kubelet
Scheduler 的作用是，將待調(diào)度的 Pod 按照算法和策略綁定到 Node 上傍衡，同時將信息保存在 etcd 中深员。如果把 Scheduler 比作調(diào)度室，那么這三件事就是它需要關(guān)注的蛙埂，待調(diào)度的 Pod辨液、可用的 Node，調(diào)度算法和策略箱残。簡單地說滔迈，就是通過調(diào)度算法/策略把 Pod 放到合適的 Node 中去止吁。此時 Node 上的 kubelet 通過 APIServer 監(jiān)聽到 Scheduler 產(chǎn)生的 Pod 綁定事件，然后通過 Pod 的描述裝載鏡像文件燎悍，并且啟動容器敬惦。也就是說 Scheduler 負(fù)責(zé)思考，Pod 放在哪個 Node谈山，然后將決策告訴 kubelet俄删，kubelet 完成 Pod 在 Node 的加載工作。
說白了奏路，Scheduler 是 boss畴椰，kubelet 是干活的工人，他們都通過 APIServer 進(jìn)行信息交換鸽粉。
Scheduler 與 kubelet 協(xié)同工作圖
Service 和 kubelet
經(jīng)歷上面一系列的過程斜脂，終于將 Pod 和容器部署到 Node 上了。
MySQL 部署成功作為部署在 Kubernetes 中触机，Pod 如何訪問其他的 Pod 呢帚戳？答案是通過 Kubernetes 的 Service 機(jī)制。在 Kubernetes 中的 Service 定義了一個服務(wù)的訪問入口地址（IP+Port）儡首。Pod 中的應(yīng)用通過這個地址訪問一個或者一組 Pod 副本片任。
Service 與后端 Pod 副本集群之間是通過 Label Selector 來實現(xiàn)連接的。Service 所訪問的這一組 Pod 都會有同樣的 Label蔬胯，通過這樣的方法知道這些 Pod 屬于同一個組对供。
Pod 通過 Service 訪問其他 Pod
寫 MySQL 服務(wù)的配置文件（mysql-svc.yaml）如下：
按照慣例運(yùn)行 kubectl，創(chuàng)建 Service：
再用 getsvc 命令檢查 Service 信息：
這里的 Cluster-IP 169.169.253.143 是由 Kubernetes 自動分配的氛濒。當(dāng)一個 Pod 需要訪問其他的 Pod 的時候就需要通過 Service 的 Cluster-IP 和 Port产场。也就是說 Cluster-IP 和 Port 是 Kubernetes 集群的內(nèi)部地址，是提供給集群內(nèi)的 Pod 之間訪問使用的泼橘，外部系統(tǒng)是無法通過這個 Cluster-IP 來訪問 Kubernetes 中的應(yīng)用的涝动。上面提到的 Service 只是一個概念迈勋，而真正將 Service 落實的是 kube-proxy炬灭。只有理解了 kube-proxy 的原理和機(jī)制，我們才能真正理解 Service 背后的實現(xiàn)邏輯靡菇。在 Kubernetes 集群的每個 Node 上都會運(yùn)行一個 kube-proxy 服務(wù)進(jìn)程重归，我們可以把這個進(jìn)程看作 Service 的負(fù)載均衡器，其核心功能是將到 Service 的請求轉(zhuǎn)發(fā)到后端的多個 Pod 上厦凤。此外鼻吮，Service 的 Cluster-IP 與 NodePort 是 kube-proxy 服務(wù)通過 iptables 的 NAT 轉(zhuǎn)換實現(xiàn)的。kube-proxy 在運(yùn)行過程中動態(tài)創(chuàng)建與 Service 相關(guān)的 iptables 規(guī)則较鼓。由于 iptables 機(jī)制針對的是本地的 kube-proxy 端口椎木，所以在每個 Node 上都要運(yùn)行 kube-proxy 組件违柏。
因此在 Kubernetes 集群內(nèi)部，可以在任意 Node 上發(fā)起對 Service 的訪問請求香椎。
集群內(nèi)部通過 kube-proxy（Service）訪問其他 Pod正如 MySQL 服務(wù)漱竖，可以被 Kubernetes 內(nèi)部的 Tomcat 調(diào)用，那么 Tomcat 如何被 Kubernetes 外部調(diào)用畜伐？
先生成配置文件馍惹，myweb-rc.yaml 看看：
在 kubectl 中使用 Create 建立 myweb 副本。
副本創(chuàng)建完畢以后玛界，創(chuàng)建對應(yīng)的服務(wù)配置文件 myweb-svc.yaml万矾。
同樣在 kubectl 中運(yùn)行 Create 命令，建立 Service 資源慎框。
從上面的配置文件可以看出良狈，Tomcat 的 Service 中多了一個 nodePort 的配置，值為 30001鲤脏。也就是說外網(wǎng)通過 30001 這個端口加上 NodeIP 就可以訪問 Tomcat 了们颜。運(yùn)行命令之后，得到一個提示猎醇，大致意思是“如果你要將服務(wù)暴露給外網(wǎng)使用窥突，你需要設(shè)置防火墻規(guī)則讓 30001 端口能夠通行×蛩唬”由于 Cluster-IP 是一個虛擬的 IP阻问，僅供 Kubernetes 內(nèi)部的 Pod 之間的通信。Node 作為一個物理節(jié)點沦疾，因此需要使用 Node-IP 和 nodePort 的組合來從 Kubernetes 外面訪問內(nèi)部的應(yīng)用称近。
如果按照上面的配置，部署了兩個 Tomcat 應(yīng)用哮塞，當(dāng)外網(wǎng)訪問時選擇那個 Pod 呢刨秆？這里需要通過 Kubernetes 之外的負(fù)載均衡器來實現(xiàn)的。
Kubernetes 之外的負(fù)載均衡器可以通過 Kubernetes 的 LoadBlancerService 組件來協(xié)助實現(xiàn)忆畅。通過云平臺申請創(chuàng)建負(fù)載均衡器衡未，向外暴露服務(wù)。目前 LoadBlancerService 組件支持的云平臺比較完善家凯，比如國外的 GCE缓醋、DigitalOcean，國內(nèi)的阿里云绊诲，私有云 OpenStack 等等送粱。從用法上只要把 Service 的 type=NodePort 改為 type=LoadBalancer，Kubernetes 就會自動創(chuàng)建一個對應(yīng)的 Load Balancer 實例并返回它的 IP 地址供外部客戶端使用掂之。
至此抗俄，MySQL（RC 1）和 Tomcat（RC 2）已經(jīng)在 Kubernetes 部署了脆丁。并在 Kubernetes 內(nèi)部 Pod 之間是可以互相訪問的，在外網(wǎng)也可以訪問到 Kubernetes 內(nèi)部的 Pod动雹。
Pod 在 Kubernetes 內(nèi)互相訪問偎快，外網(wǎng)訪問 Pod另外，作為資源監(jiān)控 Kubernetes 在每個 Node 和容器上都運(yùn)行了 cAdvisor洽胶。它是用來分析資源使用率和性能的工具晒夹，支持 Docker 容器。kubelet 通過 cAdvisor 獲取其所在 Node 及容器（Docker）的數(shù)據(jù)姊氓。cAdvisor 自動采集 CPU丐怯、內(nèi)存、文件系統(tǒng)和網(wǎng)絡(luò)使用的統(tǒng)計信息翔横。kubelet 作為 Node 的管理者读跷，把 cAdvisor 采集上來的數(shù)據(jù)通過 RESTAPI 的形式暴露給 Kubernetes 的其他資源，讓他們知道 Node/Pod 中的資源使用情況禾唁。
總結(jié)
由于微服務(wù)的迅猛發(fā)展效览，Kubernetes 作為微服務(wù)治理平臺被廣泛應(yīng)用。由于其發(fā)展時間長荡短，包含服務(wù)功能多我們無法一一列出丐枉。因此，從一個簡單的創(chuàng)建應(yīng)用副本的例子入手掘托，介紹了各個重要組件的概念和基本原理瘦锹。Kubernetes 是用來管理容器集群的，Master 作為管理者闪盔，包括 APIServer弯院，Scheduler，Controller Manager泪掀。Node作為副本部署的載體听绳，包含多個 Pod，每個 Pod 又包含多個容器（container）异赫。用戶通過 kubectl 給 Master 中的 APIServer 下部署命令椅挣。命令主體是以“.yaml”結(jié)尾的配置文件，包含副本的類型祝辣，副本個數(shù)贴妻，名稱切油，端口蝙斜，模版等信息。APIServer 接受到請求以后澎胡，會分別進(jìn)行以下操作：權(quán)限驗證（包括特殊控制）孕荠，取出需要創(chuàng)建的資源娩鹉，保存副本信息到etcd。APIServer 和 Controller Manager稚伍，Scheduler 以及 kubelete 之間通過 List-Watch 方式通信（事件發(fā)送與監(jiān)聽）弯予。Controller Manager 通過 etcd 獲取需要創(chuàng)建資源的副本數(shù)，交由 Scheduler 進(jìn)行策略分析个曙。最后 kubelet 負(fù)責(zé)最終的 Pod 創(chuàng)建和容器加載锈嫩。部署好容器以后，通過 Service 進(jìn)行訪問垦搬，通過 cAdvisor 監(jiān)控資源呼寸。
