什么是Kubernetes非竿？
Kubernetes是Google開源的分布式容器管理平臺，是為了更方便的在服務(wù)器中管理我們的容器化應(yīng)用轮傍。
Kubernetes簡稱 K8S秕重，為什么會有這個稱號正林？因為K和S是 Kubernetes 首字母和尾字母泡一，而K和S中間有八個字母，所以簡稱 K8S觅廓，加上 Kubernetes 比較繞口鼻忠，所以一般使用簡稱 K8S。
Kubernetes即是一款容器編排工具杈绸，也是一個全新的基于容器技術(shù)的分布式架構(gòu)方案帖蔓，在基于Docker的基礎(chǔ)上，可以提供從 創(chuàng)建應(yīng)用>應(yīng)用部署>提供服務(wù)>動態(tài)伸縮>應(yīng)用更新 一系列服務(wù)瞳脓，提高了容器集群管理的便捷性塑娇。
K8S產(chǎn)生的原因
大家可以先看一下，下面一張圖劫侧，里面有我們的 mysql埋酬，redis，tomcat烧栋，nginx等配置信息写妥，如果我們想要安裝里面的數(shù)據(jù)，我們需要一個一個手動安裝劲弦，好像也可以耳标，反正也就一個，雖然麻煩了一點(diǎn)邑跪，但也不耽誤次坡。
但是隨著技術(shù)的發(fā)展和業(yè)務(wù)的需要，單臺服務(wù)器已經(jīng)不能滿足我們?nèi)粘５男枰嘶絹碓蕉嗟墓驹依牛嘈枰氖羌涵h(huán)境和多容器部署，那么如果還是一個一個去部署轴踱，運(yùn)維恐怕要瘋掉了症脂，一天啥也不干就去部署機(jī)器了，有時候淫僻，可能因為某一個環(huán)節(jié)出錯诱篷，要重新，那真的是吐血雳灵。棕所。。悯辙。琳省。，如下圖所示：
如果我想要部署躲撰，以下幾臺機(jī)器：
3臺 - Nginx
5臺 - Redis
7臺 - ZooKeeper
4臺 - Tomcat
6臺 - MySql
5臺 - JDK
10臺 - 服務(wù)器
如果要一個一個去部署针贬，人都要傻掉了，這什么時候是個頭拢蛋，如果是某里巴的兩萬臺機(jī)器桦他，是不是要當(dāng)場提交辭職信，所以 K8S 就是幫助我們來做這些事情的谆棱，方便我們對容器的管理和應(yīng)用的自動化部署瞬铸，減少重復(fù)勞動，并且能夠自動化部署應(yīng)用和故障自愈础锐。
并且如果 K8S 對于微服務(wù)有很好的支持嗓节，并且一個微服務(wù)的副本可以跟著系統(tǒng)的負(fù)荷變化進(jìn)行調(diào)整，K8S 內(nèi)在的服務(wù)彈性擴(kuò)容機(jī)制也能夠很好的應(yīng)對突發(fā)流量皆警。
容器編排工具對比
Docker-Compose
Docker-Compose是用來管理容器的拦宣，類似用戶容器管家，我們有N多臺容器或者應(yīng)用需要啟動的時候信姓，如果手動去操作鸵隧，是非常耗費(fèi)時間的，如果有了 Docker-Compose 只需要一個配置文件就可以幫我們搞定意推，但是 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 可以幫助我們啟動容器，監(jiān)控容器的狀態(tài)昵宇，如果容器服務(wù)掛掉會重新啟動一個新的容器磅崭，保證正常的對外提供服務(wù)，也支持服務(wù)之間的負(fù)載均衡瓦哎。而且這些東西 Docker-Compose 是不支持的砸喻，
Kubernetes
Kubernetes它本身的角色定位是和 Docker Swarm 是一樣的，也就是說他們負(fù)責(zé)的工作在容器領(lǐng)域來說是相同的部分蒋譬，當(dāng)然也要一些不一樣的特點(diǎn)割岛， Kubernetes是谷歌自己的產(chǎn)品，經(jīng)過大量的實踐和宿主機(jī)的實驗犯助，非常的成熟癣漆，所以Kubernetes 正在成為容器編排領(lǐng)域的領(lǐng)導(dǎo)者，其 可配置性也切、可靠性和社區(qū)的廣大支持扑媚，從而超越了 Docker Swarm ，作為谷歌的開源項目雷恃，它和整個谷歌的云平臺協(xié)調(diào)工作疆股。
K8S的職責(zé)
- 自動化容器的部署和復(fù)制
- 隨時擴(kuò)展或收縮容器規(guī)模
- 容器分組Group，并且提供容器間的負(fù)載均衡
- 實時監(jiān)控：及時故障發(fā)現(xiàn)倒槐，自動替換
K8S的基本概念
在下圖中旬痹，是K8S的一個集群，在這個集群中包含三臺宿主機(jī)讨越，這里的每一個方塊都是我們的物理虛擬機(jī)两残，通過這三個物理機(jī)，我們形成了一個完整的集群把跨，從角色劃分人弓，可以分為兩種
- 一種是 Kubernetes Master 主服務(wù)器，它是整個集群的管理者着逐，它可以對整個集群的節(jié)點(diǎn)進(jìn)行管理崔赌，通過主服務(wù)器向這些節(jié)點(diǎn)，發(fā)送創(chuàng)建容器耸别、自動部署健芭、自動發(fā)布等功能，并且所有來自外部的數(shù)據(jù)都會由 Kubernetes Master進(jìn)行接收并進(jìn)行分配秀姐。
- 還有一種就是 node節(jié)點(diǎn) 節(jié)點(diǎn)可以是一臺獨(dú)立的物理機(jī)也可以是一個虛擬機(jī)慈迈，在每個節(jié)點(diǎn)中都有一個非常重要的 K8S 獨(dú)有的概念，就是我們的Pod省有， Pod是K8S最重要也是最基礎(chǔ)的概念
Pod
- Pod是 Kubernetes 控制的最小單元痒留，一個Pod就是一個進(jìn)程谴麦。
- 一個Pod可以被一個容器化的環(huán)境看做應(yīng)用層的“邏輯宿主機(jī)”，可以理解為容器的容器狭瞎，可以包含多個“Container”;
- 一個Pod的多個容器應(yīng)用通常是緊密耦合的细移，Pod在Node上創(chuàng)建搏予、啟動或銷毀熊锭；
- 每個Pod里面運(yùn)行著一個特殊的被稱為 Pause 的容器，其他的容器被稱為業(yè)務(wù)容器雪侥，這些業(yè)務(wù)容器共享Pause容器的網(wǎng)絡(luò)棧和Volume掛載卷碗殷；
- Pod的內(nèi)部容器網(wǎng)絡(luò)是互通的，每個Pod都有獨(dú)立的虛擬IP速缨。
- Pod都是部署完整的應(yīng)用或模塊锌妻，同一個Pod容器之間只需要通過localhsot就能互相通信。
- Pod的生命周期是通過 Replication Controller 來管理的旬牲，通過模板進(jìn)行定義仿粹，然后分配到一個Node上運(yùn)行，在Pod鎖包含容器運(yùn)行結(jié)束后原茅，Pod結(jié)束吭历。
打一個比較形象的比喻，我們可以把Pod理解成一個豆莢擂橘，容器就是里面的豆子晌区，是一個共生體。
Pod里面到底裝的是什么通贞？
- 在一些小公司里面朗若，一個Pod就是一個完整的應(yīng)用，里面安裝著各種容器昌罩，一個Pod里面可能包含（Redis哭懈、Mysql、Tomcat等等）茎用，當(dāng)把這一個Pod部署以后就相當(dāng)于部署了一個完整的應(yīng)用遣总，多個Pod部署完以后就形成了一個集群，這是Pod的第一種應(yīng)用方式
- 還有一種使用方式就是在Pod里面只服務(wù)一種容器绘搞，比如在一個Pod里面我只部署Tomcat
具體怎么部署Pod里面的容器彤避，是按照我們項目的特性和資源的分配進(jìn)行合理選擇的。
pause容器：
Pause容器 全稱infrastucture container（又叫infra）基礎(chǔ)容器夯辖，作為init pod存在琉预，其他pod都會從pause 容器中fork出來，這個容器對于Pod來說是必備的
一個Pod中的應(yīng)用容器共享同一個資源：
- PID命名空間：Pod中的不同應(yīng)用程序可以看到其他的應(yīng)用程序的進(jìn)程ID
- 網(wǎng)絡(luò)命名空間：Pod中的多個容器能夠訪問同一個IP和端口范圍
- IPC命名空間：Pod的多個容器能夠使用蒿褂，SystemV IPC或POSIX消息隊列進(jìn)行通信
- UTS命名空間：Pod中的多個容器共享一個主機(jī)名圆米；Volumes（共享存儲卷）
- Pod中的各個容器可以訪問在Pod級別定義的Volumes
在上圖中如果沒有 pause容器 卒暂，我們的Nginx和Ghost，Pod內(nèi)的容器想要彼此通信的話娄帖，都需要使用自己的IP地址和端口也祠，才可以彼此進(jìn)行訪問，如果有 pause容器 近速，對于整個Pod來說诈嘿，我們可以看做一個整體，也就是我們的Nginx和Ghost直接使用localhost就可以進(jìn)行訪問了削葱，他們唯一不同的就只是端口奖亚，這里面可能看著覺得比較簡單，但其實是使用了很多網(wǎng)絡(luò)底層的東西才實現(xiàn)的析砸，感興趣的小伙伴可以自行了解一下昔字。
Service(服務(wù))
在 Kubernetes 中，每個Pod都會被分配一個單獨(dú)的IP地址首繁，但是Pod和Pod之間作郭，是無法直接進(jìn)行交互的，如果想要進(jìn)行網(wǎng)絡(luò)通信弦疮，必須要通過另外一個組件才能交流夹攒，也就是我們的 Service
Service是服務(wù)的意思，在K8S中 Service 主要工作就是將多個不同主機(jī)上的Pod挂捅，通過 Service 進(jìn)行連通芹助，讓Pod和Pod之間可以正常的通信
我們可以把 Service 看做一個域名，而相同服務(wù)的Pod集群就是不同的ip地址闲先，Service 是通過 Label Selector 來進(jìn)行定義的状土。
- Service 擁有一個指定的名字，類似于域名這種伺糠，并且它還擁有一個虛擬的IP地址和端口號蒙谓，只能內(nèi)網(wǎng)進(jìn)行訪問，如果Service想要進(jìn)行外網(wǎng)訪問或提供外網(wǎng)服務(wù)训桶，需要指定公共的IP和NodePort或者外部的負(fù)載均衡器累驮。
使用NodePort提供外部訪問，只需要在每個Node上打開一個主機(jī)的真實端口舵揭，這樣就可以通過Node的客戶端訪問到內(nèi)部的Service谤专。
Label(標(biāo)簽)
Label 一般以 kv的方式附件在各種對象上，Label 是一個說明性的標(biāo)簽午绳，它有著很重要的作用置侍，我們在部署容器的時候，在哪些Pod進(jìn)行操作，都需要根據(jù)Label進(jìn)行查找和篩選蜡坊，我們可以理解Label是每一個Pod的別名杠输，只有取了名稱，作為K8S的Master主節(jié)點(diǎn)才能找到對應(yīng)的Pod進(jìn)行操作秕衙。
Replication Controller(復(fù)制控制器)
- 存在Master主節(jié)點(diǎn)上蠢甲，這個兄弟的作用主要是對Pod的數(shù)量進(jìn)行監(jiān)控，比如我們在下面的節(jié)點(diǎn)中我們需要三個相同屬性的Pod据忘，但是目前只有兩個鹦牛，當(dāng)Replication Controller 看到只有兩個的時候，就會自動幫助我們按照我們制定的規(guī)則創(chuàng)建一個額外的副本若河，放到我們的節(jié)點(diǎn)中能岩。
- Replication Controller 還可以對Pod進(jìn)行實時監(jiān)控寞宫，當(dāng)我們某一個Pod它失去了響應(yīng)萧福，這個Pod就會被剔除，如果我們需要辈赋， Replication Controller 會自動創(chuàng)建一個新的
- Kubernetes通過RC中定義的Lable篩選出對應(yīng)的Pod實例鲫忍，并實時監(jiān)控其狀態(tài)和數(shù)量，如果實例數(shù)量少于定義的副本數(shù)量（Replicas）钥屈，則會根據(jù)RC中定義的Pod模板來創(chuàng)建一個新的Pod悟民，然后將此Pod調(diào)度到合適的Node上啟動運(yùn)行，直到Pod實例數(shù)量達(dá)到預(yù)定目標(biāo)篷就。
K8S的總體架構(gòu)
- Kubernetes將集群中的機(jī)器劃分為一個Master節(jié)點(diǎn)和一群工作節(jié)點(diǎn)（Node）
- Master節(jié)點(diǎn)上運(yùn)行著集群管理相關(guān)的一組進(jìn)程 etcd射亏、API Server、Controller Manager竭业、Scheduler 智润，后三個組件構(gòu)成了Kubernetes的總控中心，這些進(jìn)程實現(xiàn)了整個集群的資源管理未辆、Pod調(diào)度窟绷、彈性伸縮、安全控制咐柜、系統(tǒng)監(jiān)控和糾錯等管理功能兼蜈，并且全都是自動完成。
- Node上運(yùn)行 kubelet拙友、kube-proxy为狸、docker 三個組件，是真正支持K8S的技術(shù)方案遗契。負(fù)責(zé)對本節(jié)點(diǎn)上的Pod的生命周期進(jìn)行管理辐棒，以及實現(xiàn)服務(wù)代理的功能。
用戶通過 Kubectl 提交一個創(chuàng)建 Replication Controller 請求，這個請求通過 API Server 寫入 etcd 中涉瘾，這個時候 Controller Manager 通過 API Server 的監(jiān)聽到了創(chuàng)建的命名知态，經(jīng)過它認(rèn)真仔細(xì)的分析以后，發(fā)現(xiàn)當(dāng)前集群里面居然還沒有對應(yīng)的Pod實例立叛，趕緊根據(jù) Replication Controller 模板定義造一個Pod對象负敏，再通 過Api Server 寫到我們 etcd 里面
到下面，如果被 Scheduler 發(fā)現(xiàn)了秘蛇，好家伙不告訴我其做？？赁还？妖泄，無業(yè)游民，這家伙一看就不是一個好人啊艘策，它就會立即運(yùn)行一個復(fù)雜的調(diào)度流程蹈胡，為這個新的Pod選一個可以落戶的Node，總算有個身份了朋蔫，真是讓人操心罚渐，然后通過 API Server 將這個結(jié)果也寫到etcd中，隨后驯妄，我們的 Node 上運(yùn)行的小管家 Kubelet 進(jìn)程通過 API Server 檢測到這個 新生的小寶寶——“Pod”荷并，就會按照它，就會按照這個小寶寶的特性青扔，啟動這個Pod并任勞任怨的負(fù)責(zé)它的下半生源织，直到Pod的生命結(jié)束。
然后我們通過 Kubectl 提交一個新的映射到這個Pod的Service的創(chuàng)建請求微猖， Controller Manager 會通過Label標(biāo)簽查詢到相關(guān)聯(lián)的Pod實例谈息，生成Service的Endpoints的信息，并通過 API Server 寫入到etcd中励两，接下來黎茎，所有 Node 上運(yùn)行的Proxy進(jìn)程通過 Api Server 查詢并監(jiān)聽 Service對象 與其對應(yīng)的 Endpoints 信息，建立一個軟件方式的負(fù)載均衡器來實現(xiàn) Service 訪問到后端Pod的流量轉(zhuǎn)發(fā)功能当悔。
kube-proxy：是一個代理傅瞻，充當(dāng)這多主機(jī)通信的代理人，前面我們講過Service實現(xiàn)了跨主機(jī)盲憎、跨容器之間的網(wǎng)絡(luò)通信嗅骄，在技術(shù)上就是通過 kube-proxy 來實現(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)控、刪除等生命周期管理炊林，同時Kubelet定時“上報”本Node的狀態(tài)信息到API Server里
etcd：用于持久化存儲集群中所有的資源對象姥卢，API Server提供了操作 etcd的封裝接口API，這些API基本上都是對資源對象的操作和監(jiān)聽資源變化的接口
API Server ：提供資源對象的操作入口渣聚，其他組件都需要通過它提供操作的API來操作資源數(shù)據(jù)独榴，通過對相關(guān)的資源數(shù)據(jù)“全量查詢”+ “變化監(jiān)聽”，可以實時的完成相關(guān)的業(yè)務(wù)功能奕枝。
Scheduler ：調(diào)度器棺榔，負(fù)責(zé)Pod在集群節(jié)點(diǎn)中的調(diào)度分配。
Controller Manager：集群內(nèi)部管理控制中心隘道，主要是實現(xiàn) Kubernetes 集群的故障檢測和恢復(fù)的自動化工作症歇。比如Pod的復(fù)制和移除，Endpoints對象的創(chuàng)建和更新薄声，Node的發(fā)現(xiàn)当船、管理和狀態(tài)監(jiān)控等等都是由 Controller Manager 完成。
總結(jié)
到這里K8S的基本情況我們就講解完畢了默辨，有喜歡的小伙伴記得 點(diǎn)贊關(guān)注 ，相比如Docker來說K8S有著更成熟的功能苍息，經(jīng)過谷歌大量實踐的產(chǎn)物缩幸，是一個比較成熟和完善的系統(tǒng)。
