簡介

      K8S全稱kubernetes，其起源于谷歌內部的一個叫Borg系統，谷歌在這方面已經有十幾年的使用經驗，所以，在Docker技術面世后，谷歌使用自家的Golang語言重寫了Borg系統，這就是K8S。

      在K8S的物理架構上，分為Master節點和Node節點，Master節點負責整個集群的管理工作，Node節點負責運行具體的容器。我們可以認為Master就是整個K8S集群的大腦，Node就是具體執行大腦指令的苦力。接下來我們將介紹一下Master和Node節點的各個組成部分。

Master

     Master節點主要由三個組件構成：API Server、Scheduler、Controller Manager，接下來我們逐一介紹一下這三個組件的各自的功能。

API Server

      API Server從字面意思來看，就是提供一組API的服務，其作用是接收處理用戶請求。比如，我們需要新建一個容器，那么就可以通過向API Server發送一個請求，由API Server來完成創建容器的后續功能。

Scheduler

      在K8S集群中，Node節點一般都會有多個，當我們需要對容器進行操作的時候，我們需要評估一下這些Node節點是否滿足容器的運行條件，例如我們需要啟動一個容器，這個容器需要2G內存，那么我們就需要在所有Node節點上查找出哪些節點滿足我們的資源需求。這項工作就是由我們的Scheduler來幫助我們完成的，Scheduler會幫助我們選出最佳的運行容器的Node節點。

Controller Manage

       我們都知道，K8S為我們提供了故障自愈的功能，那這是怎么實現的呢？比如我們在Node節點上運行著一些容器，如果此時容器異常退出了，那此時K8S需要為我們自動拉起一個新的容器，或者一臺Node節點宕機了，那此節點上的容器就需要自動調度到其他的節點上去。那問題來了，K8S是怎么知道容器是否健康呢？答案是通過一種叫控制器的東西，控制器就是一個死循環，不停的檢測其托管的容器的狀態，一旦發現某個容器狀態異常了，那么就自動為我們修復這個容器。

      那么，問題又來了，如果這個控制器退出了呢？那此時我們的容器異常退出后，K8S就無法獲取容器的健康狀態了。此時，就需要我們的Controller Manager了，這個組件就是用來為我們監測所有的控制器的狀態的。那么問題又來了，如果Controller Manager也退出了怎么辦呢？如果Controller Manager也退出了，那就表示當前這臺Master出現了異常，這是我們需要避免的問題，所以，一般在一個K8S集群中，我們往往需要多個Master節點，保持Master節點的高可用。

Etcd

      以上就是在Master節點上的三個組件的功能，我們知道，通過API Server可以來發送請求，通過Scheduler來實現選擇容器具體運行在的Node節點，通過Controller Manager來管理控制器。而且我們還要保證Master節點的高可用。那么問題又來了，集群的信息保存在哪呢？答案是Etcd中。      K8S使用Etcd作為其外部存儲，所有的集群信息都會保存在Etcd集群之中，所有的Master節點都從同一個Etcd集群來獲取數據，這就保證了所有的Master節點都可以無差別的管理我們的K8S集群。所以，在部署K8S集群的Master節點是，Etcd服務也是必不可少的，雖然Etcd并不是K8S的組件，但是K8S要使用其來存儲數據。關于Etcd的相關內容，我們將放在部署的文章中做介紹，此處就不在贅述。大家只需要記住，Etcd服務是用來存儲K8S集群信息的就可以了。

Node

        Node節點主要由三個部分組成：容器引擎，kubelet，kube-proxy，其中容器引擎并不屬于K8S本身的組件，且容器引擎也可以有多種，只不過目前應用最廣泛的是Docker容器引擎，本文也是基于Docker容器引擎來闡述的，所以，在后文中容器引擎就默認是Docker了。由此可知，我們所有的Node節點上都需要先部署上Docker，然后再來安裝剩下的兩個組件。

Kubelete

      我們介紹Master節點時說過，當我們需要對一個Pod進行操作時，Master上的Scheduler會幫我們選擇最優的Node節點，之后在這個節點上來完成我們的操作。那這些具體的操作是由誰來完成的呢？答案就是kubelet組件，Node節點上的kubelet組件就是用來具體執行我們操作的。

CNI網絡插件

      上面我們介紹了Node上的K8S組件，我們知道在一個K8S集群中，往往有很多臺Node節點，每個Node節點上都會有若干個pod，具有相同標簽的pod就會加入一個service資源中來提供服務，那么在不同Node主機上的pod的IP地址會不會沖突，又能不能互相通信呢？我們已經知道，在同一臺宿主機上的不同容器之間是可以相互通信的，但是在不同主機上的pod節點默認是不能通信的，為了解決這個問題，我們還需要在Node節點上部署CNI網絡插件來管理我們的pod網絡，這個CNI網絡插件并不是K8S官方提供的，常用的CNI網絡插件都是第三方提供的，最常用的有Calica、Flannel>