Kubernetes第一回（架構概述）

1、kubernetes和Devops概述

一、爲何要用kubernetes

 在docker尚未出現前，咱們去安裝部署應用程序時，好比nginx、php等web架構站點。咱們要去手動操做部署，很是繁瑣耗時，後來有了ansible等運維工具。這種工具其實是一個應用編排工具，可以實現安裝、配置、啓動。甚至能夠按照定義好的playbook完成對多種有着依賴關係的應用程序的快速部署。代替了繁瑣易出錯的手動操做。而這種工具操做的對象是直接部署在操做系統中的應用程序。docker出現之後，各類應用程序都被封裝在容器中運行（容器化）。因爲操做對象從實際的應用程序對象變成了容器內的應用，他們自己提供的訪問控制和管理接口是不一樣的。因此ansible等運維工具沒法完成容器運行的編排工做。後來，出現了專門用於容器編排的工具

1.一、常見的3款容器編排工具

• docker compose：它是docker自主研發，它只能面向單個的docker host來執行編排操做，後來docker爲了讓docker compose能支持多機的編排工做，推出了docker swarm和docker machine兩個組件

• mesos：mesos是Apache下的開源分佈式資源管理框架，它可以把一個IDC當中全部硬件所提供的計算資源統一調度和分配，可是它面向的上層接口不是容器運行的接口，而只是資源分配工具。它不能直接託管運行容器。因此在mesos基礎之上，它必需要依靠一個面向容器編排的框架（marathon）

• kubernetes：它是由google公司在2014年發佈的一款開源的容器編排引擎，用來管理雲平臺中多個主機上的容器化的應用。kubernetes的目標是讓部署容器化的應用變的簡單高效。到如今爲止，kubernetes已經佔據了容器編排市場的80%。

二、devops概念：

DevOps是（Development和Operations的組合詞）是一組過程、方法、文化與系統的統稱，depvops重視的是將持續集成、持續交付再到持續部署的一整套流程的解決方案

• CI  （Continued integrate  持續集成）

• CD（Continued Delivery  持續交付 ）

• CD（Continued Deployment  持續部署 ）

2.一、devops和docker的關係

docker容器的出現和容器編排工具的出現使得devops這一套流程（持續集成、持續交付、持續部署）更容易實現了，在原來的場景中，咱們須要針對目標的環境構建不一樣環境的應用，部署方式也不盡相同。而有了docker以後，就不須要關注這些，由於docker能夠作到，一次構建，處處運行。咱們能夠只構建一次（構建爲鏡像），只要目標主機上有docker（不須要關注目標主機的環境），咱們就能夠將應用跑起來。

雖然docker能夠很好的將devops文化實現，可是也帶來一個缺點，在衆多微服務中，咱們天天可能須要去處理各類服務的崩潰，而服務間的依賴調用關係也及其複雜，這對咱們解決問題帶來了很大的複雜度。要很好的解決這個問題。咱們就須要用到容器編排工具。

2、kubernetes

一、kubernetes的由來

最先在2014年對外發布，kubernetes是由google的幾位工程師用Go語言根據google內部強大的容器編排工具Borg改寫而來。然後在容器技術廣爲應用以後，kubernetes在短短几年以內，發展迅速，它深受人們的喜好。kubernetes最先的版本1.0在2015年發佈，到如今爲止發佈的版本已經到了1.12版。在2017年容器技術發展歷史上具備里程碑意義的一年，由於在這一年中，aws、微軟雲、阿里雲等等著名的雲計算公司都開始宣佈原生支持kubernetes 。還有的平臺能夠作到把本身的k8s對外提供服務，讓用戶能夠直接在上面部署應用程序，提供容器級服務的環境。這些大型雲廠商的支持， 使得k8s在業內已經受到了普遍的承認和支持。並且在2017年10月，docker宣佈在他們的企業版發行版當中，原生同時支持swarm和kubernetes兩種工具。

二、kubernetes的特性

• 自動裝箱：基於資源依賴及其餘約束可以自動完成容器的部署並且不影響其可用性
  

• 自我修復：一旦某一個容器崩潰，因爲容器輕量級的特色，kubernetes可以在1秒中左右迅速啓動新的容器。 

• 自動水平擴展：只要物理平臺的資源支撐是足夠獲得，kubernetes就能夠無限制的增長容器。

• 服務發現和負載均衡：當咱們須要在k8s上運行不少應用程序的時候，一個服務能夠經過自動發現的形式找到它所依賴的服務，並且每一種服務若是起了多個容器，他能實現自動負載均衡。

• 自動發佈回滾：

• 祕鑰和配置管理：k8s經過配置中心的方式來保存全部應用的配置信息，當容器啓動時，會去配置中心加載對應的配置信息。

• 存儲編排：根據容器自身的需求自動建立存儲卷。

• 任務批處理運行：

三、kubernetes架構

kubernetes是從咱們傳統運維角度來講的集羣，組合多臺主機的資源整合成一個大的資源池並統一對外提供計算存儲等能力的集羣。每個主機上都安裝了k8s的相關應用程序，並經過這個應用程序協同工做，把多個主機當一個主機來使用。可是在k8s集羣中，主機是分角色的，k8s是一個有中心節點架構的集羣系統（master/nodes模型）。k8s通常有3個master節點以實現HA，N個node節點提供計算存儲能力以運行容器。master負責接受客戶端的請求，然後master負責分析各個node現有的可用資源狀態，將請求調度到一個可運行容器的最佳的node節點。最後，node節點首先在本地檢查是否有鏡像（去Registry上pull鏡像）最後在以Pod（node節點的最小調度單元）的形式將容器啓動起來。這是kubernetes的功能模型。

3.一、master節點的核心組件

• API Server：    API Server專門負責接收、解析、接收集羣中的各個狀態信息、處理請求。
  

• Scheduler（調度器）：    它負責觀測每個node上總共可用的cpu計算和存儲資源，並根據用戶請求建立的容器所須要的資源量在衆多node中挑選出一個符合條件的node來建立容器。kubernetes設計了一個兩級調度的的方式來完成調度，第一步先進行預選；對每個node進行評估，選出全部符合的node。第二步再在選出來的node上根據「調度算法」中的優選算法來選出一個最佳的node。

•  Controller Manager：   它負責監控每個控制器的健康狀態，若是控制器不健康，由Controller Manager會從新生成一個控制器接管。Controller Manager若是down機，會有從master上的Controller Manager接管

3.二、etcd節點

它是一個key：value的數據庫，相似redis。可是它還具備redis不具有的集羣選舉功能，負責存儲集羣中API Server中保存的各個狀態信息（持久化到共享存儲），以防止集羣中的主master節點宕機，其餘master節點能夠讀取到以前的集羣信息。etcd一樣是restfull風格的集羣，經過http或https通訊。在一個k8s集羣中，etcd是高可用的。防止一個etcd宕機以後不能進行集羣leader選舉。

3.三、node節點的核心組件

• kubelet：負責與master通訊，接受master調度過來的任務並執行，可能包括；建立Pod，管理Pod的健康狀態、建立存儲卷、啓動容器等

• 容器引擎：docker，做爲容器引擎負責運行Pod中的容器

• Service：在k8s集羣中，Pod故障、從新建立會致使主機名、IP地址常常變化，這就致使了客戶端沒法與變化以後的Pod進行通訊，因而k8s爲每一組提供同類服務的Pod在它的客戶端之間添加了一箇中間層（Service），Service未來自客戶端的請求代理到衆多的Pod上面，因此它同時也是調度器。而Pod故障重啓以後，Service經過「label selector」來將新的Pod對象關聯。最後Service在自動探測新Pod對象的IP地址、端口、主機名等信息。Service並非k8s中的組件，它是一個iptables的Dnet規則，k8s在1.11版已經替換成了IPVS規則。

• Kube-Proxy：節點中的每個Pod發生變化之後，結果是保存在API Server中。然後API Server會生成一個通知事件，Kube-Proxy負責接收API Server的通知事件，一旦發現了某一個Service背後的Pod信息發生了改變（IP、Port等），由Kube-Proxy負責在每個節點上將變化後的service轉換成IPVS或IPtables規則中。而每建立一個Service，Service的實現也要靠Kube-Proxy在每個節點上建立成IPVS或規則

• namespace（名稱空間）：它是k8s的名稱空間，用來將集羣中的不一樣類型的Pod隔離開來，它提供的不是真正意義上的網絡邊界，而是管理邊界。之後咱們能夠刪除一個名稱空間，就能夠將Pod所有刪除。它不是Pod的邊界，Pod若是沒有網絡策略限制，一樣能夠訪問其餘名稱空間中的Pod。

3.四、Pod是什麼

Pod是k8s的最小邏輯運行、調度單元。在k8s中，調度器並不直接調度容器的運行，它調度的目標是Pod，Pod是k8s中對容器抽象的封裝，能夠理解成一個外殼。Pod內部主要用來放容器，通常Pod中只有一個容器，Pod中也能夠有多個容器，所以Pod有個特性，就是共享底層的名稱空間Net、UTS、IPC，在這三個名稱空間之上還能夠共享第三種資源「存儲卷」。這使得咱們能夠構建較爲精細的容器間通訊架構。

k8s經過在Pod上添加一些元數據信息來將k8s的資源管理（Pod資源等）變得簡單，而Tag是衆多元數據中的一種，，Tag是Key="Value"的形式，經過label selector（標籤選擇器），kubelet在管理Pod，分組Pod，識別Pod就容易了。

Pod種類：

• 自主式Pod：指的是自我管理的Pod，Pod在建立之後，提交給API Server，API Server接收之後藉助於調度器將其調度至指定的node節點，由node啓動此Pod，若是Pod中的容器出現故障須要重啓容器，這個操做是由kubelet來完成。若是節點故障，pod將消失。

• 控制器管理的Pod：正是Pod控制器這種機制的引入，使得在k8s集羣的設計中，Pod能夠成爲有生命週期的對象，由調度器將Pod調度至集羣中的某節點運行。

  
  

3.五、Pod控制器

• ReplicationController：它能夠自動管理Pod，當Pod少於或者多餘指定的數量，他會根據策略自動重啓Pod、刪除、建立Pod。Pod控制器還能夠實現滾動更新，將Pod內部運行的容器鏡像從1個版本更新到另外一個版本。而且能夠回退鏡像版本。在k8s早期版本中，只支持ReplicationController一個Pod控制器

• ReplicaSet：新版本k8s中加入，它不直接使用，它有一個聲明式更新的控制器Deployment

• Deployment：只能負責管理那些無狀態的應用，它還支持HPA的二級控制器，經過HPA（水平Pod自動伸縮控制器），來監控Pod是否足夠，不足則建立新的Pod

• StatefulSet：負責管理那些有狀態的應用Pod

• DaemonSet：若是咱們要在集羣中的某一個節點運行一個副本，而不是隨意副本，就須要用到

• Job：管理那些須要特定時間，而時間又不固定的，執行任務就能夠退出的Pod。好比腳本的執行等操做

• Cronjob：管理那些須要週期運行的任務的Pod
  

4、Kubernetes的網絡模型

一、kubernetes要求整個k8s集羣中要有3種網絡

• 各Pod要運行在一個網絡中，Pod的網絡是配置在Pod內部的網絡名稱空間上的，至關於主機的IP地址，稱爲Pod網絡

• 各service要運行在一個網絡中，這個網絡是虛擬的，沒法ping通，存在於IPVS或IPtables的規則中。稱爲集羣網絡

• 各節點網絡，每一個節點都有一個網絡。稱爲節點網絡

要想接入外部網絡，要先到達節點網絡，由節點網絡代理至集羣網絡，最後在由集羣網絡代理到Pod網絡

二、3類通訊

• 本地通訊：同一Pod內多個容器間通訊，經過Lo接口便可

• 各Pod之間通訊：不一樣docker主機之間的Pod通訊要經過配置IPtables規則的net規則來通訊，這樣通過多層轉發會影響效率，而使用物理橋接通訊會產生廣播風暴，k8s使用Overlay Network（疊加網絡），經過隧道的方式來轉發2層報文。雖然跨主機，但好像工做在同一個二層網絡當中
  

• Pod與Service間通訊：因爲Service地址只是主機上的iptables或ipvs規則中的地址，因此只須要在容器中將網關地址指向到docker0橋地址。而Service的變更或新建都由node節點上的Kube-Proxy組件管理

 

三、kubernetes的網絡實現

k8s並不提供集羣中的3種網絡管理與網絡策略功能，而是依賴於第三方插件，k8s經過CNI（Container  Network  Interface）插件體系來接入外部的網絡服務解決方案，CNI要求網絡解決方案必需要支持網絡功能（能提供地址），還必需要支持網絡策略的功能（爲了安全，隔離限制不一樣名稱空間中的Pod之間的訪問或者限制相同名稱空間中的各Pod之間的訪問）。只要一個網絡服務提供商可以遵循CNI開發這個服務，它就能做爲k8s的網絡解決方案來使用。這些網絡解決方案能夠以附件的方式託管在集羣之上（能夠運行爲Pod），它是一個特殊Pod，它須要共享節點的網絡名稱空間。這樣就能實現以容器的方式來運行系統管理的命令。目前能夠用的CNI插件有不少，常見的有；

• flannel：只支持網絡配置

• calico：支持網絡配置、網絡策略。基於BGP的協議來實現直接路由通訊。可是它部署和使用困難。

• canel：結合上面兩種插件的。