1 容器編排工具概述
k8s擴充docker單個容器的管理功能，實作誇多主機的問題，容器編排要負責網絡，存儲，安全等問題。
容器編排系統，完成以下功能：
1.為docker提供私有的registry
2.提供網絡功能
3.提供共享存儲
4.確定容器間的安全
5.telemetry
容器編排的三個主要工具
1.docker的三劍客:docker machine+swarm+compose
docker machine,快速建構docker容器,加入叢集。
swarm：把容器加入到叢集中來
compose:面向swarm,實作容器的編排
2.mesos+marathon：系統資源排程架構，可以排程hadoop或者容器，不是專門為容器編排設定的
3.kubernetes:把容器歸類到一起，最小排程機關是容器集（pod）
本文主要介紹kubernetes的相關内容
2 k8s整體概述
k8s，可監控系統的資源使用情況，進行容器的自動增加或者收縮，這就是所謂的容器編排
kubernetes:舵手，飛行員，參考谷歌内部的大規模内部容器排程系統borg實作，使用go語言開發。代碼托管在github上，連結：https://github.com/kubernetes/kubernetes
k8s特性如下：
1.自動裝箱，自動容器的部署，不影響可用性
2.自我修複，如容器崩潰後快速重新啟動新的容器
3.自動實作水準擴充
4.自動實作服務發現和負載均衡
5.自動釋出和復原
6.支援密鑰和配置管理，把應用程式的配置資訊通過服務來加載，而不是加載本地的配置。實作配置的統一
7.實作存儲編排
8.任務的批處理運作
k8s的叢集至少有兩個主機組成：master + node ,即為master/node架構，master為叢集的控制台，master主機需要做備援，一般建議為3台，而node主機不需要，因為node的主要作用是運作pod，貢獻計算能力和存儲能力，而pod控制器會自動管控pod資源，如果資源少，pod控制器會自動建立pod，即pod控制器會嚴格按照使用者指定的副本來管理pod的數量。用戶端的請求下發給master,即把建立和啟動容器的請求發給master,master中的排程器分析各node現有的資源狀态，把請求調用到對應的node啟動容器。
可以了解為k8s把容器抽象為pod來管理1到多個彼此間有非常緊密聯系的容器，但是lamp的容器主機a,m,p隻是有關聯，不能說是非常緊密聯系，是以a,m,p都要運作在三個不同的pod上。
在k8s中，要運作幾個pod，是需要定義一個配置檔案，在這個配置檔案裡定義用哪個控制器啟動和控制幾個pod，在每個pod裡要定義那幾台容器，k8s通過這個配置檔案，去建立一個控制器，由此控制器來管控這些pod,如果這些pod的某幾個down掉後，控制器會通過健康監控功能，随時監控pod，發現pod異常後,根據定義的政策進行操作，即可以進行自愈。
k8s内部需要5套證書，手動建立或者自動生成，分别為，etcd内部通信需要一套ca和對應證書，etcd與外部通信也要有一套ca和對應證書。apiserver間通信需要一套證書，apiserver與node間通信需要一套證書，node和pod間通信需要一套ca
目前而言，還不能實作把所有的業務都遷到k8s上，如存儲，因為這個是有狀态應用，出現錯誤排查很麻煩，目前而且，k8s主要是運作無狀态應用。
是以一般而言，負載均衡器運作在k8s之外，nginx或者tomcat這種無狀态的應用運作于k8s叢集内部，而資料庫，如mysql，zabbix，zoopkeeper，有狀态的，一般運作于k8s外部，通過網絡連接配接，實作k8s叢集的pod調用這些外部的有狀态應用。
k8s叢集架構如下
k8s的master和node的詳細架構如下
k8s的叢集元件如下：
master: apiserver,scheduler,controller-manager,etcd
node:kubelet(agent),kube-proxy,docker(container engine)
registry:harbor，屬于叢集外部的
addons(附件)：kube-dns,ui(如 dashboard)等等。在叢集運作正常後，在叢集上運作pod實作。
k8s部署叢集整體環境架構
注意，下圖的ip可根據實際環境調整
3 master主機
master 有三個最關鍵的元件，apiserver，scheduler，controller-manager，運作為三個守護程序：
apiserver:負責接入請求的入口，解析請求，處理請求，即網關，任何到達請求必須經過apiserver
scheduler:請求到達後，由scheduler計算後端node的相關資源，如cpu或者記憶體使用情況後，負責排程到合适的node,并啟動pod,即標明某一節點後，有節點的kubelet負責節點上的操作如啟動pod，即scheduler會先做預選,選擇滿足條件的node，然後再做優選,最合适的node，啟動pod
controller-manager:控制器管理器，統一管控不同類型的資源,監控master上每個控制器的健康性，可以在每個master叢集上做備援高可用。其中，控制器用于確定已建立的容器處于健康狀态。
controller：控制器，自動建立pod資源(容器啟動),根據使用者的需求啟動和建立pod，可以在m個節點上運作n個容器，控制器根據label來識别pod。，使得pod能夠按照指定的數量運作。
controller 通過 label selector 來關聯 pod (lable),注意controller隻是用來管理pod的健康性，不能進行pod流量導向，即管理pod,確定pod副本數量嚴格符合使用者的定義。
每一組pod都需要獨立的控制器來運作，實作跨節點自愈，管控pod的生命周期。控制器也是通過便簽和便簽選擇器來實作感覺自己管控組内的pod
在k8s環境中，推薦使用控制器管理的pod，控制器有如下幾種：
replicationcontroller。嚴格控制容器的副本數和滾動更新pod,在更新過程臨時超出副本數。也支援滾動復原操作。
relicaset:聲明更新控制器
deployment:負責無狀态應用pod控制，支援二級控制器（hpa，horizontalpodautoscaler水準pod自動控制器）。
statefulset:負責有狀态應用pod控制
deamonset:守護程序集，作用是在叢集中每一個node上都啟用一個pod副本，如果pod down了，deamonset會自動重新開機這個pod，如果新增node，會自動添加。即自動下載下傳鏡像，在這個node上啟用這個pod。
job,ctonjob:周期性pod控制，如臨時任務的job。
不同的控制器，滿足客戶不同類型的pod資源運作。
master 主機其他元件：
label selector ；标簽選擇器，根據标簽來選擇符合條件的資源對象的機制，不僅僅用于pod資源，所有的對象都可以打上标簽。k/v格式的資料。service和controller都是根據标簽和标簽控制器來識别pod資源。
etcd：分布式的高性能的鍵值存儲的資料庫系統，儲存叢集的對象狀态資訊，如apiserver對所有主機的操作結果，如建立pod,删除pod，排程pod的結果狀态資訊都儲存在etcd中，如果這個插件異常，則整個叢集運作都将異常，因為etcd異常後，整個叢集的狀态協定都将不能正常工作。是以etcd需要做高可用，防止單點故障。專門的元件，另外一個主機上安裝的元件，建議至少三個節點，為restfull風格的叢集。為https協定。
master示意圖如下
注意，api,ui,cli都想api server發送請求
4 node主機
node節點上主要有三個主鍵，kubelet，kube-proxy，container engine（這裡用docker）,介紹如下
kubelet:相當于k8s的節點級的agent，執行當地任務，如目前節點的啟動和目前節點的狀态狀态監測，和apiserver進行互動。
kube-proxy：為目前節點的pod生成iptables或者ipvs規則,實作了将使用者請求排程到後端pod,為service元件服務，負責與apiserver随時保持通信，一旦發現某一service後的pod發生改變，需要将改變儲存在apiserver中，而apiserver内容發生改變後，會生成通知事件，使得所有關聯apiserver的元件都能收到，而 kube-proxy可以收到這個通知事件，一旦發現某一service背後的pod資訊發生改變，kube-proxy就會把改變反應在本地的iptables或者ipvs規則上，實作動态的變化。kube-proxy有三個模型，userspace(名稱空間，和docker的名稱空間有差別，),iptables,ipvs，負責實作service的定義
container engine：作用是負責啟動或者運作有kubelete啟動的容器，如docker
此外，node節點上還有addons（附件），如dns,可以動态變動dns解析内容，如service的名稱改了，會自動觸發dns的記錄進行更改。
node示意圖如下
5 邏輯元件介紹
除了master和node上的關鍵元件，還有邏輯元件介紹如下
service:
service 通過 label selector 來關聯 pod (lable) ，提供一個固定端點，使得使用者的請求流量導向後端的pod，service為pod中的應用的用戶端提供一個固定的通路端點，即clusterip:serviceport實作、另外通過dns addons實作服務把主機名和clusterip做解析，使得通路能夠通過主機名和端口來實作
service是在應用前面加一個代理層，這個代理層的主機名對應的ip不變，手動建立，比如nginx要配置後端的tomcat，那麼配置檔案上寫入的後端tomcat的ip應該是代理層上（service）的主機名（因為ip也可能變化），防止tomcat重建後ip變化。代理層上通過service的後端pod的label來感覺後端pod,是以，無論pod的ip位址怎麼變化，隻要label不變，service通過便簽選擇器（label selector）來動态關聯後端的pod。同理，由于應用可能被删掉重新建立，是以，在所有的應用前，都需要有service，相當于是提供其他應用統一通路的入口。實際上，service,提供穩定的通路入口和排程功能，根據label來排程，隻要pod的label不變，那麼即使pod的ip和端口變化了，都能被service識别，因為service根據label來識别pod對象。可以跨主機實作的，service相當于是由kube-proxy建立的iptables的dnat規則或者ipvs規則。k8s1.11版本中，已經把規則調整為ipvs規則。當一個請求到達service後，service會排程到對應的node上。如果service被誤删了，那麼ip位址可能會變化，為了防止這種情況發生，k8s有一個附件，dns服務，完成服務發現，動态按需完成資源的遷移和改變，如每次建立一個service，就會把service對應的名稱和ip關系，放入到這個dns的解析庫中，那麼當service被删掉時，對應解析記錄就會被删掉，當service重建後，就會在這個解析庫中建立對應的解析記錄。是以隻要前端應用配置的是service的主機名，那麼即使service重建，ip變更也不影響請求的排程。如果沒有了service，那麼前後端應用的銜接就不能固定，服務異常。
當用戶端發起請求，請求都先到servcie，service收到請求後，通過本地的iptables或者ipvs規則排程到後端的pod，如果pod不在同一node上，那麼存在一個跨主機排程問題。使用疊加網絡（overlay）解決不同主機上網絡問題，所有的pod都在同一網段，service才能實作正常排程。當主控端把請求送出去後，封包封裝了兩個ip，容器ip和主控端網卡的ip，這樣，容器才能實作跨主機間的網絡通路。即k8s要求所有的pod在同一網段，而且可以使用這個網絡直接通信。注意，service的ip和pod的ip不在同一網段，而且service的ip不是真的ip，即不配在某一個網卡上，僅僅是iptables上的某一個符号。是以service的ip是不能被ping通，service的ip被稱為cluster ip， pod的ip稱為 pod ip。
service作為k8s的對象有service的名稱，service的名稱，相當于是服務的名稱，而名稱可以被dns解析。service有兩種類型，一種是隻能pod内部通路，一種是可以供k8s外部通路。
每個應用的pod都要有專用的service進行排程。
存儲卷，pod級别的卷，pod間存在卷的問題，是以，資料建議使用外部的專用卷，而不要使用挂載的本地容器的卷。當容器重建時，需要加載相同的卷。存儲卷有四級概念，pv(持久卷)，pvc(持久卷申請),volume(存儲卷)，volume mount(存儲卷挂載)。
pod：
pod指容器集，原子排程單元，一個pod的所有容器運作于同一節點。k8s排程的目标是pod,，pod可以了解為容器的外殼，pod是k8s最小的排程單元。一個pod可以包含多個容器。一組聯系非常緊密的容器組成pod，同一組pod共享networks,uts,storage,volumes,通過ipc機制進行通訊，跨pod的容器，需要借助于外部網絡插件進行通訊，每一個pod有一個podip。一個pod相當于是傳統意義上的虛拟機。存儲卷屬于pod。一般而言，一個pod僅放一個容器。一個pod内的所有容器隻能運作于同一node上。
k8s的最核心功能就是為了運作pod，其他元件是為了pod能夠正常運作而執行的。
pod可以分為兩類：
1.自主式pod,
2.控制器管理的pod
一個pod上有兩類中繼資料，label 和 annotation
label：标簽，對資料類型和程度要求嚴格，
annotation：注解，用于存儲自己定義的複雜中繼資料，用來描述pod的屬性
外部請求通路内部的pod，有三級轉發，第一級，先到nodeip（主控端ip）對應的端口,然後被轉為cluster ip的service 端口，然後轉換為podip的containerport。
注意，在k8s叢集外部還有一個排程器（load blance）,這個排程器跟k8s沒有關系，需要手動管理。這個排程器可借助keepalive實作高可用。
k8s的運作空間需要分區，即分成邏輯區域，如用于區分不同項目，每個邏輯區域為一個名詞空間（usersapce），這裡的名稱空間為k8s特有的名稱空間,和docker的名稱空間有差別。用于隔離pod。實作了網絡邊界的隔離。提供了管理的邊界。網絡政策可以實作不同名稱空間是否可以實作網絡通路。預設情況下，不需要建立namespace。
6 k8s通信
service位址和pod位址在不同網段，service位址為虛拟位址，不配在pod上或主機上，外部通路時，先到節點網絡，再打service網絡，最後代理給pod網絡。
同一pod内的多個容器通過lo通信
各pod間的通信，pod通過overlay network的隧道轉發實作跨主機間封包轉發，實作直接通信。
其中，疊加網絡
1.一個資料包(或幀)封裝在另一個資料包内;被封裝的包轉發到隧道端點後再被拆裝。
2.疊加網絡就是使用這種所謂“包内之包”的技術安全地将一個網絡隐藏在另一個 網絡中，然後将網絡區段進行遷移。
pod和service間的通信，
cni:容器網絡集接口，網絡解決方案，有三種不同ip，ip位址解釋如下
node ip,節點網絡,主控端實體ip
cluster ip,叢集ip，為service 網絡，為固定的接入端口，即service元件的ip位址，不會配置在任何網絡接口上，clusterip定義在iptables或ipvs規則中。k8s叢集自己管控和提供
pod ip ,屬于pod網絡，為pod提供ip位址，使得pod間直接通信，但是，叢集間pod通信要借助于 cluster ip，pod和叢集外通信，還要借助于node ip。pod網絡要通過cni規範借助于外部的虛拟化網絡模型實作，為pod配置ip位址，使得pod間能夠通信。
其中，虛拟化網絡解決方案有如下幾種較為著名的插件：
flannel：簡單易用，不支援網絡政策，配置本地網絡協定棧，進而為運作在這個主機上的pod提供ip,但是，不能提供網絡政策的功能。
project calico:支援網絡政策和網絡配置，預設基于bgp建構網絡，實作直接通訊，三層隧道網絡，目前生産主要使用這個模型
canel:是flannel+calico的結合，用flannel提供網絡，calico實作政策配置
kube-rote
weave network
k8s的網絡模型如下