DevOps和kubernetes概述

kubernetes和DevOps介紹

1.爲何要用kubernetes

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

2.常見的3款容器編排工具

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

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

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

3.devops概念

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

CI （Continued integrate 持續集成）
CD（Continued Delivery 持續交付 ）
CD（Continued Deployment 持續部署 ）

4.devops和docker的關係

docker容器的出現和容器編排工具的出現使得devops這一套流程（持續集成、持續交付、持續部署）更容易實現了，在原來的場景中，咱們須要針對目標的環境構建不一樣環境的應用，部署方式也不盡相同。而有了docker以後，就不須要關注這些，由於docker能夠作到，一次構建，處處運行。咱們能夠只構建一次（構建爲鏡像），只要目標主機上有docker（不須要關注目標主機的環境），咱們就能夠將應用跑起來。雖然docker能夠很好的將devops文化實現，可是也帶來一個缺點，在衆多微服務中，咱們天天可能須要去處理各類服務的崩潰，而服務間的依賴調用關係也及其複雜，這對咱們解決問題帶來了很大的複雜度。要很好的解決這個問題。咱們就須要用到容器編排工具。

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代碼所在的位置

在www.github.com下面

源碼位置：

https://github.com/kubernetes/kubernetes

發行版本：

https://github.com/kubernetes/kubernetes/releases

阿里雲支持源生的k8s，提供按鈕，咱們點擊按鈕，就能夠部署k8s集羣

三、kubernetes特性：

（1）自動裝箱
基於資源依賴及其餘約束可以自動完成容器的部署並且不影響其可用性
（2）自我修復
一旦某一個容器崩潰，因爲容器輕量級的特色，kubernetes可以在1秒中左右迅速啓動新的容器。
（3）只要物理平臺的資源支撐是足夠獲得，kubernetes就能夠無限制的增長容器。
（4）服務發現和負載均衡
當咱們須要在k8s上運行不少應用程序的時候，一個服務能夠經過自動發現的形式找到它所依賴的服務，並且每一種服務若是起了多個容器，他能實現自動負載均衡。
（5）自動發佈回滾
執行平常的運維任務
（6）祕鑰和配置管理
k8s經過配置中心的方式來保存全部應用的配置信息，當容器啓動時，會去配置中心加載對應的配置信息。
（7）存儲編排
根據容器自身的需求自動建立可以知足自身須要存儲卷。

kubernetes架構

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

1.master節點的核心組件

（1）API Server
API Server專門負責接收、解析、處理請求。
（2）Scheduler（調度器）
它負責觀測每個node上總共可用的cpu計算和存儲資源，並根據用戶請求建立的容器所須要的資源量在衆多node中挑選出一個符合條件的node來建立容器。kubernetes設計了一個兩級調度的的方式來完成調度，第一步先進行預選；對每個node進行評估，選出全部符合的node。第二步再在選出來的node上根據「調度算法」中的優選算法來選出一個最佳的node。
（3）Controller
負責檢測pod的健康的
（4） Controller Manager
它負責監控每個控制器的健康狀態，若是控制器不健康，由Controller Manager會從新生成一個控制器接管。Controller Manager若是down機，會有從master上的Controller Manager接管。

2.etcd

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

3.node節點的核心組件

（1）kubelet
負責與master通訊，接受master調度過來的任務並執行，可能包括；建立Pod，管理Pod的健康狀態、建立存儲卷、啓動容器等
（2）容器引擎
docker，做爲容器引擎負責運行Pod中的容器
（3）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規則。
（4）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或規則
（5）namespace（名稱空間）
它是k8s的名稱空間，用來將集羣中的不一樣類型的Pod隔離開來，它提供的不是真正意義上的網絡邊界，而是管理邊界。之後咱們能夠刪除一個名稱空間，就能夠將Pod所有刪除。它不是Pod的邊界，Pod若是沒有網絡策略限制，一樣能夠訪問其餘名稱空間中的Pod。