强推！2019年最火的容器、K8S和DevOps入门都在这了

做者： Pasca

来源：蛋蛋团（公众号ID：dandan_tuan）

前言

咱们回顾企业IT架构演进的整个历史，不难看出企业主流形态都是依据冯诺依曼架构形态从计算机高度集中化，再到多用户多任务的大型机和小型机，简单归纳这个时期的特征就是复杂且缺少统一的标准。

直到80年代X86服务器的诞生，企业IT形态走向水平分层：站点层、应用层、中间件层甚至是数据访问层。 若是用一个词来形容发展中的互联网行业演变，我会说：突飞猛进。

传统IT架构在互联网急剧膨胀的数据增加下，没法实现很好的解耦以及有效的分配资源。因而，以云计算为驱动的第三次IT架构融合变革浪潮，经过虚拟化与云调度管理技术，将不一样厂家彼此孤立的计算、存储以及网络设备逻辑上虚拟成一个“资源池”。同时应运而生的，还有容器、K8S、DevOps等技术与理念成为云计算产业新热点。

“天下大势，合久必分，分久必合！”， 这里也体如今IT架构，当咱们了解了这种趋势后，从而去根据业务需求选择部署最适合的架构带来成本的下降和效率的提高。

“工欲善其事，必先利其器！”，做为互联网从业者，不管是否隶属于架构师职责，了解如容器、K8S等技术以及相辅而成的DevOps部署模式，才能更好的“玩转云计算”。

思考一个事物，笔者喜欢以2W1H逻辑模型去分析。

是什么？为何会出现？出现后会带来怎样的价值？本文文章脉络也是如此。

一、容器是什么？

容器，见到这个词，咱们可能脑中就有一个“装东西”概念。 没错，简单来说，容器就是装“应用”封装，而后在任何位置均可以运行。就如同容器的logo，相似于一个集装箱，容器能够全部货物打包，而且互相隔离。

视角移到软件开发，当咱们在本地电脑上开发时（生产环节），可能本地已经适配好了所需的库文件、扩展包、开发工具和开发框架等。而后在一个模拟生产环境的机器上进行测试经过后被用于生产环境（测试和上线）。 假设没有用到容器，这三者的开发环境多是不同的，而后致使一系列的 Bug。

可是容器完美解决了这个问题。

正如 Docker 解释的，“容器镜像是软件的一个轻量的、独立的、可执行的包，包括了执行它所须要的全部东西：代码、运行环境、系统工具、系统库、设置。”

这表明着，一旦一个应用被封装成容器，那么它所依赖的下层环境就再也不重要了。它能够在任何地方运行，甚至在混合云环境下也能够。

有数据代表，持续集成和持续部署 (CI/CD) 经过 Docker 加速应用管道自动化和应用部署，交付速度提升至少 13 倍。 固然，这只是容器的一个优势，由于若是仅仅是这一个，虚拟机也能办到这个事情。 打包成镜像而后移交到另一台虚拟机，可是容器有一个虚拟机没法媲美的优势: 轻量。

这里的轻量指的是相比较于虚拟机动辄分钟级的启动时间，容器甚至能够在毫秒级别启动，而且相同宿主机，能够为容器给成千上百的应用独立部署。 并且，相比较于虚拟机，容器的性能IO更接近于原生，这也是半死不活的DotCloud公司，当开源了这个公司内部项目后，不管是谷歌仍是微软，又或者AWS，纷纷看到了容器的前景，加入docker开源社区。DotCloud也所以成为了业内使人仰慕的公司。

而对于容器，咱们只须要记住三大特性：轻量、标准和独立。

二、K8S是什么？

首先，咱们来了解K8S是什么。

K8S全称为Kubernetes，其谐音就是K8S，而后如今通俗讲K8S都是指Kubernetes。 上面咱们简单的介绍了下Docker，其实Docker只是应用容器引擎，也就是建立容器的工具。

Docker技术的三大核心概念，分别是：

• 镜像（Image）
• 容器（Container）
• 仓库（Repository）。

前二者咱们很好理解，镜像是一种轻量级、可执行的独立软件包，它包含运行某个软件所需的全部内容，容器就是承载这个镜像运行的实例。

那这个仓库又是什么呢？

咱们先来思考下，有了镜像后，能够放到容器中去执行。可是从开发到测试，再到正式上线，这些镜像是怎么流转的呢？

仓库，就是提供一个集中的存储、分发镜像的服务。而每一个仓库经过不一样的标签（Tag）对不一样的镜像分类。

通常而言，一个仓库会包含同一个软件不一样版本的镜像，而标签就经常使用于对应该软件的各个版本。

在K8S的章节里讲了如此多关于容器知识，为啥不写进前文呢？

主要是由于，K8S自己就是依托于容器而诞生的，二者密不可分。

K8S是一个开源的用于多个主机虚拟成一个云平台后进行容器资源管理和应用编排引擎，致力于让部署容器化应用简单而且高效，提供了应用的全生命周期管理，如应用部署，规划，更新，维护等机制。

这里有两个关键词须要重点mark下：多个主机、容器化应用。

K8S为何出现？就是由于有了K8S，咱们能够将整个大规模的服务器对计算资源抽象化经过一个个容器进行自动化且细致化管理，将最终的应用服务交给用户。

尽管谷歌是开源的K8S，但在谷歌内部已经大量使用了容器承载数据中心不一样类型的应用负载，如谷歌搜索、大数据仍是仍是谷歌地图等。当K8S发布后，众多的的互联网企业能够享受到链接众多计算机成为集群资源池的好处。

也是由于K8S管理着不一样的数据中心，每一个数据中心都由成千上万的服务器联接组成。因此通常来讲，一个K8S系统也叫作K8S集群。 而这个集群，一般由两个核心组件组成： • 一个Master节点（主节点） • 一群Node节点（计算节点）

Master主节点主要负责集群管理和控制Node节点，Node节点是物理机或虚拟机的主机节点，每一个Node节点提供Pod运行的必要服务，由Master主节点统一管理。

其中Master主节点提供了4个组件，具体功能以下：

• apiserver：资源操做惟一入口，符合Restful规范。
• controller-manager：全部资源的自动化管理控制中心，管理着一堆其余控制器。
• scheduler：负责Pods在各个Node节点上的分配和调度，并提供多种Pod调度策略（预选和优选策略）。
• etcd：共享配置和服务发现的分布式KV键值对存储集群，主要负责存储持久性状态。

除了这些，还有一个很重要的副本控制器（Replication Controller，RC）的概念。

设定RC为3，经过controller-manager监控到不可用（即Pod少于3）时，会自动复制建立一个新的Pod。

其中Node节点主要包含Pod（没错，上面可能听的很迷糊的那个pod）、kubelet、kube-proxy 、Docker和Fluentd等等。

这几个组件的具体功能介绍以下：

• Pod：K8S部署的最小对象，内含1~n个容器和存储卷，全部容器都是一个业务。重点：Pod是短暂的，不是持续性实体。
• kubelet：负责管理Pod的生命周期以及Pod的容器、镜像、卷等。以及同步Master主节点本机注册信息。
• kube-proxy：提供Pod之间的网络代理通信和负载均衡。
• Docker：容器应用引擎。
• Fluentd ：主要负责日志收集、存储与查询。

阅读到这里，也许你看完上文，对于K8S仍是迷迷糊糊，不要紧，很正常。

由于除了上述这些组件的介绍外，在K8S还有一些概念是必需要理解，这样才能更好深入理解整个系统。 命名空间（Namespace）：为K8S集群提供虚拟的隔离做用，同一个Pod的容器确定在一个命名空间里。 服务（Service）：Pod是短暂的，不是持续性实体。持久化容器数据是经过使用持久化的卷类型存在，一个服务后面都有不少对应的容器来提供支持，对外表现为一个单一访问域名。 标签（labels）：用来更好让你分类，是与一个资源关联的键值对，这个资源大到集群，小到Pod，皆可。 存储卷（Volume）：每一个 Pod 中声明的存储卷由 Pod 中的全部容器共享，同时，卷的生命周期和Pod一致，一个Volume只是一个目录，不过一个Pod支持多个Volume。

前面提到，Pod是短暂的、甚至能够说是游离的。那Pod重启后，IP地址可能改变，怎么前端容器正确可靠地指向后台容器呢？

答案是经过Service。

Service是K8S的基本操做单元，是真实应用服务或者称之为一组Pod的抽象。经过 Kube-Proxy 的 port 和服务 selector 决定服务请求传递给后端的容器，外部无需关注后端如何运行，只要知道服务单一访问域名便可。

下述GIF简略的演示了部分的Service通讯功能，其中LoadBalancer是一个特殊类型的Service，也就是外部负载均衡。有容器，有了K8S，因而咱们就有了更多的想象空间。

好比，DevOps持续交付、微服务架构甚至是混合云部署。本文暂且不提微服务和混合云的部署，下面来简单的讲讲DevOps是什么。

三、DevOps是什么？

近几年，这个词很火，特别是K8S和容器发展起来后，几乎个个企业都喊着向DevOps前进。

那么,DevOps究竟是什么呢？

其实咱们讲解容器的时候已经了解了一个持续集成和持续部署 (CI/CD)的概念，其实这就是一个实施DevOps的重要成果。最终以实现迅捷、高质量的服务交付为目标，为企业提高业务价值和响应能力。

简单来说，DevOps一词的来自于Development和Operations的组合，突出重视软件开发人员和运维人员的沟通合做，经过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。

在DevOps以前，企业开发软件通常采用瀑布流模式，看到瀑布两个词，你可能就对这种模式有个大概的了解了。从产品需求的提出，到最终的落地，它的开发模式是以下图流程。

即，上述任何一个阶段，都必须在前者所有完成才能进行下一步。并且，传统软件架构将系统分为多个模块，并不注重接口的契约化，瀑布流方式集成周期长暂且不说，集成一个模块出现问题那么其余团队也须要等待。

为了解决这个问题，早在09年，DevOps就因传统瀑布流开发模没法知足快速迭代交付的需求而诞生，持续集成（CI）和持续部署（CD）方式，即小步快跑模式。可是这种模式也是由于近几年容器和K8S等技术的成熟，才真正走进大小企业的殿堂。

因而，有了DevOps的开发模式变成了以下流程。

根据2018年度的DevOps报告数据代表，2014 年时，只有16%的调查参与者表示本身在 DevOps 团队。而在 2018，这个数字已经增加到 27%。同时“DevOps”一词的 Google Trends 以及 2019 年的预计增加假设。

全文《2018全球DevOps现状报告》关键点以下：

• SDO效能解锁竞争优点：提高盈利能力、生产力、市场份额、客户满意度，以及实现组织目标和使命的能力
• 如何实施云基础设施很关键：云提升了软件交付的效能。具有云计算全部核心特征的团队，其属于高效能组织的可能性要高出23倍
• 开源软件能够提升效能：高效能组织普遍应用开源软件的频率比其余组织要高1.75倍，而且在将来扩展开源软件使用范围的可能性是其余团队的1.5倍
• 精英效能团队几乎不采用职能外包：由于这会有损于效能 一般外包能够节省成本并提供灵活的人力资源池，然而低效能组织将测试或运维等职能所有外包的比例，至少是高效能组织的4倍
• 关键技术实践驱动高效能 ：这些实践包括监控与可观察性、持续测试、数据库变动管理，以及尽早在软件开发过程当中集成安全性
• 实现软件交付的高效能与行业无关：咱们发如今强监管行业和弱监管行业中，都存在着在软件交付方面实现了高效能的组织

最后，DevOps尽管有如此之多的优势，可是并非全部的企业都可以完美的去实践。

由于DevOps必定程度上，并不只仅是IT开发模式的改变，仍是企业公司组织的重构。而相比前者，后者更难。

2019年，DevOps是否会如预期中覆盖更广，为更多企业带来真正的效率开发，咱们拭目以待。

参考资料

10分钟看懂Docker和K8S——来源：小枣君

2018全球DevOps现状报告——来源：DevOps社区

Learn the Kubernetes Key Concepts in 10 Minutes——做者：Omer Dawelbeit

《云计算架构技术与实践》——做者：顾炯炯

七牛容器云文档

Docker中国文档

K8S中文社区文档