目錄
docker的編排工具
docker的第一類編排工具（docker三劍客）
- docker compose（docker原生）：只能對一個主機上的容器進行編排，無法編排多個主機上的容器
- docker swarm（docker原生）：可以對多個主機上的容器進行編排。
- docker machine（docker原生）：可以將一個主機迅速初始化到docker swarm集羣裏。
docker的第二類編排工具
- mesos：它不是docker的編排工具，而是資源分配工具。所以mesos必須要依賴與容器編排框架marathon
docker的第三類編排工具
- kubernets：簡稱k8s，這個容器編排工具佔用了80%的市場份額。
有了容器和容器編排技術，對於持續集成（CI）、持續交付Delivery（CD）和持續部署Deployment（CD）的需求變爲可能，這也就是devopos的理念。
k8s的介紹
- k8s是2014年google對外開放的，2015年7月正式發佈，截至目前最穩定的版本是1.9
- k8s是基於Borg開發出來的，Borg是google內部非常好的容器編排工具。
- 2017年是容器技術最輝煌的一年，aws、微軟、阿里雲等技術廠商對外宣佈支持k8s。
- k8s是google開源的一個容器編排引擎，它支持自動化部署、大規模伸縮、應用容器化管理。在生產環境中部署一個應用程序，通常要部署該應用的多個實例以便對應用請求進行負載均衡。
- 在k8s中，可以創建多個容器，每個容器裏面運行一個應用實例，然後通過內置的負載均衡策略，實現對這一組應用實例的管理、發現、訪問，而這些細節都不需要運維人員去進行復雜的手工配置和處理。
- k8s由Golang語言開發，具有輕量化、模塊化、便攜以及可擴展的特點。
- k8s的代碼託管在github上：https://github.com/kubernetes/kubernetes/releases
- k8s是一個有中心節點的架構集羣，由master節點（至少三個）和nodes節點（運行容器的節點）組成，客戶的啓動容器等請求會先發給master節點，master節點有個調度器會分析node節點資源（cpu、內存）的可用狀態，找到最佳適配的node來啓動用戶請求的容器。
- master上的第一個組件叫作調度器（scheduler）
scheduler的工作原理：
第一步調度器先做預選，即先評估有多少個node符合容器需求；
第二步調度器再做優選，即在符合的node中選擇一個最佳的node來運作容器。
如果node宕機了，那麼託管在node之上的所有容器也就不見了，此時k8s可以在其他節點創建出來和宕機node上一模一樣的容器
-
master上還有一個組件叫作控制器，它會不停的Loop，用來週期性監控每個node的健康狀態，控制器是有多個的（因爲至少有三個master）。
-
master上有一個組件叫作控制器管理器（Controller-Manager），用來監控每個控制器的健康。
k8s的特性
- 自動修復：在節點故障時重新啓動失敗的容器，替換和重新部署，保證預期的副本數量；殺死健康檢查失敗的容器，並且在爲準備好之前不會處理客戶端的請求，確保線上服務不中斷。
- 彈性伸縮：使用命令、UI或者基於CPU的使用自動快速擴容和縮容應用程序實例，保證應用業務高峯併發時的高可用性；業務低峯時回收資源，以最小的成本運行服務。
- 自動部署和回滾：k8s採用滾動更新策略更新應用，一次更新一個Pod，而不是同時刪除所有Pod，如果更新過程中出現問題，將回滾更改，確保升級不受影響業務。
- 服務發現和負載均衡：k8s爲多個容器提供一個統一的訪問入口（內部IP地址和一個DNS名稱），並且負載均衡關聯的所有容器，使得用戶無需考慮IP問題。
- 機密和配置管理：管理機密數據和應用程序配置，而不需要把敏感數據暴露在鏡像裏，提高敏感數據的安全性，並且可以將一些常用的配置存儲在k8s中，方便應用程序使用。
- 存儲編排：掛載外部存儲系統，無論是來自本地存儲，公有云（如AWS），還是網絡存儲（如NFS、GlusterFS、CEPH）都作爲集羣資源的一部分使用，極大地提高存儲使用靈活性。
- 批處理：提供一次性任務，定時任務，滿足批量數據處理和分析的場景。
pod的分類
pod的概念
- 在k8s上運行的最小單元不是容器，而是pod，pod可以理解爲容器外殼，pod裏面裝的就是容器。
- 一個pod裏面可以放多個容器，這些容器可以共享一個底層的網絡名稱空間、存儲卷，這樣pod對外更像一個虛擬機。
- 一般來說，一個pod裏只放一個容器；如果一個pod必須要放多個容器，那麼裏面有一個是主容器，其他都是輔助容器，輔助容器主要是爲了輔助主容器的主程序的某些功能而設置的
- 一個pod裏面的所有容器只能運行在一個node上，最終用戶無需再關注pod運行在哪個node之上。也就是把很多的node作爲一個資源池，來進行統一管理。pod儘量有控制器管理，而不要手工管理。
自主式pod
- 自我管理的pod。
- 創建pod，首先交給ApiServer，然後調度器調度給指定的node節點。如果容器需要啓動，由node上的kubelet組件來完成；如果node發送故障，那麼pod也就消失了
控制器管理的pod
- 一般建議創建控制器管理的pod，這種pod是有生命週期的對象。
- 由master上的調度器將pod調度至某node進行運行或者停止，Replica Set（副本集控制器），但是該控制器並不直接使用，而是使用一個聲明更新的控制器Deployment，這個也是應用最多的。
- Deployment控制器只能管理哪些無狀態的應用；有狀態的應用是由Stateful Set控制器管理。
- 對於Deployment控制器，它還支持二級控制器，叫HPA（horizontalPodAutoscaler），該控制器可以自動水平擴展pod，也就是當一個pod壓力大時，HPA控制器會自動水平擴展加幾個新的pod來分解壓力，具體加幾個，HPA會根據當前節點的cpu、內存負荷來計算，一旦訪問量小了，HPA還會自動減少pod個數。
- 如果我們想在一個node上只運行一個副本，需要用DaemonSet控制器
- 如果需要運作作業（如備份、清理數據等），需要conjob控制器。
- 以上所講的都是pod的控制器，用來管理不同類型的pod。
service
- 爲了實現pod分組，可以給pod打上標籤Lablel，這樣就可以進行分組了
Lablel Selector（標籤選擇器）
- Lablel Selector組件：是一個根據標籤來過濾符合要求的資源機制
- 客戶端是通過service來找到pod的，service是通過pod標籤選擇器來找到pod的
- service只是一個iptables方式的net地址轉換器路由規則，到了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中需要三種網絡
1.需要各個pod在一個網絡中
2.service在另外一個網絡中，即service的地址和pod的地址是不同網段的，pod的地址是配置在pod內部的網絡名稱空間，是可以ping通的，但是service的地址是虛擬的，是假地址，只存在於iptables或者ipvs中。
3.node又存在於另外一個網絡。
總結：所以外部先到達node網絡，然後到達service網絡，最後纔到pod網絡
通信
pod、service通信
- 同一個pod內的多個容器通過lo進行通信
- 各個pod之間通過overlay network（疊加網絡）進行通信，即使pod之間跨主機，通信也沒問題
- pod於service之間通過網關（也就是docker 0的地址）進行通信
1.node上有個組件叫kube-proxy，它負責和ApiServer進行通信，kube-proxy一旦發現service背後的pod地址發生變化，就會改變service在ipvs中的pod地址，所以service的管理是靠kube-proxy來實現的。
2.kubelet--node上用於和master通信的一個組件，試圖啓動node上的容器，啓動容器是由容器引擎（docker）來操作
認證與存儲
存儲etcd
- 在master（有多個master）上的數據並不存儲在master本地，而是存儲在在共享數據庫中，這個共享的數據庫叫作etcd。
- etcd裏面的數據庫是以k-v形式存儲的，集羣中所有狀態信息都在etcd中，所以要對etcd做冗餘，一般是三個節點。
- etcd是通過https方式訪問的
CA認證
- etcd有一個端口是用來集羣內部通信的，另外一個端口用來對ApiServer通信。這樣一來etcd內部通訊需要點對點的專門證書，對ApiServer通信就需要另外一套證書
- 此外ApiServer向客戶端提供服務，也需要一套證書。同樣，ApiServer和node上的kubelet組件和kube-proxy組件通信也需要CA證書
- 所以做k8s部署，需要建立5個CA
插件
- 我們把k8s歸爲三類節點：master、node（內部有pod）和etcd（存儲集羣狀態信息），它們彼此之間通過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裏面的容器運行
總結：
1.master上包含的組件：API Server、Scheduler（調度器）、Controller-Manager（控制器管理器）
2.node上包含的組件：kubelet（用來和master通信的一個組件，並且試圖啓動node上的容器等工作；另外啓動容器是由容器引擎來操作的，最近流行的容器引擎是docker）、docker引擎（也可以用其他容器引擎）、kube-proxy（負責和ApiServer進行通信，kube-proxy一旦發現service背後的pod地址發生變化，kube-proxy就會把pod地址反映給iptables或者ipvs，所以service的管理就是靠kube-proxy實現的）
3.pod：Lablel（標籤，k-v格式）、Lablel selector(標籤選擇器)