這一篇 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的職責
- 自動化容器的部署和復制
- 隨時擴展或收縮容器規模
- 容器分組Group，并且提供容器間的負載均衡
- 實時監控：及時故障發現，自動替換
K8S的基本概念
在下圖中，是K8S的一個集群，在這個集群中包含三臺宿主機，這里的每一個方塊都是我們的物理虛擬機，通過這三個物理機，我們形成了一個完整的集群，從角色劃分，可以分為兩種
- 一種是 KubernetesMaster主服務器，它是整個集群的管理者，它可以對整個集群的節點進行管理，通過主服務器向這些節點，發送創建容器、自動部署、自動發布等功能，并且所有來自外部的數據都會由 KubernetesMaster進行接收并進行分配。
- 還有一種就是 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中的應用容器共享同一個資源：
- PID命名空間：Pod中的不同應用程序可以看到其他的應用程序的進程ID
- 網絡命名空間：Pod中的多個容器能夠訪問同一個IP和端口范圍
- IPC命名空間：Pod的多個容器能夠使用，SystemV IPC或POSIX消息隊列進行通信
- UTS命名空間：Pod中的多個容器共享一個主機名;Volumes(共享存儲卷)
- 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(復制控制器)
- 存在Master主節點上，這個兄弟的作用主要是對Pod的數量進行監控，比如我們在下面的節點中我們需要三個相同屬性的Pod，但是目前只有兩個，當 ReplicationController看到只有兩個的時候，就會自動幫助我們按照我們制定的規則創建一個額外的副本，放到我們的節點中。
- ReplicationController還可以對Pod進行實時監控，當我們某一個Pod它失去了響應，這個Pod就會被剔除，如果我們需要， ReplicationController會自動創建一個新的
- Kubernetes通過RC中定義的Lable篩選出對應的Pod實例，并實時監控其狀態和數量，如果實例數量少于定義的副本數量(Replicas)，則會根據RC中定義的Pod模板來創建一個新的Pod，然后將此Pod調度到合適的Node上啟動運行，直到Pod實例數量達到預定目標。
K8S的總體架構
- Kubernetes將集群中的機器劃分為一個Master節點和一群工作節點(Node)
- Master節點上運行著集群管理相關的一組進程 etcd、APIServer、ControllerManager、Scheduler，后三個組件構成了Kubernetes的總控中心，這些進程實現了整個集群的資源管理、Pod調度、彈性伸縮、安全控制、系統監控和糾錯等管理功能，并且全都是自動完成。
- Node上運行kubelet、kube-proxy、docker三個組件，是真正支持K8S的技術方案。負責對本節點上的Pod的生命周期進行管理，以及實現服務代理的功能。
用戶通過 Kubectl提交一個創建 ReplicationController請求，這個請求通過 API Server 寫入 etcd 中，這個時候 ControllerManager通過 API Server的監聽到了創建的命名，經過它認真仔細的分析以后，發現當前集群里面居然還沒有對應的Pod實例，趕緊根據 ReplicationController模板定義造一個Pod對象，再通 過Api Server 寫到我們 etcd 里面
到下面，如果被 Scheduler發現了，好家伙不告訴我???，無業游民，這家伙一看就不是一個好人啊，它就會立即運行一個復雜的調度流程，為這個新的Pod選一個可以落戶的Node，總算有個身份了，真是讓人操心，然后通過 API Server 將這個結果也寫到etcd中，隨后，我們的 Node上運行的小管家 Kubelet進程通過 API Server 檢測到這個 新生的小寶寶——“Pod”，就會按照它，就會按照這個小寶寶的特性，啟動這個Pod并任勞任怨的負責它的下半生，直到Pod的生命結束。
然后我們通過 Kubectl提交一個新的映射到這個Pod的Service的創建請求， ControllerManager會通過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的發現、管理和狀態監控等等都是由 ControllerManager完成。
總結
到這里K8S的基本情況我們就講解完畢了，有喜歡的小伙伴記得 點贊關注，相比如Docker來說K8S有著更成熟的功能，經過谷歌大量實踐的產物，是一個比較成熟和完善的系統。
本文轉載自微信公眾號「牧小農」
