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介绍

1、kubernetes的由来

最早在2014年对外发布，kubernetes是由google的几位工程师用Go语言根据google内部强大的容器编排工具Borg改写而来。而后在容器技术广为应用之后，kubernetes在短短几年之内，发展迅速，它深受人们的喜爱。kubernetes最早的版本1.0在2015年发布，到现在为止发布的版本已经到了1.12版。在2017年容器技术发展历史上具有里程碑意义的一年，因为在这一年中，aws、微软云、阿里云等等著名的云计算公司都开始宣布原生支持kubernetes 。还有的平台可以做到把自己的k8s对外提供服务，让用户可以直接在上面部署应用程序，提供容器级服务的环境。这些大型云厂商的支持， 使得k8s在业内已经受到了广泛的认可和支持。而且在2017年10月，docker宣布在他们的企业版发行版当中，原生同时支持swarm和kubernetes两种工具。

2、kubernetes代码托管的位置

托管在www.github.com下面

源码位置：

https://github.com/kubernetes/kubernetes

发行版本：

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

阿里云支持源生的k8s，提供按钮，我们点击按钮，就可以部署k8s集群

3、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。