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

作者： Pasca

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

前言

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

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

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

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

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

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

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

1、容器是什么？

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

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

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

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

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

有数据表明，持续集成和持续部署 (CI/CD) 通过 Docker 加速应用管道自动化和应用部署，交付速度提高至少 13 倍。当然，这只是容器的一个优点，因为如果仅仅是这一个，虚拟机也能办到这个事情。打包成镜像然后移交到另外一台虚拟机，但是容器有一个虚拟机无法媲美的优点: 轻量。

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

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

2、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是什么。

3、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是否会如预期中覆盖更广，为更多企业带来真正的效率开发，我们拭目以待。