隨着技術發展，運維實現部署，實現應用編排，經歷了許多變化
早期，我們可以使用ansible，saltstack等批量工具進行安裝，編排
後來出現了docker，應用程序容器化，編排工具也發生了變化
這裏我用通俗一些的話簡單介紹下早期的docker三劍客，也就是docker compose、docker swarm和docker machine的應用場景 。
docker compose
它更加適用於單機編排，換句話說，docker compose適用於一個docker host來進行編排操作
docker swarm
我們可以理解爲它可以將多個docker host整合爲同一平臺下管理機制的一個集羣工具，通俗講就是docker swarm可以將多個docker host提供的計算資源整合成一個資源池，隨後docker compose再去編排時，只需要面向這一資源池進行編排即可，無論底層到底有什麼樣的docker host或是幾個dockerhost。
docker machine
docker swarm可以將多個docker host整合，那麼什麼樣的docker host能被它整合，滿足加入docker swarm中的一個成員呢？這就需要另一個工具，那就是docker machine，它可以將一個 docker host初始化成一個可以滿足加入docker swarm集羣的docker主機，我們也可以稱它爲一個預處理工具。
再後來出現了我們要講的主角--kubernetes（k8s）
kubernetes環境架構、概念、術語
集羣主機
可以說他就是一個集羣，組合多臺主機的資源，整合成一個大的資源池，並統一對外提供計算、存儲等能力的集羣，說白了就是找很多臺主機，每一臺主機上都安裝上 kubernetes的應用程序，並通過這些應用程序協同工作，把多個主機當成一個主機來使用，讓 所有主機來完成通信 ，從而完成彼此間的協調。
在k8s中，主機是分角色的，屬於有中心節點架構的集羣系統， 稱爲master/nodes結構模型
一組節點用來扮演master主節點，不需太多，能夠做冗餘，一般三個，是整個集羣的唯一入口。
nodes在做相關的工作，可以理解爲master是蜂王，用來指揮，node則爲工蜂，是幹活的。每一個node節點，都是來貢獻一部分計算能力，存儲能力等相關資源的節點，說白了就是運行容器的節點。
一個容器的啓動
用戶把創建啓動容器的請求先發給master，master當中有一個調度器去分析各node現有的可用資源狀態，然後找一個最適配的node節點利用本地的docker或者容器引擎把這個容器啓動起來。
要啓動這個容器需要鏡像，接受這個請求的node節點先會在本地是否有鏡像，若沒有，這個node節點則從外部的dockerhub或私有redis，亦或者是K8S內自己的redis上把鏡像拖下來，來啓動所被請求的容器。
Node組件
kubelet、kube-proxy
kubelet
在每個節點（node）上都要運行一個 worker 對容器進行生命週期的管理，這個 worker 程序就是 kubelet。簡單地說，kubelet 的主要功能就是定時從某個地方獲取節點上 pod/container 的期望狀態（運行什麼容器、運行的副本數量、網絡或者存儲如何配置等等），並調用對應的容器平臺接口達到這個狀態。
kubelet的主要作用可概括爲節點管理、pod管理、容器健康檢查、容器監控
節點管理
Kubelet在創建之初就會向API Server做自注冊，然後會定時報告節點的信息給API Server寫入到Etcd中。默認爲10秒。
pod管理
Kubelet會監聽API Server，如果發現對Pod有什麼操作，它就會作出相應的動作。例如發現有Pod與本Node進行了綁定。那麼Kubelet就會創建相應的Pod且調用Docker Client下載image並運行container。
容器健康檢查
有三種方式對容器做健康檢查：
1.在容器內部運行一個命令，如果該命令的退出狀態碼爲0，則表明容器健康。
2.TCP檢查。
3.HTTP檢查。
容器監控
Kubelet通過cAdvisor對該節點的各類資源進行監控。如果集羣需要這些監控到的資源信息，可以安裝一個組件Heapster。
Heapster會進行集羣級別的監控，它會通過Kubelet獲取到所有節點的各種資源信息，然後通過帶着關聯標籤的Pod分組這些信息。
如果再配合InfluxDB與Grafana，那麼就成爲一個完整的集羣監控系統了。
kube-proxy
每個pod上都會運行一個kube-proxy，負責接收並轉發請求。Kube-proxy的核心功能是將到Service的訪問請求轉發到後臺的某個具體的Pod。(service是一組pod的服務抽象，相當於一組pod的LB，負責將請求分發給對應的pod。service會爲這個LB提供一個IP，一般稱爲cluster IP)具體來說，就是實現了內部從pod到service和外部的從node port向service的訪問。
舉個例子，現在有podA，podB，podC和serviceAB。serviceAB是podA，podB的服務抽象(service)。那麼kube-proxy的作用就是可以將pod(不管是podA，podB或者podC)向serviceAB的請求，進行轉發到service所代表的一個具體pod(podA或者podB)上。請求的分配方法一般分配是採用輪詢方法進行分配。
另外，kubernetes還提供了一種在node節點上暴露一個端口，從而提供從外部訪問service的方式。
無論是通過ClusterIP+Port的方式還是NodeIP+NodePort的方式訪問Service，最終都會被節點的Iptables規則重定向到Kube-proxy監聽服務代理端口，當Kube-proxy監聽到Service的訪問請求後，它會找到最適合的Endpoints，然後將請求轉發過去。具體的路由選擇依據Round Robin算法及Service的Session會話保持這兩個特性。
Master包含三個組件。
controller-manager，scheduler，apiserver，他們的狀態和信息都保存在etcd中，所以etcd也要做冗餘
API server
kubernetes把master之上的一個組件稱爲API server，負責接收請求，解析請求，處理請求，它提供了HTTP Rest接口的關鍵服務進程，是kubernetes裏所有資源的增刪改查等操作的唯一入口，也是集羣的入口進程。
調度器-scheduler
如果客戶端請求創建一個容器，這個容器不應該是創建在master之上的，而應該是node之上，但是哪一個node更合適？此時就引出另一個概念，那就是調度器，叫做scheduler，負責去觀測每一個可用的node之上總共可用的計算資源和存儲資源，並根據用戶所請求創建的容器所需要的最低需求量、資源量去評估，哪一個節點更合適，因此kubernetes設計了一個兩級調度的方式來完成調度，第一步，先做預選，即先初步評估一下到底有多少個適合啓動請求容器需求的節點，第二步，從篩選出的node中挑選出最佳適配，取決於你的調度算法中的優選算法來決定
控制器管理器-controller-manager
kubernetes還擁有自愈能力。當其中一臺node節點上的容器故障了，它會在其他合適的節點上創建一臺相同的容器來，確保這個容器始終是健康的。那麼我們如何知道他是否故障呢？---持續監控它，所以kubernetes還實現了一大堆的叫控制器的組件，它會在本地不停的loop循環，持續性的負責去監控他所管理的容器是否是健康的，一旦發現問題，控制器就會向master APIserver發請求說我的容器掛了一個，你在幫我調度一個適配的node把容器啓動起來。
但是，當我們之前說的去負責持續監控的scheduler控制器出現問題了，又該如何解決呢？這就引出了master之上的另一重要組件，控制器管理器-controller-manager，他是kubernetes裏所有資源對象的自動化管理中心，可以理解爲資源對象的“大總管”，它負責去監控着每一個控制器是健康的。
node節點可動態增加到kubernetes集羣中，前提是這個節點已經正確安裝、配置和啓動了上述的關鍵進程，默認情況下，kubelet會向master註冊自己，這也是kubernetes推薦的node管理方式，一旦node被納入集羣管理範圍，kubelet會定時向master彙報自身的情況，以及之前有哪些pod在運行等，這樣master可以獲知每個node的資源使用情況，並實現高效均衡的資源調度策略。如果node沒有按時上報信息，則會被master判斷爲失戀，node狀態會被標記爲not ready，隨後master會觸發工作負載轉移流程。
Pod
是kubernetes最重要也是最基本的概念，每個Pod都會包含一個‘根容器’，還會包含一個或者多個緊密相連的業務容器，pod是kubernetes中最基本的管理單位，而不是 container。
flannel
kubernetes爲每個Pod都分配了唯一的IP地址，稱之爲PodIP，一個Pod裏的多個容器共享PodIP地址，要求底層網絡支持集羣內任意兩個Pod之間的直接通信，通常採用虛擬二層網絡技術來實現（Flannel）
Label
是一個key=value的鍵值對，其中key與value由用戶自己指定。可以附加到各種資源對象上，一個資源對象可以定義任意數量的Label。可以通過LabelSelector（標籤選擇器）查詢和篩選資源對象
Etcd
Etcd一種k-v存儲倉庫，可用於服務發現程序。在Kubernetes中就是用Etcd來存儲各種k-v對象的。
Etcd是Kubernetes的一個重要組件。當我們無論是創建Deployment也好，還是創建Service也好，各種資源對象信息都是寫在Etcd中了。
各個組件是通過API Server進行交流的，然而數據的來源是Etcd。所以維持Etcd的高可用是至關重要的。如果Etcd壞了，任何程序也無法正常運行了。
總結
Kubernetes的這些組件各自分別有着重要的功能。它們之間協同工作，共同保證了Kubernetes對於容器化應用的自動管理。
API Server起着橋樑的作用，各個組件都要通過它進行交互。Controller Manager像是集羣的大管家，管理着許多事務。Scheduler就像是一個調度亭，負責Pod的調度工作。
Kubelet則在每個節點上都有，像是一個執行者，真正創建、修改、銷燬Pod的工作都是由它來具體執行。
Kube-proxy像是負載均衡器，在外界需要對Pod進行訪問時它作爲代理進行路由工作，將具體的訪問分給某一具體的Pod實例。
Etcd則是Kubernetes的數據中心，用來存儲Kubernetes創建的各類資源對象信息。
這些組件缺一不可，無論少了哪一個Kubernetes都不能進行正常的工作。這裏大概講了下各組件的功能，感興趣的可以分析Kubernetes的源碼，github中就有。