K8S 是一個基于容器技術(shù)的分布式集群管理系統(tǒng)稻据，是谷歌幾十年來大規(guī)模應(yīng)用容器技術(shù)的經(jīng)驗積累和升華的一個重要成果艾猜。所以為了能夠支持大規(guī)模的集群管理，它承載了很多的組件捻悯，而且分布式本身的復(fù)雜度就很高匆赃。因為 K8S 是谷歌出品的，依賴了很多谷歌自己的鏡像今缚，所以對于國內(nèi)的同學(xué)環(huán)境搭建的難度又增加了一層算柳。下面，我們帶著問題姓言，一步步來看 K8S 中到底有哪些東西瞬项？首先，既然是個分布式系統(tǒng)何荚，那勢必有多個 Node 節(jié)點（物理主機或虛擬機）囱淋，它們共同組成一個分布式集群，并且這些節(jié)點中會有一個 Master 節(jié)點餐塘，由它來統(tǒng)一管理 Node 節(jié)點妥衣。
如圖所示：
問題一：主節(jié)點和工作節(jié)點是如何通信的呢？
首先戒傻，Master 節(jié)點啟動時税手，會運行一個 kube-apiserver 進(jìn)程，它提供了集群管理的 API 接口需纳，是集群內(nèi)各個功能模塊之間數(shù)據(jù)交互和通信的中心樞紐冈止，并且它頁提供了完備的集群安全機制（后面還會講到）。在 Node 節(jié)點上候齿，使用 K8S 中的 kubelet 組件，在每個 Node 節(jié)點上都會運行一個 kubelet 進(jìn)程，它負(fù)責(zé)向 Master 匯報自身節(jié)點的運行情況慌盯，如 Node 節(jié)點的注冊周霉、終止、定時上報健康狀況等亚皂，以及接收 Master 發(fā)出的命令俱箱，創(chuàng)建相應(yīng) Pod。在 K8S 中灭必，Pod 是最基本的操作單元狞谱，它與 docker 的容器有略微的不同，因為 Pod 可能包含一個或多個容器（可以是 docker 容器）禁漓，這些內(nèi)部的容器是共享網(wǎng)絡(luò)資源的跟衅，即可以通過 localhost 進(jìn)行相互訪問。關(guān)于 Pod 內(nèi)是如何做到網(wǎng)絡(luò)共享的播歼，每個 Pod 啟動伶跷，內(nèi)部都會啟動一個 pause 容器（google的一個鏡像），它使用默認(rèn)的網(wǎng)絡(luò)模式秘狞，而其他容器的網(wǎng)絡(luò)都設(shè)置給它叭莫，以此來完成網(wǎng)絡(luò)的共享問題。
如圖所示：
問題二：Master 是如何將 Pod 調(diào)度到指定的 Node 上的烁试？
該工作由 kube-scheduler 來完成雇初，整個調(diào)度過程通過執(zhí)行一些列復(fù)雜的算法最終為每個 Pod 計算出一個最佳的目標(biāo) Node，該過程由 kube-scheduler 進(jìn)程自動完成减响。常見的有輪詢調(diào)度（RR）靖诗。當(dāng)然也有可能，我們需要將 Pod 調(diào)度到一個指定的 Node 上辩蛋，我們可以通過節(jié)點的標(biāo)簽（Label）和 Pod 的 nodeSelector 屬性的相互匹配呻畸，來達(dá)到指定的效果。
如圖所示：
問題三：各節(jié)點悼院、Pod 的信息都是統(tǒng)一維護(hù)在哪里的伤为，由誰來維護(hù)？
從上面的 Pod 調(diào)度的角度看据途，我們得有一個存儲中心绞愚，用來存儲各節(jié)點資源使用情況、健康狀態(tài)颖医、以及各 Pod 的基本信息等位衩，這樣 Pod 的調(diào)度來能正常進(jìn)行。在 K8S 中熔萧，采用 etcd 組件 作為一個高可用強一致性的存儲倉庫糖驴，該組件可以內(nèi)置在 K8S 中僚祷，也可以外部搭建供 K8S 使用。集群上的所有配置信息都存儲在了 etcd贮缕，為了考慮各個組件的相對獨立辙谜，以及整體的維護(hù)性，對于這些存儲數(shù)據(jù)的增感昼、刪装哆、改、查定嗓，統(tǒng)一由 kube-apiserver 來進(jìn)行調(diào)用蜕琴，apiserver 也提供了 REST 的支持，不僅對各個內(nèi)部組件提供服務(wù)外宵溅，還對集群外部用戶暴露服務(wù)凌简。外部用戶可以通過 REST 接口，或者 kubectl 命令行工具進(jìn)行集群管理层玲，其內(nèi)在都是與 apiserver 進(jìn)行通信号醉。
如圖所示：
問題四：外部用戶如何訪問集群內(nèi)運行的 Pod ？
前面講了外部用戶如何管理 K8S辛块，而我們更關(guān)心的是內(nèi)部運行的 Pod 如何對外訪問畔派。使用過 docker 的應(yīng)該知道，如果使用 bridge 模式润绵，在容器創(chuàng)建時线椰，都會分配一個虛擬 IP，該 IP 外部是沒法訪問到的尘盼，我們需要做一層端口映射憨愉，將容器內(nèi)端口與宿主機端口進(jìn)行映射綁定，這樣外部通過訪問宿主機的指定端口卿捎，就可以訪問到內(nèi)部容器端口了配紫。
那么，K8S 的外部訪問是否也是這樣實現(xiàn)的午阵？答案是否定的躺孝，K8S 中情況要復(fù)雜一些。因為上面講的 docker 是單機模式下的底桂，而且一個容器對外就暴露一個服務(wù)植袍。在分布式集群下，一個服務(wù)往往由多個 Application 提供籽懦，用來分擔(dān)訪問壓力于个，而且這些 Application 可能會分布在多個節(jié)點上，這樣又涉及到了跨主機的通信暮顺。
這里厅篓，K8S 引入了 service 的概念秀存，將多個相同的 Pod 包裝成一個完整的 service 對外提供服務(wù)，至于獲取到這些相同的 Pod贷笛，每個 Pod 啟動時都會設(shè)置 labels 屬性应又，在 service 中我們通過選擇器 selector，選擇具有相同 name 標(biāo)簽屬性的 Pod乏苦，作為整體服務(wù)，并將服務(wù)信息通過 apiserver 存入 etcd 中尤筐，該工作由 Service Controller 來完成汇荐。同時，每個節(jié)點上會啟動一個 kube-proxy 進(jìn)程盆繁，由它來負(fù)責(zé)服務(wù)地址到 Pod 地址的代理以及負(fù)載均衡等工作掀淘。
如圖所示：
問題五：Pod 如何動態(tài)擴(kuò)容和縮放？
既然知道了服務(wù)是由 Pod 組成的油昂，那么服務(wù)的擴(kuò)容也就意味著 Pod 的擴(kuò)容革娄。通俗點講，就是在需要時將 Pod 復(fù)制多份冕碟，在不需要后拦惋，將 Pod 縮減至指定份數(shù)。K8S 中通過 Replication Controller 來進(jìn)行管理安寺，為每個 Pod 設(shè)置一個期望的副本數(shù)厕妖，當(dāng)實際副本數(shù)與期望不符時，就動態(tài)的進(jìn)行數(shù)量調(diào)整挑庶，以達(dá)到期望值言秸。期望數(shù)值可以由我們手動更新，或自動擴(kuò)容代理來完成迎捺。
如圖所示：
問題六：各個組件之間是如何相互協(xié)作的举畸？
最后，講一下 kube-controller-manager 這個進(jìn)程的作用凳枝。我們知道了 ectd 是作為集群數(shù)據(jù)的存儲中心抄沮， apiserver 是管理數(shù)據(jù)中心，作為其他進(jìn)程與數(shù)據(jù)中心通信的橋梁范舀。
而 Service Controller合是、Replication Controller 這些統(tǒng)一交由 kube-controller-manager 來管理，kube-controller-manager 作為一個守護(hù)進(jìn)程锭环，每個 Controller 都是一個控制循環(huán)聪全，通過 apiserver 監(jiān)視集群的共享狀態(tài)，并嘗試將實際狀態(tài)與期望不符的進(jìn)行改變辅辩。
關(guān)于 Controller难礼，manager 中還包含了 Node 節(jié)點控制器（Node Controller）娃圆、資源配額管控制器（ResourceQuota Controller）、命名空間控制器（Namespace Controller）等蛾茉。
如圖所示：
總結(jié)
本文通過問答的方式讼呢，沒有涉及任何深入的實現(xiàn)細(xì)節(jié)，從整體的角度谦炬，概念性的介紹了 K8S 中涉及的基本概念悦屏，其中使用相關(guān)的包括有：
- Node
- Pod
- Label
- Selector
- Replication Controller
- Service Controller
- ResourceQuota Controller
- Namespace Controller
- Node Controller
以及運行進(jìn)程相關(guān)的有：
kube-apiserver
kube-controller-manager
kube-scheduler
kubelet
kube-proxy
pause
學(xué)習(xí) K8S 后對其整體架構(gòu)的一次總結(jié)，文中有不到位的地方键思，歡迎指正础爬！
