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。