Kubernetes 之 基礎概念理解

隨着技術發展，運維實現部署，實現應用編排，經歷了許多變化

早期，咱們可使用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中就有。