Kubernetes 是Google開源的分布式容器管理平臺，是為了更方便的在服務器中管理我們的容器化應用。
Kubernetes 簡稱 K8S，為什麽會有這個稱號？因為K和S是 Kubernetes 首字母和尾字母，而K和S中間有八個字母，所以簡稱 K8S，加上 Kubernetes 比較繞口，所以壹般使用簡稱 K8S。
Kubernetes 即是壹款容器編排工具，也是壹個全新的基於容器技術的分布式架構方案，在基於Docker的基礎上，可以提供從 創建應用>應用部署>提供服務>動態伸縮>應用更新 壹系列服務，提高了容器集群管理的便捷性。
大家可以先看壹下，下面壹張圖，裏面有我們的 mysql，redis，tomcat，nginx 等配置信息，如果我們想要安裝裏面的數據，我們需要壹個壹個手動安裝，好像也可以，反正也就壹個，雖然麻煩了壹點，但也不耽誤。
但是隨著技術的發展和業務的需要，單臺服務器已經不能滿足我們日常的需要了，越來越多的公司，更多需要的是集群環境和多容器部署，那麽如果還是壹個壹個去部署，運維恐怕要瘋掉了，壹天啥也不幹就去部署機器了，有時候，可能因為某壹個環節出錯，要重新，那真的是吐血。。。。。，如下圖所示：
如果我想要部署，以下幾臺機器：
如果要壹個壹個去部署，人都要傻掉了，這什麽時候是個頭，如果是某裏巴的兩萬臺機器，是不是要當場提交辭職信，所以 K8S 就是幫助我們來做這些事情的，方便我們對容器的管理和應用的自動化部署，減少重復勞動，並且能夠自動化部署應用和故障自愈。
並且如果 K8S 對於微服務有很好的支持，並且壹個微服務的副本可以跟著系統的負荷變化進行調整，K8S 內在的服務彈性擴容機制也能夠很好的應對突發流量。
Docker-Compose 是用來管理容器的，類似用戶容器管家，我們有N多臺容器或者應用需要啟動的時候，如果手動去操作，是非常耗費時間的，如果有了 Docker-Compose 只需要壹個配置文件就可以幫我們搞定，但是 Docker-Compose 只能管理當前主機上的 Docker，不能去管理其他服務器上的服務。意思就是單機環境。
Docker Swarm 是由Docker 公司研發的壹款用來管理集群上的Docker容器工具，彌補了 Docker-Compose 單節點的缺陷， Docker Swarm 可以幫助我們啟動容器，監控容器的狀態，如果容器服務掛掉會重新啟動壹個新的容器，保證正常的對外提供服務，也支持服務之間的負載均衡。而且這些東西 Docker-Compose 是不支持的，
Kubernetes 它本身的角色定位是和 Docker Swarm 是壹樣的，也就是說他們負責的工作在容器領域來說是相同的部分，當然也要壹些不壹樣的特點， Kubernetes 是谷歌自己的產品，經過大量的實踐和宿主機的實驗，非常的成熟，所以 Kubernetes 正在成為容器編排領域的領導者，其 可配置性、可靠性和社區的廣大支持，從而超越了 Docker Swarm ，作為谷歌的開源項目，它和整個谷歌的雲平臺協調工作。
在下圖中，是K8S的壹個集群，在這個集群中包含三臺宿主機，這裏的每壹個方塊都是我們的物理虛擬機，通過這三個物理機，我們形成了壹個完整的集群，從角色劃分，可以分為兩種
打壹個比較形象的比喻，我們可以把Pod理解成壹個豆莢，容器就是裏面的豆子，是壹個***生體。
Pod裏面到底裝的是什麽？
具體怎麽部署Pod裏面的容器，是按照我們項目的特性和資源的分配進行合理選擇的。
pause容器：
Pause容器 全稱infrastucture container（又叫infra）基礎容器，作為init pod存在，其他pod都會從pause 容器中fork出來，這個容器對於Pod來說是必備的
壹個Pod中的應用容器***享同壹個資源：
在上圖中如果沒有 pause容器 ，我們的Nginx和Ghost，Pod內的容器想要彼此通信的話，都需要使用自己的IP地址和端口，才可以彼此進行訪問，如果有 pause容器 ，對於整個Pod來說，我們可以看做壹個整體，也就是我們的Nginx和Ghost直接使用localhost就可以進行訪問了，他們唯壹不同的就只是端口，這裏面可能看著覺得比較簡單，但其實是使用了很多網絡底層的東西才實現的，感興趣的小夥伴可以自行了解壹下。
在 Kubernetes 中，每個Pod都會被分配壹個單獨的IP地址，但是Pod和Pod之間，是無法直接進行交互的，如果想要進行網絡通信，必須要通過另外壹個組件才能交流，也就是我們的 Service
Service 是服務的意思，在K8S中 Service 主要工作就是將多個不同主機上的Pod，通過 Service 進行連通，讓Pod和Pod之間可以正常的通信
我們可以把 Service 看做壹個域名，而相同服務的Pod集群就是不同的ip地址， Service 是通過 Label Selector 來進行定義的。
使用NodePort提供外部訪問，只需要在每個Node上打開壹個主機的真實端口，這樣就可以通過Node的客戶端訪問到內部的Service。
Label 壹般以 kv的方式附件在各種對象上，Label 是壹個說明性的標簽，它有著很重要的作用，我們在部署容器的時候，在哪些Pod進行操作，都需要根據Label進行查找和篩選，我們可以理解Label是每壹個Pod的別名，只有取了名稱，作為K8S的Master主節點才能找到對應的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大家有什麽想要了解或者疑問的地方歡迎大家留言告訴我。
我是牧小農，壹個卑微的打工人，如果覺得文中的內容對妳有幫助，記得壹鍵三連，妳們的三連是小農最大的動力。