這一篇 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大家有什麼想要了解或者疑問的地方歡迎大家留言告訴我。

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

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