从生态的角度看容器和虚拟化的区别

「执笔人」品高股份 cloud native 资深架构师：继承

概述

容器技术和虚拟机技术都是近些年计算平台的主要的计算虚拟化技术，各家云厂商都提供虚拟机和容器服务，关于容器和虚拟化的区别，业界已经有很多共识了，例如：

• 容器镜像较小，仅为 MB 级别

• 容器启动速度为秒级

• 容器的资源消耗比虚拟机更小，单机可支持上千容器

• 容器可在不同操作系统、不同硬件平台移植

但是对于应用来说，更快、更小、可移植固然是非常吸引人的技术特性，但是将应用从虚拟化架构迁移到容器架构要付出相当的改造成本，容器架构究竟能为应用带来什么，是否要投入力量将已经部署在虚拟机中的业务改造迁移到容器架构上？

本篇文章将从两种技术路线的生态配套方面谈一谈两种技术的区别，从应用获取相关运维能力的角度，为应用的架构选型提供一种新的思路。

容器技术出现的非常早，但其标志性的发展始于 Docker 技术的出现，以及 Kubernetes 的蓬勃发展，所以本文谈论的容器技术指以 Docker 和 Kubernetes 两种技术为代表的容器技术。而虚拟化以各大云平台交付的虚拟机或云主机为代表。

应用的周边生态对比

容器加速 DevOps 的发展

DevOps 起源于 2009 年，由 Patrick Debois 发起的“DevOpsDays”会议中首次提出，旨在通过 IT 部门内部团队相互合作的方式，实现业务的快速交付、频繁变更和快速修复问题，以提高业务的敏捷性和稳定性。

通俗的讲，DevOps 中提到的快速交付和频繁变更的技术核心就在于 CI/CD 技术，Jenkins 就是 CI/CD 技术中最为传统、受众最广的一款持续集成工具。但是基于虚拟化的持续集成和持续交付，因为缺乏统一的应用构建和应用部署的标准，发展速度很慢，企业实践也比较困难，而容器技术的出现，让应用的构建和部署具有了一种标准，Docker 的集装箱形象非常鲜明，通过将应用程序和应用依赖的类库打包为统一格式的镜像，业界第一次有了这种一次构建、到处运行的应用标准。Docker 技术的出现，使得软件开发的标准化和自动化程度得到了大幅提升，让 Devops 实践成为可能。

业界涌现了很多为容器架构服务的 CICD 方案，例如 Jenkins X、Tekton、Argo CD 等，其中 Tekton 和 Argo CD 还是 Kubernetes 原生的解决方案，直接利用 Kubernetes 的调度机制，具有很强的灵活性和扩展性。

根据市场研究机构 Gartner 的数据，Devops 的市场规模从 2016 年的 23 亿美元增长到了 2020 年的 57 亿美元，到 2023 年，市场规模预计可以达到 98 亿美元，容器技术的出现，让 DevOps 获得了快速发展的机遇, 同时也为应用的发展反哺了更强的动力。

毫无疑问，容器架构相对虚拟化架构，实践 Devops 将会更加便利和高效。

监控告警的新旧对比

监控告警，是一个历史悠久的业务伴生问题，有应用部署的地方，就有监控告警方案的身影。我们以 Zabbix 和 Prometheus 作为虚拟机监控和容器监控的解决方案代表，来对比应用在两种部署形态下的监控方案落地优缺点。

1. 数据存储：Zabbix 使用关系型数据库存储数据，而 Prometheus 则使用时间序列数据库。关系型数据库具有灵活性，但是在存储大量时间序列数据时，性能可能会受到影响。时间序列数据库则专门用于存储时间序列数据，具有更高的性能。

2. 数据采集：Zabbix 和 Prometheus 都采用 pull 的方式收集数据，在网络受限的场景里面 Zabbix 支持代理方案，Prometheus 支持 PushGateway 的方式，相对来说 Zabbix 更为成熟。不过 Prometheus 主要用在容器场景，对容器的指标采集并不需要连接到容器的网络，只需要能够连通节点 kubelet 的网络即可。

3. 可视化：Zabbix 提供了较为完整的可视化界面，可以通过图表直观地展示数据；Prometheus 则需要通过 Grafana 等可视化工具进行数据展示，Grafana 的图表自定义和展示的能力，可以说是非常丰富和强大。

4. 插件和扩展性：Prometheus 具有更强的插件和扩展性，可以支持多种语言编写的插件；Zabbix 则需要通过自行编写脚本来扩展功能，两者都具备扩展的能力。

以上为两个方案的几个常见的对比项，本文主要从应用的角度来探讨两种方案的优缺点，那么更为关注的是获取的难度以及能力的丰富程度：

1. 获取的难度：在容器架构中，Prometheus 的部署有非常成熟的 Helm 以及 Operator 的方式，快速的初始化监控告警环境，而 Zabbix 的部署要相对困难，需要依赖一些自动化脚本的能力，以及类似 chef、puppet 等自动化编排工具。

2. 生态的丰富程度：两个方案都有相应的生态，Zabbix 具有丰富的监控模板可以复用，Prometheus 具有很多采集插件，但是 Prometheus 的生态更为活跃，可以集成具有丰富可视化面板的 Grafana，以及告警的 AlertManager 等组件。

综上所述，从获取难度和生态的角度来看，容器架构中获取到监控告警能力更为方便，各类生态组件也较为完善，一般容器云平台都会提供原生集成的监控告警方案，应用可以轻松的获取到应用级的性能监控指标，而虚拟化平台大多只能提供到虚拟机级别的性能指标，靠近应用层的监控，必须引入 APM（应用监控）的监控能力。

如何实现统一日志

统一日志是在微服务快速发展的背景下诞生的业务需求，随着微服务的数量增长，传统查看微服务日志的方式已经不能顺应时代的发展了，统一日志通过将系统内部所有应用程序、设备或服务产生的日志信息收集并存储到同一个地方，以便于管理和分析。统一日志采集的数据可能包含应用程序的事件、错误、性能指标、网络流量等等。通过收集和分析这些日志，可以帮助企业或组织发现问题、监测系统的运行状态、优化应用程序的性能，并提供安全审计和合规性的服务。

统一日志广为认知应该是从 ELK 的方案开始，2005 年 ELK Stack 发布，它包括 Elasticsearch、Logstash 和 Kibana 三个开源软件，提供了强大的解决方案，成为了日志管理领域的重要里程碑。但是 ELK 相对很笨重，社区先后发布了 Fluentd 和 Loki 这种轻量级的日志管理方案，2018 年 CNCF 社区发布了 OpenTelemetry，提供了更加强大的可观测性能力，覆盖了 Trace，Metrics 和 Log 。

以上这些日志方案均可以运行在容器架构和虚拟机架构中，但是和监控方案类似，部署这类日志方案的难度在容器架构和虚拟化架构上完全不同，虚拟化架构中除了部署日志采集插件以外，还需要根据日志位置配置采集文件，由于虚拟化应用的部署缺乏统一标准，这类配置工作非常繁琐，每上架一个新的微服务，都需要重新为该服务配置采集功能，相比之下由于容器可将日志写入标准输出中，对应用来说几乎是无感知的就可以获取到统一日志的能力。

应用编排技术

从监控告警和日志管理的功能对比中可以看出，容器技术和虚拟化技术有一个非常突出的区别：应用部署的难易程度。这个关键的区别点影响了应用在两种架构的部署管理成本，以及获取周边生态组件的管理成本。

前文提到过虚拟化架构中，对于应用组件的部署，需要借助一些自动化工具来完成，对于虚拟化的应用部署编排工具一般有三种层次：

1. 脚本自动化： 在规模较小的应用场景中，可以直接编写脚本完成自动化的部署，但是如果部署复杂度过高的话，脚本的编写和管理是一个灾难。

2. 传统编排工具： 业界关于虚拟化的编排有非常成熟的套件，例如 chef、puppet、ansible 等编排工具，通过编排文件声明、编排执行调度的方式，将应用的复杂编排组织成一键式的安装过程。但是这类编排工具仅限软件层面，无法对硬件进行编排，并且有些基于 ssh 或其他 push 的通信方式，严重依赖网络，在某些环境中会受限。

3. 云厂商的编排工具：各大云厂商都会提供资源编排工具，典型的例如 AWS 的 Cloudfomation 工具，品高云的自动化编排工具，可以实现硬件和软件的统一编排，并且云厂商会解决网络层面的问题，让指令和文件的下载畅通无阻，这一点是传统编排工具无法具备的。

在虚拟化长期的发展过程中，编排工具可谓百花齐放，但是并没有哪一家能够形成事实上的标准，各家应用的选型不一，所以这些编排工具的推广也比较缓慢。我们尝试对这个问题进行探讨，有几个原因阻碍了虚拟化编排标准的形成：

1. 构建不统一：应用程序打包的方式多种多样，Zip、Tar、War，如何打包完全由应用自行发挥。

2. 运行时不统一：不同中间件、不同编程语言，太多因素影响了虚拟化环境的应用运行时环境了，不同的环境具备不同的部署形态，以及不同的部署包。

3. 基础设施不统一：不同 CPU 架构、不同操作系统、不同云厂商提供的基础设施存在较多差异，其计算、存储、网络的获取方式、运行条件、安全策略都可能存在差异性。

4. 面向过程：构建和运行时的形态不一导致虚拟化的编排声明往往都是面向过程的，描述的是事件流，例如先创建机器，再下载文件，接着执行初始化脚本，其中掺杂着若干的条件判断，比如单机模式下如何安装，多机模式下如何安装，应用的管理员必须将这个部署过程转换为对应的规范，显然这个过程非常复杂，并且很难统一。

虚拟化应用部署由于缺乏统一的标准，导致应用的部署困难重重，发展缓慢，历史的经验告诉我们统一的标准对生产力发展的重要性，容器也是在这种背景下应运而生的。

容器技术诞生的很早了，但正真的腾飞要从 Docker 开始，Docker 通过制定了一种应用构建和运行标准，将构建不统一、运行时不统一、基础设施不统一三个问题都解决了，所有的应用都是一个集装箱，真正做到 “一次构建、处处运行”。

Docker 自 2013 年推出后，迅速占领容器市场，下图为 2015 年的一份容器市场份额报告，Docker 成为了容器市场的王者。

Docker 奠定了容器应用部署的基础，在容器编排的领域 Kubernetes 发展至今已经成为了事实上的赢家，在今天，大家谈论容器时，基本都在谈论 Kubernetes 了。关于 Kubernetes 的发展历史，本文不做赘述，其发展至今已经成为了容器架构下的操作系统，为应用屏蔽了底层的差异，Kubernetes 声明式的 API，让应用编排可以面向结果（最终期望状态）而不是面向过程，用户只需要声明应用的最终部署形态，其调度过程可以完全交由 Kubernetes 完成。

Kubernetes 通过 CRI、CNI、CSI 三大接口标准，基本囊括了计算、存储、网络的各家基础设施，通过对无状态、有状态、守护进程、定时任务等各种应用部署的声明提供丰富的应用部署形态，通过 CRD 和自定义控制器模式提供了扩展性，可以说在容器架构中 Kubernetes 已经是一个非常全面的应用部署编排方案了。

总结：在容器架构中，Kubernetes 提供的应用编排能力，已经远远超过了虚拟化架构，使得应用部署的便利性大幅度提升。

总结

相对虚拟化技术，容器技术因为具备了应用构建和运行的标准(Docker), 以及应用编排的标准（Kubernetes）, 应用在容器架构中的部署变得标准化，部署和管理成本相对虚拟化技术非常低，部署效率也更高。

得益于此，容器生态圈的诸多技术发展速度更快，DevOps、可观测性（监控、日志、追踪）、服务治理以及各类数据库中间件的发展为应用云原生化提供了诸多选型，应用获取这些能力的成本非常廉价。

容器技术助力了周边生态的发展，而生态的发展也进一步促进和滋长出更多的生态组件和项目，这也是云原生思想所体现的，应用生于斯，长于斯。