【个人Linux，我作主！】DevOps文化及kubernetes概述

（1）DevOps文化
DevOps即运维自动化，目前在国外，互联网巨头如Google、Amazon、Facebook、LinkedIn、Netflix、Airbnb，传统软件公司如Adobe、IBM、微软、SAP等，亦或是网络业务非核心企业如苹果、沃尔玛、可口可乐、星巴克等都在采用DevOps或提供相关支持产品。那么DevOps到底是怎样一回事呢。
DevOps一词来自于Development和Operations的组合，突出重视软件开发人员和运维人员的沟通合做，经过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。DevOps概念早先升温于2009年的欧洲，因传统模式的运维之痛而生。DevOps是为了填补开发端和运维端之间的信息鸿沟，改善团队之间的协做关系。不过须要澄清的一点是，开发到运维，中间还有测试环节。DevOps其实包含了三个部分：开发、测试和运维。换句话说，DevOps但愿作到的是软件产品交付过程当中IT工具链的打通，使得各个团队减小时间损耗，更加高效地协同工做。
应用程序的架构在早期是单体架构，在早期应用程序是比较简单的，因此仍是能够招架住，可是到后来人们发现单体应用程序难以承载愈来愈复杂的系统，就算能够横向扩展，可是单体应用的内部业务复杂度也会致使扩展很容易达到上限，因此单体的下一个时代就是分层架构，让应用程序各自分离开开发；再日后就是微服务，不是在简单的分层，而是把每个应用都拆解成一个微小的服务，只干一件事，因此一个传统的3级应用程序须要拆解成数百个微型服务，让彼此之间进行协做。所以微服务自然的和容器很是契合，由于容器在分发、构建、部署起来都是很是方便的，因此把为服务和对应的容器结合起来后迅速的让它们找到了适合于落地的实现方案。包括DevOps理念也是如此，早期的DevOps技术中的交互环节和部署环节由于环境因素异构致使部署起来及其困难，由于docker技术的出现恰好弥补了这个裂缝，使得DevOps很是容易实现了。
在DevOps中有三种概念，其中第一个CI（CONTINUOUS INTEGRATION）是指持续集成，它属于开发人员的自动化流程，成功的CI意味着应用代码的更新会按期构建、测试并合并到共享存储库中，该解决方案能够解决在一次开发中有太多应用分支，从而致使相互冲突的问题；第二个CD（CONTINUOUS DELIVERY）是指持续交付，一般是指开发人员对应用的更改会自动进行错误测试并上传到存储库，而后由运维团队将其部署到实时生产环境中。这旨在解决开发和运维团队之间可见性及沟通较差的问题，所以持续交付的目的就是确保尽量减小部署新代码时所需的工做量；第三个CD（CONTINUOUS DEPLOYMENT）是持续部署，指的是自动将开发人员的更改从存储库发布到生产环境，以供客户使用，它主要是为了解决因手动流程下降应用交付速度，从而提升运维团队超负荷的问题，持续部署以持续交付的优点为根基，实现了管道后续阶段的自动化。

由上所述，相信你们对DevOps有了必定的了解。可是除了触及工具链以外，做为文化和技术的方法论，DevOps还须要公司在组织文化上的变革。回顾软件行业的研发模式，能够发现大体有三个阶段：瀑布式开发、敏捷开发、DevOps。DevOps早在十几年前就有人提出来，可是为何最近才开始受到愈来愈多的企业重视和实践呢？由于DevOps的发展是独木不成林的，如今有愈来愈多的技术支撑。微服务架构理念、容器技术使得DevOps的实施变得更加容易，计算能力和云环境的发展使得快速开发的产品能够马上得到更普遍的使用。
那么DevOps的好处是什么呢？它的一个巨大的好处就是能够高效交付，这也正好是它的初衷。Puppet和DevOps Research and Assessment（DORA）主办了2016年DevOps调查报告中，根据全球4600位各IT公司的技术工做者的提交数据统计，得出高效公司能够完成平均每一年1460次部署。与低效组织相比，高效组织的部署频繁200倍，产品投入使用速度快2555倍，服务恢复速度快24倍。在工做内容的时间分配上，低效者多花22%的时间用在为规划好或者重复工做上，而高效者却能够多花29%的时间用在新的工做上。因此这里的高效不只仅指公司产出的效率提升，还指员工的工做质量获得提高。DevOps另一个好处就是会改善公司组织文化、提升员工的参与感。员工们变得更高效，也更有知足和成就感；调查显示高效员工的雇员净推荐值更高，即对公司更加认同。
那么DevOps为何会兴起呢？第一，首先条件成熟，技术的发展使得DevOps有了更多的配合。早期时，你们虽然意识到这个问题，可是苦于当时没有完善丰富的技术工具，是一种理想很丰满的状况。DevOps的实现能够基于新兴的容器技术；也能够在自动化运维工具Puppet、SaltStack、Ansible以后的延伸；还能够构建在传统的Cloud Foundry、OpenShift等PaaS厂商之上。第二，是来自市场的外部需求，IT行业已经愈来愈于市场的经济发展紧密挂钩，专家们认为IT将会由支持中心变成利润驱动中心。事实上，这个变化已经开始了，这不只体如今Google、苹果这些大企业中，并且也发生在传统行业中，好比出租车业务中的Uber、酒店连锁行业中的Airbnb、图书经销商Amazon等。可否让公司的IT配套方案及时跟上市场需求的步伐，在今天显得相当重要。第三，对于工程师而言，他们也是DevOps的受益者。工具链的打通使得开发者们在交付软件时能够完成生产环境的构建、测试和运行，正如Amazon的CTO那句让人印象深入的话：“谁开发谁运行。”（You build it,you run it）
（2）kubernetes概述
Kubernetes是Google开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理。在生产环境中部署一个应用程序时，一般要部署该应用的多个实例以便对应用请求进行负载均衡，
Kubernetes，又称为k8s或者简称为“kube”，是一种可自动实施Linux容器操做的开源平台。它能够帮助用户省去应用容器化过程的许多手动部署和扩展操做。也就是说，您能够将运行Linux容器的多组主机汇集在一块儿，由Kubernetes帮助您轻松高效地管理这些集群。并且，这些集群可跨公共云、私有云或混合云部署主机。所以，对于要求快速扩展的云原生应用而言（例如借助Apache Kafka进行的实时数据流处理），Kubernetes是理想的托管平台。
Kubernetes最初由Google的工程师开发和设计。Google是最先研发Linux容器技术的企业之一（组件了cgroups），曾公开分享介绍Google如何将一切都运行于容器之中（这个是Google云服务背后的技术）。Google每周会启用超过20亿个容器--所有由内部平台Borg支撑。Borg是Kubernetes的前身，多年来开发Borg的经验教训成了影响Kubernetes中许多技术的主要因素。
为何须要Kubernetes呢？真正的生产型应用会涉及多个容器。这些容器必须跨多个服务器主机进行部署。容器安全性须要多层部署，所以可能会比较复杂。但Kubernetes有助于解决这一问题。Kubernetes能够提供所需的编排和管理功能，以便您针对这些工做负载大规模部署容器。借助Kubernetes编排功能，您能够构建多个容器的应用服务、跨集群调度、扩展这些容器，并长期持续管理这些容器的健康情况。有了Kubernetes，您即可切实采起一些措施来提升IT安全性。Kubernetes还须要与联网、存储、安全性、遥测和其余服务整合，以提供全面的容器基础架构。
Redhat公司目前也已经花大价钱压住在容器编排工具之上了，同时这个也体如今Kubernetes已经成为了红帽产品中的PaaS，你们知道Kubernetes属于开源技术，因此，没有正式的技术支持机构能够为您的商业业务提供支持。若是生产过程当中Kubernetes出现实施问题，您必定会感到很是担忧，您的客户可能也会如此。这时就是企业Kubernetes容器平台大展身手的时候了。OpenShift是企业版的Kubernetes，此外，它还具有更多功能。OpenShift引入了额外的先进技术，从而使Kubernetes成为可供企业使用的强大平台，这些技术包括：注册表、联网、遥测、安全性、自动化和服务。借助OpenShift的可扩展性以及控制和编排功能，您的开发人员能够构建新的容器化应用、对其进行托管并在云端加以部署，从而轻松快速地将各类奇思妙想转变为新业务。这些都是由开源领域的领导者红帽所开发，并提供全面支持的。
Kubernetes的代码托管在GitHub之上，官方站点为https://github.com/kubernetes ，咱们能够看到目前K8S版本的迭代速度。同时亚马逊的AWS、微软的Azure、阿里云等大型云厂商也已经宣布原生支持K8S。

（3）Kubernetes的特性
Kubernetes的主要特性主要体如今，第一它可以实现自动装箱，基于资源依赖以及其余约束可以自动完成容器的部署并且不影响其可用性。第二是可以实现自我修复，一旦一个容器崩溃了，能够在一秒中启动，把缺失的服务kill掉从新起一个就能够了，因此有了Kubernetes容器编排平台之后，咱们更多关注的是群体，而再也不是个体了。第三是能自动实现水平扩展，一个容器不够能够再起一个，不断的进行向上扩展，只要物理平台的资源是足够的，它还可以实现自动的服务发现和负载均衡，同时还可以实现自动的发布和回滚。第四个是能够支持密钥的配置和管理，咱们若是启动了一个容器后，但愿换一种配置来运行，咱们定义一个ENTRYPOINT脚本，这个脚本可以接受用户传递给容器一些变量，把这些变量的值转换为容器内的应用程序可读取的配置信息，从而完成容器化应用配置，这是由于早期的应用程序不是面向云原生而开发的，因此那些应用程序须要读取配置文件来获取配置，而云原生开发的最好能基于环境变量获取配置，若是咱们使用容器编排平台让容器启动自动化了，但每一次启动还要手工传环境变量的值这是一个很麻烦的事，因此咱们须要一个外部的组件保存这些配置信息于外部，当镜像启动为容器时，咱们只须要让镜像加载配置中心当中的配置信息就能够完成配置。第五个是Kubernetes还能实现存储编排，让存储卷实现动态供给，也就意味着某一个容器须要用到存储卷时根据容器自身的需求建立可以知足它的须要的存储卷，从而实现存储编排。第六个是可以实现任务的批处理运行。
（4）Kubernetes的架构
Kubernetes其实就是一个集群，要组合多台主机的资源整合成一个大的资源池统一对外提供计算、存储等能力的集群。咱们在许多台主机上都安装上Kubernetes的相关应用程序，并经过应用程序协同工做，把多个主机当一台主机来使用。可是在Kubernetes当中集群是分角色的，咱们知道模型一般分为两种，一种是P2P的，例如redis没有中心节点，每个节点自己都可以直接接受服务请求，能路由请求的这种模型，第二种是由中心节点的集群，例如MySQL的主从复制，有一个节点是主节点，其余的都和它进行同步，那么K8S就是一个有中心节点架构的集群系统，即master/nodes模型，master主节点通常不须要太多，通常可以作冗余有3个就足够了，而nodes咱们称之为worker，就相似于蜂王和工蜂的概念。客户端的请求先发送给Master，Master中会有一个调度器去分析各node现有的可用资源状态，找一个最佳适配运行用户所请求的容器的节点，并把它调度上去，由这个node本地的容器引擎负责把docker启动起来，这个node负责启动容器时先检查是否本地是否有镜像，若是没有须要到Registry将镜像拖下来，固然咱们也能够建私有Registry，并且Registry本身也能够是一个容器，咱们能够把私有Registry托管在Kubernetes自身之上。

在Kubernetes上第一个组件名为API Server，能够负责接收请求、解析请求、处理请求。第二个组件为，若是用户的请求时建立一个容器，那么这个容器不该该运行在Master之上，而应该运行在Node之上，那么哪个Node更合用，这个应该是由Master之上的组件scheduler调度器来决定，它负责去观测每个Node上的总共计算资源，并根据用户所请求容器所需建立的资源量的下限来评估哪个Node节点最合适。咱们不能根据容器中的应用程序运行与否判断容器的健康与否，咱们能够根据额外定义的可用性探测机制来探测服务的可用性，若是一旦容器中的应用挂了，咱们又须要容器始终是运行的，在Node之上有一个应用程序，第三个就是kubelet，这个应用程序就是确保容器始终处于运行状态的。Kubernetes还运行了不少控制器的应用程序，负责去监控所管理的每个容器是不是健康的，一旦发现容器是不健康的，控制器就向Master的API Server发请求，而后由scheduler调度从其余节点挑一个合适的并从新起一个容器。用于监控容器健康的控制器不健康了，那么容器的健康也就没法获得保证了，因此在Master之上还有第四个组件控制器管理器（Controller-Manager），由控制器管理器负责监控每个控制器是否健康的，若是控制器不健康了，由控制器管理器确保它是健康的，而控制器管理器（Controller-Manager）则是经过冗余来保证其自身的可用性。因此从这个角度说Master是集群的大脑，它有如上的几个核心组件。
在K8S之上运行的最小单元不在是容器，Pod是K8S之上调度的最小的逻辑单元。在Pod内能够运行容器，一个Pod内包含多个容器，众多容器共享同一个UTS、Network、IPC三个名称空间，而另外三个User、Mount、PID三个名称空间是互相隔离的。并且同一个Pod内的各容器还共享第二种资源即存储卷，存储卷不在属于容器，存储卷是属于Pod的。通常来讲同一个Pod只包含一个容器，除非容器之间有很是紧密的关系须要放在同一个Pod中。若是一个Pod中须要放多个容器，一般有一个容器是主容器，其余容器是辅助主容器中的应用程序完成更多功能而存在的，例如主容器中运行Nginx，会生成不少日志，这时候就能够在辅助的容器（边车）中运行ELK等日志收集程序。因此调度器调度的是一个Pod，Node运行的也是一个Pod，而Pod是一个原子单元。

理论上说Node能够是任何形式的计算设备，只要可以有传统意义上的CPU、内存等，而且能装上Kubernetes的集群代理程序，均可以做为Kubernetes的一个份子来进行工做。例以下图，全部的node节点做为一个总体看做为一个大的计算池使用，有x个CPU和y容量的内存，由Kube_Cluster来统一管理的，Master就拥有这样一个统一的视图，当用户请求在Master建立资源时，咱们能够作一个统一资源池的调度和评估，这样一来终端用户就无需再关心咱们的资源是运行在哪一个节点上了，因此就实现了云计算。

若是未来咱们想分类管理某一类Pod，咱们应该怎么挑选出来某一类统一功能的Pod呢，为了可以作Pod识别，咱们须要在Pod之上附加一些元数据，即key-value类型的标签，在建立完Pod的时候能够给Pod打上标签，让人能够基于标签的值来识别出Pod来，例如咱们建立4个Nginx的Pod，咱们给每一个Pod加一个标签叫App，而后它的值是nginx，这样之后咱们根据键和值信息就能够把一类的Pod分拣出来了，因此这个筛选的机制咱们是靠一个组件标签选择器（Label Selector）来实现的。

—————— 本文至此结束，感谢阅读 ——————