這一篇 K8S（Kubernetes）我覺得可以了解一下！！！

點贊再看，養成習慣，微信搜索【牧小農】關注我獲取更多資訊，風里雨里，小農等你，很高興能夠成為你的朋友，

什么是Kubernetes？

Kubernetes 是Google開源的分布式容器管理平臺，是為了更方便的在服務器中管理我們的容器化應用，

Kubernetes 簡稱 K8S，為什么會有這個稱號？因為K和S是 Kubernetes 首字母和尾字母，而K和S中間有八個字母，所以簡稱 K8S，加上 Kubernetes比較繞口，所以一般使用簡稱 K8S，

Kubernetes 即是一款容器編排工具，也是一個全新的基于容器技術的分布式架構方案，在基于Docker的基礎上，可以提供從 創建應用>應用部署>提供服務>動態伸縮>應用更新一系列服務，提高了容器集群管理的便捷性，

K8S產生的原因

大家可以先看一下，下面一張圖，里面有我們的mysql，redis，tomcat，nginx等配置資訊，如果我們想要安裝里面的資料，我們需要一個一個手動安裝，好像也可以，反正也就一個，雖然麻煩了一點，但也不耽誤，

但是隨著技術的發展和業務的需要，單臺服務器已經不能滿足我們日常的需要了，越來越多的公司，更多需要的是集群環境和多容器部署，那么如果還是一個一個去部署，運維恐怕要瘋掉了，一天啥也不干就去部署機器了，有時候，可能因為某一個環節出錯，要重新，那真的是吐血，，，，，，如下圖所示：

如果我想要部署，以下幾臺機器：

3臺 - Nginx
5臺 - Redis
7臺 - ZooKeeper
4臺 - Tomcat
6臺 - MySql
5臺 - JDK
10臺 - 服務器

如果要一個一個去部署，人都要傻掉了，這什么時候是個頭，如果是某里巴的兩萬臺機器，是不是要當場提交辭職信，所以 K8S 就是幫助我們來做這些事情的，方便我們對容器的管理和應用的自動化部署，減少重復勞動，并且能夠自動化部署應用和故障自愈，

并且如果 K8S 對于微服務有很好的支持，并且一個微服務的副本可以跟著系統的負荷變化進行調整，K8S 內在的服務彈性擴容機制也能夠很好的應對突發流量，

容器編排工具對比

Docker-Compose

Docker-Compose 是用來管理容器的，類似用戶容器管家，我們有N多臺容器或者應用需要啟動的時候，如果手動去操作，是非常耗費時間的，如果有了 Docker-Compose 只需要一個組態檔就可以幫我們搞定，但是 Docker-Compose 只能管理當前主機上的 Docker，不能去管理其他服務器上的服務，意思就是單機環境，

Docker Swarm

Docker Swarm 是由Docker 公司研發的一款用來管理集群上的Docker容器工具，彌補了 Docker-Compose 單節點的缺陷，Docker Swarm 可以幫助我們啟動容器，監控容器的狀態，如果容器服務掛掉會重新啟動一個新的容器，保證正常的對外提供服務，也支持服務之間的負載均衡，而且這些東西 Docker-Compose是不支持的，

Kubernetes

Kubernetes 它本身的角色定位是和Docker Swarm 是一樣的，也就是說他們負責的作業在容器領域來說是相同的部分，當然也要一些不一樣的特點，Kubernetes 是谷歌自己的產品，經過大量的實踐和宿主機的實驗，非常的成熟，所以 Kubernetes 正在成為容器編排領域的領導者，其 可配置性、可靠性和社區的廣大支持，從而超越了 Docker Swarm，作為谷歌的開源專案，它和整個谷歌的云平臺協調作業，

K8S的職責

1. 自動化容器的部署和復制
2. 隨時擴展或收縮容器規模
3. 容器分組Group，并且提供容器間的負載均衡
4. 實時監控：及時故障發現，自動替換

K8S的基本概念

在下圖中，是K8S的一個集群，在這個集群中包含三臺宿主機，這里的每一個方塊都是我們的物理虛擬機，通過這三個物理機，我們形成了一個完整的集群，從角色劃分，可以分為兩種

• 一種是 Kubernetes Master主服務器，它是整個集群的管理者，它可以對整個集群的節點進行管理，通過主服務器向這些節點，發送創建容器、自動部署、自動發布等功能，并且所有來自外部的資料都會由 Kubernetes Master進行接收并進行分配，

• 還有一種就是 node節點 節點可以是一臺獨立的物理機也可以是一個虛擬機，在每個節點中都有一個非常重要的 K8S 獨有的概念，就是我們的Pod，Pod是K8S最重要也是最基礎的概念

Pod

• Pod是 Kubernetes 控制的最小單元，一個Pod就是一個行程，
• 一個Pod可以被一個容器化的環境看做應用層的“邏輯宿主機”，可以理解為容器的容器，可以包含多個“Container”;
• 一個Pod的多個容器應用通常是緊密耦合的，Pod在Node上創建、啟動或銷毀；
• 每個Pod里面運行著一個特殊的被稱為Pause的容器，其他的容器被稱為業務容器，這些業務容器共享Pause容器的網路堆疊和Volume掛載卷；
• Pod的內部容器網路是互通的，每個Pod都有獨立的虛擬IP，
• Pod都是部署完整的應用或模塊，同一個Pod容器之間只需要通過localhsot就能互相通信，
• Pod的生命周期是通過 Replication Controller 來管理的，通過模板進行定義，然后分配到一個Node上運行，在Pod鎖包含容器運行結束后，Pod結束，

打一個比較形象的比喻，我們可以把Pod理解成一個豆莢，容器就是里面的豆子，是一個共生體，

Pod里面到底裝的是什么？

• 在一些小公司里面，一個Pod就是一個完整的應用，里面安裝著各種容器，一個Pod里面可能包含（Redis、Mysql、Tomcat等等），當把這一個Pod部署以后就相當于部署了一個完整的應用，多個Pod部署完以后就形成了一個集群，這是Pod的第一種應用方式

• 還有一種使用方式就是在Pod里面只服務一種容器，比如在一個Pod里面我只部署Tomcat

具體怎么部署Pod里面的容器，是按照我們專案的特性和資源的分配進行合理選擇的，

pause容器：

Pause容器 全稱infrastucture container（又叫infra）基礎容器，作為init pod存在，其他pod都會從pause 容器中fork出來，這個容器對于Pod來說是必備的
一個Pod中的應用容器共享同一個資源：

1. PID命名空間：Pod中的不同應用程式可以看到其他的應用程式的行程ID
2. 網路命名空間：Pod中的多個容器能夠訪問同一個IP和埠范圍
3. IPC命名空間：Pod的多個容器能夠使用，SystemV IPC或POSIX訊息佇列進行通信
4. UTS命名空間：Pod中的多個容器共享一個主機名；Volumes（共享存盤卷）
5. Pod中的各個容器可以訪問在Pod級別定義的Volumes

在上圖中如果沒有pause容器，我們的Nginx和Ghost，Pod內的容器想要彼此通信的話，都需要使用自己的IP地址和埠，才可以彼此進行訪問，如果有pause容器，對于整個Pod來說，我們可以看做一個整體，也就是我們的Nginx和Ghost直接使用localhost就可以進行訪問了，他們唯一不同的就只是埠，這里面可能看著覺得比較簡單，但其實是使用了很多網路底層的東西才實作的，感興趣的小伙伴可以自行了解一下，

Service(服務)

在 Kubernetes 中，每個Pod都會被分配一個單獨的IP地址，但是Pod和Pod之間，是無法直接進行互動的，如果想要進行網路通信，必須要通過另外一個組件才能交流，也就是我們的 Service

Service 是服務的意思，在K8S中Service主要作業就是將多個不同主機上的Pod，通過Service進行連通，讓Pod和Pod之間可以正常的通信

我們可以把Service看做一個域名，而相同服務的Pod集群就是不同的ip地址，Service 是通過 Label Selector 來進行定義的，

• Service 擁有一個指定的名字，類似于域名這種，并且它還擁有一個虛擬的IP地址和埠號，只能內網進行訪問，如果Service想要進行外網訪問或提供外網服務，需要指定公共的IP和NodePort或者外部的負載均衡器，

使用NodePort提供外部訪問，只需要在每個Node上打開一個主機的真實埠，這樣就可以通過Node的客戶端訪問到內部的Service，

Label(標簽)

Label 一般以 kv的方式附件在各種物件上，Label 是一個說明性的標簽，它有著很重要的作用，我們在部署容器的時候，在哪些Pod進行操作，都需要根據Label進行查找和篩選，我們可以理解Label是每一個Pod的別名，只有取了名稱，作為K8S的Master主節點才能找到對應的Pod進行操作，

Replication Controller(復制控制器)

1. 存在Master主節點上，這個兄弟的作用主要是對Pod的數量進行監控，比如我們在下面的節點中我們需要三個相同屬性的Pod，但是目前只有兩個，當Replication Controller看到只有兩個的時候，就會自動幫助我們按照我們制定的規則創建一個額外的副本，放到我們的節點中，

2. Replication Controller還可以對Pod進行實時監控，當我們某一個Pod它失去了回應，這個Pod就會被剔除，如果我們需要，Replication Controller會自動創建一個新的

3. Kubernetes通過RC中定義的Lable篩選出對應的Pod實體，并實時監控其狀態和數量，如果實體數量少于定義的副本數量（Replicas），則會根據RC中定義的Pod模板來創建一個新的Pod，然后將此Pod調度到合適的Node上啟動運行，直到Pod實體數量達到預定目標，

K8S的總體架構

• Kubernetes將集群中的機器劃分為一個Master節點和一群作業節點（Node）
• Master節點上運行著集群管理相關的一組行程etcd、API Server、Controller Manager、Scheduler，后三個組件構成了Kubernetes的總控中心，這些行程實作了整個集群的資源管理、Pod調度、彈性伸縮、安全控制、系統監控和糾錯等管理功能，并且全都是自動完成，
• Node上運行kubelet、kube-proxy、docker三個組件，是真正支持K8S的技術方案，負責對本節點上的Pod的生命周期進行管理，以及實作服務代理的功能，

用戶通過 Kubectl提交一個創建 Replication Controller請求，這個請求通過 API Server 寫入 etcd 中，這個時候Controller Manager通過 API Server的監聽到了創建的命名，經過它認真仔細的分析以后，發現當前集群里面居然還沒有對應的Pod實體，趕緊根據Replication Controller模板定義造一個Pod物件，再通 過Api Server 寫到我們 etcd 里面

到下面，如果被Scheduler發現了，好家伙不告訴我？？？，無業游民，這家伙一看就不是一個好人啊，它就會立即運行一個復雜的調度流程，為這個新的Pod選一個可以落戶的Node，總算有個身份了，真是讓人操心，然后通過 API Server 將這個結果也寫到etcd中，隨后，我們的 Node上運行的小管家Kubelet行程通過 API Server 檢測到這個 新生的小寶寶——“Pod”，就會按照它，就會按照這個小寶寶的特性，啟動這個Pod并任勞任怨的負責它的下半生，直到Pod的生命結束，

然后我們通過Kubectl提交一個新的映射到這個Pod的Service的創建請求，Controller Manager會通過Label標簽查詢到相關聯的Pod實體，生成Service的Endpoints的資訊，并通過 API Server 寫入到etcd中，接下來，所有Node上運行的Proxy行程通過 Api Server 查詢并監聽Service物件與其對應的Endpoints資訊，建立一個軟體方式的負載均衡器來實作Service訪問到后端Pod的流量轉發功能，

kube-proxy： 是一個代理，充當這多主機通信的代理人，前面我們講過Service實作了跨主機、跨容器之間的網路通信，在技術上就是通過kube-proxy來實作的，service是在邏輯上對Pod進行了分組，底層是通過kube-proxy進行通信的

kubelet： 用于執行K8S的命令，也是K8S的核心命令，用于執行K8S的相關指令，負責當前Node節點上的Pod的創建、修改、監控、洗掉等生命周期管理，同時Kubelet定時“上報”本Node的狀態資訊到API Server里

etcd： 用于持久化存盤集群中所有的資源物件，API Server提供了操作 etcd的封裝介面API，這些API基本上都是對資源物件的操作和監聽資源變化的介面

API Server ： 提供資源物件的操作入口，其他組件都需要通過它提供操作的API來操作資源資料，通過對相關的資源資料“全量查詢”+ “變化監聽”，可以實時的完成相關的業務功能，

Scheduler ： 調度器，負責Pod在集群節點中的調度分配，

Controller Manager： 集群內部管理控制中心，主要是實作 Kubernetes集群的故障檢測和恢復的自動化作業，比如Pod的復制和移除，Endpoints物件的創建和更新，Node的發現、管理和狀態監控等等都是由 Controller Manager完成，

總結

到這里K8S的基本情況我們就講解完畢了，有喜歡的小伙伴記得 點贊關注，相比如Docker來說K8S有著更成熟的功能，經過谷歌大量實踐的產物，是一個比較成熟和完善的系統，

關于K8S大家有什么想要了解或者疑問的地方歡迎大家留言告訴我，

我是牧小農，一個卑微的打工人，如果覺得文中的內容對你有幫助，記得一鍵三連，你們的三連是小農最大的動力，

	—— 怕什么真理無窮，進一步 有進一步的歡喜，大家加油~