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