這一篇 K8S（Kubernetes）我覺得你可以了解一下
什么是Kubernetes?
Kubernetes 是Google開源的分布式容器管理平臺，是為了更方便的在服務(wù)器中管理我們的容器化應(yīng)用。
Kubernetes 簡稱 K8S，為什么會(huì)有這個(gè)稱號?因?yàn)镵和S是 Kubernetes 首字母和尾字母，而K和S中間有八個(gè)字母，所以簡稱 K8S，加上 Kubernetes比較繞口，所以一般使用簡稱 K8S。
Kubernetes 即是一款容器編排工具，也是一個(gè)全新的基于容器技術(shù)的分布式架構(gòu)方案，在基于Docker的基礎(chǔ)上，可以提供從 創(chuàng)建應(yīng)用>應(yīng)用部署>提供服務(wù)>動(dòng)態(tài)伸縮>應(yīng)用更新一系列服務(wù)，提高了容器集群管理的便捷性。
K8S產(chǎn)生的原因
大家可以先看一下，下面一張圖，里面有我們的 mysql，redis，tomcat，nginx等配置信息，如果我們想要安裝里面的數(shù)據(jù)，我們需要一個(gè)一個(gè)手動(dòng)安裝，好像也可以，反正也就一個(gè)，雖然麻煩了一點(diǎn)，但也不耽誤。
但是隨著技術(shù)的發(fā)展和業(yè)務(wù)的需要，單臺服務(wù)器已經(jīng)不能滿足我們?nèi)粘５男枰耍絹碓蕉嗟墓?，更多需要的是集群環(huán)境和多容器部署，那么如果還是一個(gè)一個(gè)去部署，運(yùn)維恐怕要瘋掉了，一天啥也不干就去部署機(jī)器了，有時(shí)候，可能因?yàn)槟骋粋€(gè)環(huán)節(jié)出錯(cuò)，要重新，那真的是吐血。。。。。，如下圖所示：
如果我想要部署，以下幾臺機(jī)器：
- 3臺 - Nginx
- 5臺 - Redis
- 7臺 - ZooKeeper
- 4臺 - Tomcat
- 6臺 - MySql
- 5臺 - JDK
- 10臺 - 服務(wù)器
如果要一個(gè)一個(gè)去部署，人都要傻掉了，這什么時(shí)候是個(gè)頭，如果是某里巴的兩萬臺機(jī)器，是不是要當(dāng)場提交辭職信，所以 K8S 就是幫助我們來做這些事情的，方便我們對容器的管理和應(yīng)用的自動(dòng)化部署，減少重復(fù)勞動(dòng)，并且能夠自動(dòng)化部署應(yīng)用和故障自愈。
并且如果 K8S 對于微服務(wù)有很好的支持，并且一個(gè)微服務(wù)的副本可以跟著系統(tǒng)的負(fù)荷變化進(jìn)行調(diào)整，K8S 內(nèi)在的服務(wù)彈性擴(kuò)容機(jī)制也能夠很好的應(yīng)對突發(fā)流量。
容器編排工具對比
Docker-Compose
Docker-Compose 是用來管理容器的，類似用戶容器管家，我們有N多臺容器或者應(yīng)用需要啟動(dòng)的時(shí)候，如果手動(dòng)去操作，是非常耗費(fèi)時(shí)間的，如果有了 Docker-Compose 只需要一個(gè)配置文件就可以幫我們搞定，但是 Docker-Compose 只能管理當(dāng)前主機(jī)上的 Docker，不能去管理其他服務(wù)器上的服務(wù)。意思就是單機(jī)環(huán)境。
Docker Swarm
Docker Swarm 是由Docker 公司研發(fā)的一款用來管理集群上的Docker容器工具，彌補(bǔ)了 Docker-Compose 單節(jié)點(diǎn)的缺陷，Docker Swarm 可以幫助我們啟動(dòng)容器，監(jiān)控容器的狀態(tài)，如果容器服務(wù)掛掉會(huì)重新啟動(dòng)一個(gè)新的容器，保證正常的對外提供服務(wù)，也支持服務(wù)之間的負(fù)載均衡。而且這些東西 Docker-Compose是不支持的，
Kubernetes
Kubernetes 它本身的角色定位是和Docker Swarm 是一樣的，也就是說他們負(fù)責(zé)的工作在容器領(lǐng)域來說是相同的部分，當(dāng)然也要一些不一樣的特點(diǎn)，Kubernetes 是谷歌自己的產(chǎn)品，經(jīng)過大量的實(shí)踐和宿主機(jī)的實(shí)驗(yàn)，非常的成熟，所以 Kubernetes 正在成為容器編排領(lǐng)域的領(lǐng)導(dǎo)者，其 可配置性、可靠性和社區(qū)的廣大支持，從而超越了 Docker Swarm，作為谷歌的開源項(xiàng)目，它和整個(gè)谷歌的云平臺協(xié)調(diào)工作。
K8S的職責(zé)
- 自動(dòng)化容器的部署和復(fù)制
- 隨時(shí)擴(kuò)展或收縮容器規(guī)模
- 容器分組Group，并且提供容器間的負(fù)載均衡
- 實(shí)時(shí)監(jiān)控：及時(shí)故障發(fā)現(xiàn)，自動(dòng)替換
K8S的基本概念
在下圖中，是K8S的一個(gè)集群，在這個(gè)集群中包含三臺宿主機(jī)，這里的每一個(gè)方塊都是我們的物理虛擬機(jī)，通過這三個(gè)物理機(jī)，我們形成了一個(gè)完整的集群，從角色劃分，可以分為兩種
- 一種是 KubernetesMaster主服務(wù)器，它是整個(gè)集群的管理者，它可以對整個(gè)集群的節(jié)點(diǎn)進(jìn)行管理，通過主服務(wù)器向這些節(jié)點(diǎn)，發(fā)送創(chuàng)建容器、自動(dòng)部署、自動(dòng)發(fā)布等功能，并且所有來自外部的數(shù)據(jù)都會(huì)由 KubernetesMaster進(jìn)行接收并進(jìn)行分配。
- 還有一種就是 node節(jié)點(diǎn) 節(jié)點(diǎn)可以是一臺獨(dú)立的物理機(jī)也可以是一個(gè)虛擬機(jī)，在每個(gè)節(jié)點(diǎn)中都有一個(gè)非常重要的 K8S 獨(dú)有的概念，就是我們的Pod，Pod是K8S最重要也是最基礎(chǔ)的概念
Pod
- Pod是 Kubernetes 控制的最小單元，一個(gè)Pod就是一個(gè)進(jìn)程。
- 一個(gè)Pod可以被一個(gè)容器化的環(huán)境看做應(yīng)用層的“邏輯宿主機(jī)”，可以理解為容器的容器，可以包含多個(gè)“Container”;
- 一個(gè)Pod的多個(gè)容器應(yīng)用通常是緊密耦合的，Pod在Node上創(chuàng)建、啟動(dòng)或銷毀;
- 每個(gè)Pod里面運(yùn)行著一個(gè)特殊的被稱為 Pause的容器，其他的容器被稱為業(yè)務(wù)容器，這些業(yè)務(wù)容器共享Pause容器的網(wǎng)絡(luò)棧和Volume掛載卷;
- Pod的內(nèi)部容器網(wǎng)絡(luò)是互通的，每個(gè)Pod都有獨(dú)立的虛擬IP。
- Pod都是部署完整的應(yīng)用或模塊，同一個(gè)Pod容器之間只需要通過localhsot就能互相通信。
- Pod的生命周期是通過 Replication Controller 來管理的，通過模板進(jìn)行定義，然后分配到一個(gè)Node上運(yùn)行，在Pod鎖包含容器運(yùn)行結(jié)束后，Pod結(jié)束。
打一個(gè)比較形象的比喻，我們可以把Pod理解成一個(gè)豆莢，容器就是里面的豆子，是一個(gè)共生體。
Pod里面到底裝的是什么?
- 在一些小公司里面，一個(gè)Pod就是一個(gè)完整的應(yīng)用，里面安裝著各種容器，一個(gè)Pod里面可能包含(Redis、Mysql、Tomcat等等)，當(dāng)把這一個(gè)Pod部署以后就相當(dāng)于部署了一個(gè)完整的應(yīng)用，多個(gè)Pod部署完以后就形成了一個(gè)集群，這是Pod的第一種應(yīng)用方式
- 還有一種使用方式就是在Pod里面只服務(wù)一種容器，比如在一個(gè)Pod里面我只部署Tomcat
具體怎么部署Pod里面的容器，是按照我們項(xiàng)目的特性和資源的分配進(jìn)行合理選擇的。
pause容器：
Pause容器 全稱infrastucture container(又叫infra)基礎(chǔ)容器，作為init pod存在，其他pod都會(huì)從pause 容器中fork出來，這個(gè)容器對于Pod來說是必備的一個(gè)Pod中的應(yīng)用容器共享同一個(gè)資源：
- PID命名空間：Pod中的不同應(yīng)用程序可以看到其他的應(yīng)用程序的進(jìn)程ID
- 網(wǎng)絡(luò)命名空間：Pod中的多個(gè)容器能夠訪問同一個(gè)IP和端口范圍
- IPC命名空間：Pod的多個(gè)容器能夠使用，SystemV IPC或POSIX消息隊(duì)列進(jìn)行通信
- UTS命名空間：Pod中的多個(gè)容器共享一個(gè)主機(jī)名;Volumes(共享存儲卷)
- Pod中的各個(gè)容器可以訪問在Pod級別定義的Volumes
在上圖中如果沒有pause容器，我們的Nginx和Ghost，Pod內(nèi)的容器想要彼此通信的話，都需要使用自己的IP地址和端口，才可以彼此進(jìn)行訪問，如果有pause容器，對于整個(gè)Pod來說，我們可以看做一個(gè)整體，也就是我們的Nginx和Ghost直接使用localhost就可以進(jìn)行訪問了，他們唯一不同的就只是端口，這里面可能看著覺得比較簡單，但其實(shí)是使用了很多網(wǎng)絡(luò)底層的東西才實(shí)現(xiàn)的，感興趣的小伙伴可以自行了解一下。
Service(服務(wù))
在 Kubernetes 中，每個(gè)Pod都會(huì)被分配一個(gè)單獨(dú)的IP地址，但是Pod和Pod之間，是無法直接進(jìn)行交互的，如果想要進(jìn)行網(wǎng)絡(luò)通信，必須要通過另外一個(gè)組件才能交流，也就是我們的 Service
Service 是服務(wù)的意思，在K8S中Service主要工作就是將多個(gè)不同主機(jī)上的Pod，通過Service進(jìn)行連通，讓Pod和Pod之間可以正常的通信
我們可以把Service看做一個(gè)域名，而相同服務(wù)的Pod集群就是不同的ip地址，Service 是通過 Label Selector 來進(jìn)行定義的。
- Service 擁有一個(gè)指定的名字，類似于域名這種，并且它還擁有一個(gè)虛擬的IP地址和端口號，只能內(nèi)網(wǎng)進(jìn)行訪問，如果Service想要進(jìn)行外網(wǎng)訪問或提供外網(wǎng)服務(wù)，需要指定公共的IP和NodePort或者外部的負(fù)載均衡器。
使用NodePort提供外部訪問，只需要在每個(gè)Node上打開一個(gè)主機(jī)的真實(shí)端口，這樣就可以通過Node的客戶端訪問到內(nèi)部的Service。
Label(標(biāo)簽)
Label 一般以 kv的方式附件在各種對象上，Label 是一個(gè)說明性的標(biāo)簽，它有著很重要的作用，我們在部署容器的時(shí)候，在哪些Pod進(jìn)行操作，都需要根據(jù)Label進(jìn)行查找和篩選，我們可以理解Label是每一個(gè)Pod的別名，只有取了名稱，作為K8S的Master主節(jié)點(diǎn)才能找到對應(yīng)的Pod進(jìn)行操作。
Replication Controller(復(fù)制控制器)
- 存在Master主節(jié)點(diǎn)上，這個(gè)兄弟的作用主要是對Pod的數(shù)量進(jìn)行監(jiān)控，比如我們在下面的節(jié)點(diǎn)中我們需要三個(gè)相同屬性的Pod，但是目前只有兩個(gè)，當(dāng) ReplicationController看到只有兩個(gè)的時(shí)候，就會(huì)自動(dòng)幫助我們按照我們制定的規(guī)則創(chuàng)建一個(gè)額外的副本，放到我們的節(jié)點(diǎn)中。
- ReplicationController還可以對Pod進(jìn)行實(shí)時(shí)監(jiān)控，當(dāng)我們某一個(gè)Pod它失去了響應(yīng)，這個(gè)Pod就會(huì)被剔除，如果我們需要， ReplicationController會(huì)自動(dòng)創(chuàng)建一個(gè)新的
- Kubernetes通過RC中定義的Lable篩選出對應(yīng)的Pod實(shí)例，并實(shí)時(shí)監(jiān)控其狀態(tài)和數(shù)量，如果實(shí)例數(shù)量少于定義的副本數(shù)量(Replicas)，則會(huì)根據(jù)RC中定義的Pod模板來創(chuàng)建一個(gè)新的Pod，然后將此Pod調(diào)度到合適的Node上啟動(dòng)運(yùn)行，直到Pod實(shí)例數(shù)量達(dá)到預(yù)定目標(biāo)。
K8S的總體架構(gòu)
- Kubernetes將集群中的機(jī)器劃分為一個(gè)Master節(jié)點(diǎn)和一群工作節(jié)點(diǎn)(Node)
- Master節(jié)點(diǎn)上運(yùn)行著集群管理相關(guān)的一組進(jìn)程 etcd、APIServer、ControllerManager、Scheduler，后三個(gè)組件構(gòu)成了Kubernetes的總控中心，這些進(jìn)程實(shí)現(xiàn)了整個(gè)集群的資源管理、Pod調(diào)度、彈性伸縮、安全控制、系統(tǒng)監(jiān)控和糾錯(cuò)等管理功能，并且全都是自動(dòng)完成。
- Node上運(yùn)行kubelet、kube-proxy、docker三個(gè)組件，是真正支持K8S的技術(shù)方案。負(fù)責(zé)對本節(jié)點(diǎn)上的Pod的生命周期進(jìn)行管理，以及實(shí)現(xiàn)服務(wù)代理的功能。
用戶通過 Kubectl提交一個(gè)創(chuàng)建 ReplicationController請求，這個(gè)請求通過 API Server 寫入 etcd 中，這個(gè)時(shí)候 ControllerManager通過 API Server的監(jiān)聽到了創(chuàng)建的命名，經(jīng)過它認(rèn)真仔細(xì)的分析以后，發(fā)現(xiàn)當(dāng)前集群里面居然還沒有對應(yīng)的Pod實(shí)例，趕緊根據(jù) ReplicationController模板定義造一個(gè)Pod對象，再通 過Api Server 寫到我們 etcd 里面
到下面，如果被 Scheduler發(fā)現(xiàn)了，好家伙不告訴我???，無業(yè)游民，這家伙一看就不是一個(gè)好人啊，它就會(huì)立即運(yùn)行一個(gè)復(fù)雜的調(diào)度流程，為這個(gè)新的Pod選一個(gè)可以落戶的Node，總算有個(gè)身份了，真是讓人操心，然后通過 API Server 將這個(gè)結(jié)果也寫到etcd中，隨后，我們的 Node上運(yùn)行的小管家 Kubelet進(jìn)程通過 API Server 檢測到這個(gè) 新生的小寶寶——“Pod”，就會(huì)按照它，就會(huì)按照這個(gè)小寶寶的特性，啟動(dòng)這個(gè)Pod并任勞任怨的負(fù)責(zé)它的下半生，直到Pod的生命結(jié)束。
然后我們通過 Kubectl提交一個(gè)新的映射到這個(gè)Pod的Service的創(chuàng)建請求， ControllerManager會(huì)通過Label標(biāo)簽查詢到相關(guān)聯(lián)的Pod實(shí)例，生成Service的Endpoints的信息，并通過 API Server 寫入到etcd中，接下來，所有 Node上運(yùn)行的Proxy進(jìn)程通過 Api Server 查詢并監(jiān)聽 Service對象與其對應(yīng)的 Endpoints信息，建立一個(gè)軟件方式的負(fù)載均衡器來實(shí)現(xiàn) Service訪問到后端Pod的流量轉(zhuǎn)發(fā)功能。
kube-proxy： 是一個(gè)代理，充當(dāng)這多主機(jī)通信的代理人，前面我們講過Service實(shí)現(xiàn)了跨主機(jī)、跨容器之間的網(wǎng)絡(luò)通信，在技術(shù)上就是通過kube-proxy來實(shí)現(xiàn)的，service是在邏輯上對Pod進(jìn)行了分組，底層是通過kube-proxy進(jìn)行通信的
kubelet： 用于執(zhí)行K8S的命令，也是K8S的核心命令，用于執(zhí)行K8S的相關(guān)指令，負(fù)責(zé)當(dāng)前Node節(jié)點(diǎn)上的Pod的創(chuàng)建、修改、監(jiān)控、刪除等生命周期管理，同時(shí)Kubelet定時(shí)“上報(bào)”本Node的狀態(tài)信息到API Server里
etcd： 用于持久化存儲集群中所有的資源對象，API Server提供了操作 etcd的封裝接口API，這些API基本上都是對資源對象的操作和監(jiān)聽資源變化的接口
API Server ： 提供資源對象的操作入口，其他組件都需要通過它提供操作的API來操作資源數(shù)據(jù)，通過對相關(guān)的資源數(shù)據(jù)“全量查詢”+ “變化監(jiān)聽”，可以實(shí)時(shí)的完成相關(guān)的業(yè)務(wù)功能。
Scheduler ： 調(diào)度器，負(fù)責(zé)Pod在集群節(jié)點(diǎn)中的調(diào)度分配。
Controller Manager： 集群內(nèi)部管理控制中心，主要是實(shí)現(xiàn) Kubernetes集群的故障檢測和恢復(fù)的自動(dòng)化工作。比如Pod的復(fù)制和移除，Endpoints對象的創(chuàng)建和更新，Node的發(fā)現(xiàn)、管理和狀態(tài)監(jiān)控等等都是由 ControllerManager完成。
總結(jié)
到這里K8S的基本情況我們就講解完畢了，有喜歡的小伙伴記得 點(diǎn)贊關(guān)注，相比如Docker來說K8S有著更成熟的功能，經(jīng)過谷歌大量實(shí)踐的產(chǎn)物，是一個(gè)比較成熟和完善的系統(tǒng)。
本文轉(zhuǎn)載自微信公眾號「牧小農(nóng)」
