Docker的第一類編排工具：

        1） docker compose（docker原生）：只能對一個主機上的容器進行編排，無法編排多個主機上的容器；

        2） docker swarm（docker原生）：可以對多個主機上的容器進行編排。

        3） docker machine（docker原生）：可以將一個主機迅速初始化到docker swarm叢集裡。

        以上三個稱為docker三劍客。

     Docker的第二類編排工具：    

         mesos：它不是docker的編排工具，而是資源分配工具。所以mesos必須要依賴於容器編排框架marathon。

     Docker的第三類編排工具：

        kubernetes(簡稱k8s)：這個容器編排工具佔用了80%的市場份額。

        有了容器和容器編排技術，對持續整合（CI）、持續交付Delivery（CD）和持續部署Deployment（CD）的需求變為可能，這也就是DevOps的理念。

        注意：DevOps並不是一種技術，而是一種運動，一種文化。

k8s的介紹

    k8s是2014年google對外開放的。

    Borg是谷歌內部非常棒的容器編排工具，k8s就是站在Borg基礎上開發出來的，所以k8s從一出世，就吸引了太多太多人的關注，直到今天為止，它也確實沒有辜負人們的期望。

    2017年是容器技術最輝煌的一年，AWS、微軟的雲技術、阿里雲等雲廠商開始對外宣佈，他們支援k8s。

     k8s的程式碼託管在github之上：

    k8s的特性：

        1）可以自動裝箱，即可以自動完成容器的部署，而不影響可用性；

        2）可以自我修復，如果容器崩潰了，可以1s內重新啟動，有了k8s後，我們不再關注個體，而是關注群體，有一個個體壞了，把它幹掉，換一個新的就行了；

        3）可以自動實現水平擴充套件，一個容器不夠，再啟動一個就是了；

        4）可以自動實現服務發現和負載均衡，也就是說可以自動發現每個微服務之間的關係，同時也可以自動對容器內多個服務做負載均衡；

        5） 可以實現自動釋出和回滾；

        6） 可以實現金鑰和配置管理,也就是說每個容器不是載入容器內的配置檔案，而是載入遠端伺服器上（配置中心）的配置檔案；

        7）可以實現儲存編排；

        8）可以實現任務的批次處理執行。

     k8s是一個有中心節點架構的叢集，由master節點（至少三個）和nodes節點(執行容器的節點)組成 。客戶的啟動容器等請求會先發給master節點，master節點有個排程器會分析node節點資源(cpu、記憶體)的可用狀態，找到最佳適配的node來啟動使用者請求的容器。

        

    master上的第一個元件叫排程器（Scheduler），它的工作原理有兩步：第一步排程器先做預選，即先評估到底有多少個node是符合容器需求的；第二步排程器再做優選，即在符合的node中選擇一個最佳的node來執行容器。

    如果node當機了，那麼託管在node之上的所有容器也就不見了。此時k8s可以在其他節點上建立出來和當機node上一模一樣的容器。

     另外，master上還有一個元件叫控制器，它會不停的Loop，用來週期性監控每個node的健康狀態；控制器是有多個的（因為有至少三個master）。

     再者，master上還有一個元件叫控制器管理器 (Controller-Mnager) ，控制器管理器用來監控著每個控制器的健康。

     在k8s上執行的最小單元不是容器，而是pod。pod可以理解為容器外殼，pod裡面裝的就是放容器的。一個pod裡面可以放多個容器，這些容器可以共享一個底層的網路名稱空間、儲存卷，這樣一來，pod對外更像一個虛擬機器。

    一般說來，一個pod裡只放一個容器；如果一個pod必須要放多個容器，那麼裡面有一個是主容器，其他都是輔助容器，輔助容器主要是為了輔助主容器的主程式的某些功能而設定的。

     一個pod裡面的所有容器只能執行在一個node上的。

     pod是k8s呼叫的原子單元，是個邏輯概念。

    終端使用者無需再關注pod執行在哪個node之上，這也就是雲的概念，也就是把很多的node做為一個資源池，來進行統一管理。

    pod儘量由控制器管理，而不要手工管理。

    pod可以分為兩類：

        a)自主式pod：即自我管理的pod。我們建立Pod，首先交給Apiserver，然後排程器排程給指定的node節點，。如果容器需要啟動，由node上kubelet元件來完成；如果node發生故障，那麼pod也就消失了。

        b）控制器管理的Pod(建議建立這種Pod)：這種Pod是有生命週期的物件。由master上的排程器將pod排程至某node進行執行或者停止。pod控制器後很多種， 最早的一種叫Replicaton Controller（副本控制器） ，意思是當我們啟動一個pod時，如果這個pod不夠了，會再啟動一個，這叫副本。副本控制器就控制副本的數量，一旦副本少了，就會自動再加一個。如果副本多於定義的個數，會被停止。也就是副本必須精確符合人們定義的個數。副本個數至少要兩個。如果一個pod副本所在node當機了，那麼會向ApiServer重新請求，Apiserver藉助排程器，到新節點建立一個新pod。滾動更新：比如我有個1.0版本的映象，現在又有個1.1版本的映象，那麼控制器管理的pod就會新啟動一個1.1版本的Pod，然後刪除1.0版本的pod，這叫滾動更新。同樣，k8s也支援回滾更新。 到了k8s新版本，又出現了Replica Set（副本集控制器），但是該控制器並不直接使用， 而是使用一個宣告更新的控制器Deployment，這個也是用的最多的。但是Deployment控制器只能管理那些無狀態的應用。而有狀態的應用是由Stateful Set控制器管理。對於Deployment控制器，它還支援二級控制器，叫 HPA（horizontalPodAutoscaler），該控制器可以自動水平擴充套件pod，也就是當一個pod壓力大時，HPA控制器會自動水平擴充套件加幾個新的pod來分解壓力，具體加幾個，HPA會根據當前節點的cpu、記憶體負荷來計算，一旦訪問量小了，HPA還會自動減少pod個數 。如果我們想在一個Node上只執行一個副本，需要用DaemonSet控制器。如果需要執行作業（如備份，清理資料等），需要conjob控制器。以上所講的都是pod的控制器，用來管理不同型別的pod。

     為了實現給pod分組，可以給pod打上標籤（Lablel），這樣就可以進行分組了。

    標籤選擇器（Lablel Selector）元件：是一個根據標籤來過濾符合要求的資源機制。

    客戶端是透過service來找到pod的，service是透過pod的標籤選擇器來找到pod的。service只是一個iptables方式的net地址轉換路由規則，不過到了k8s最新版本1.11，支援了ipvs方式的分發規則，支援各種排程演算法，這也就實現了負載均衡。。裝完k8s後，就需要建立一個DNS pod，這是因為service的名字需要DNS伺服器來進行解析。這種pod是k8s的組成部分，被稱為k8s基礎架構的pod，也被稱為k8s的附件，英文名叫AddOns。這種DNS是用來解析service名字的，而不是pod的，並且DNS名稱解析是K8s自動維護的，不需要我們人工干預。

     一句話，service裡面的地址存在iptables net或者ipvs裡面，service是用來排程流量的，而不會啟動或者停止容器的。

    然而，pod的啟動或者關閉、建立等是由控制器來做的，比如我們想建立一個nginx pod，就先建立一個Nginx控制器，nginx控制器自動就會幫我們建立nginx pod；然後我們再建立一個nginx service，把nginx pod釋出出去。

    service有兩種型別，一種是排程流量僅供k8s內部來使用，還有一種可以排程流量供k8s外部來使用。

    

    

     上圖中，我們應該明白了service是用來分發流量給pod的，控制器是用來建立、啟動和停止pod的，標籤選擇器是service用來根據標籤來識別每個pod的。 

    在k8s執行中，需要三種網路，第一種網路是需要各pod在一個網路中，而service在另外一個網路，即service的地址和pod的地址是不同網段的，pod的地址是配置在pod內部的網路名稱空間，是可以ping通的，但service的地址虛擬的，是假地址，只存在於iptables 或者ipvs裡面。另外node又存在另外一個網路，這樣就有三種網路。所以外部先到達node網路，然後再到service網路，最後才到pod網路。

    那麼pod之間是怎麼通訊的呢。同一個pod內的多個容器間透過lo進行通訊；各pod之間透過overlay network（疊加網路）進行通訊，即使pod之間跨主機，通訊也沒問題；pod與service之間透過閘道器（也就是docker 零橋的地址）進行通訊。

   node上有個元件叫kube-proxy，它負責和ApiServer進行通訊，kube-proxy一旦發現service背後的pod地址發生變化，kube-proxy就會把pod地址反映到iptables 或者ipvs中。所以service的管理是靠kube-proxy來實現的。

    在master(注意，master是有多個的)上的資料並不存在master本地，而是存在共享儲存DB中，這個共享DB叫etcd。etcd裡面資料是以key-value形式儲存的，叢集中所有狀態資訊都在etcd中，所以ectd要做冗餘，一般至少三個節點。etcd是透過https方式訪問的。etcd有一個埠是用來叢集內部通訊，另外 一個埠用來對ApiServer通訊。這樣一來，etcd內部通訊需要點對點的專門證書，對ApiServer通訊就要另外一套證書。另外，ApiServer向客戶端提供服務，也需要另外一套證書。同樣，ApiServer和node上的kubelet元件和kube-proxy元件通訊也需要CA證書。所以做K8s的部署，需要建立5個CA，這也是最難的。

    下面我們把k8s歸類為以下三類節點：master、node（上面有pod）和ectd（儲存叢集狀態資訊），它們彼此之間都是由http或https進行通訊的。我們知道網路也分為：pod網路，service網路和node網路。所以我們要構建出三類網路來，但是K8s自己不提供這三類網路，而是要依賴於第三方外掛CNI。

    

    k8s透過CNI（容器網路介面）外掛體系接入網路。目前常見的CNI外掛是flannel。其實網路只提供兩個功能，一個是給pod、service等提供ip地址的功能，另外還需要網路能提供網路測試的功能，來隔離不同Pod之間的通訊。

    flannel外掛只支援網路配置（供ip地址的功能），但不支援網路策略。

    CNI裡面的外掛calico可以同時支援網路配置和網路策略，但是calico的部署和使用非常難。

    於是，又有了第三個CNI外掛canel，它用flannel提供網路配置，用calico提供網路策略。這些外掛可以作為k8s之上的守護程式執行，也可以在k8s裡面的容器執行。

    名稱空間，可以實現不同類pod執行在不同的名稱空間中。比如可以把名稱空間分為開發名稱空間、生產名稱空間等。這樣透過網路策略來定義名稱空間之間、同一個名稱空間的pod之間的網路行為。

     本小節總結：

         1）master/node:

            a) master上包含的元件 ：API Server，Scheduler（排程器），Controller-Manager（控制器管理器）

            b) node上包含的元件： kubelet （用來和master通訊的一個元件，並試圖啟動本node上的容器等工作；另外啟動容器是由容器引擎來操作的，最流行的容器引擎是docker）、 docker引擎 （也可以用其他容器引擎）、 kube-proxy（ 負責和ApiServer進行通訊，kube-proxy一旦發現service背後的pod地址發生變化，kube-proxy就會把pod地址反映到iptables 或者ipvs中。所以service的管理是靠kube-proxy來實現的）

         2）Pod ：Lablel（標籤,kv格式），Lablel Selector（標籤選擇器）

 生產中k8s的最終架構圖（PaaS）