目录

前言

正文

一、传统虚拟技术面临的挑战

二、容器化的含义

三、容器化的优点

1. 可迁移性

2. 速度快

3. 可扩展性

4. 利用率

5. 故障隔离

6. 安全性

7. 易于管理

8. 便利性

四、容器化的缺点

1. 安全性

2. 编排和数据存储

3. 监控

五、容器化的发展趋势

六、云服务产品实例

总结

粉丝福利

---

前言

目前，容器化已经成为云计算领域最新的技术趋势，很多人认为，容器化可创建全新、可扩展的云原生应用程序，实现老旧系统的现代化改造。几乎所有的企业都在使用云环境（公有云或者私有云），大多时候采用虚拟机方案，但是传统的虚拟化技术面临一系列挑战。本文将针对容器化技术的发展现状和趋势展开讨论，最后以亚马逊非关系型云数据库 DynamoDB 为例介绍云原生应用程序服务实例。另外，亚马逊云科技提供了100余种产品免费套餐。其中，计算资源Amazon EC2首年12个月免费，750小时/月；存储资源 Amazon S3 首年12个月免费，5GB标准存储容量；数据库资源 Amazon RDS 首年12个月免费，750小时；Amazon Dynamo DB 25GB存储容量 永久免费。

正文

一、传统虚拟技术面临的挑战

在云原生的大趋势下，传统的虚拟技术已经无法满足最新服务架构和产品技术选型的需要，因此，基于容器化的虚拟机技术逐渐登上了历史舞台，并且在最近几年发展迅猛。

 

上图是传统虚拟机技术和容器技术一个简单对比情况。 除此之外，传统虚拟技术还面临着哪些挑战呢？ 接下来详细介绍一下。

1. 环境不一致，应用程序和软件包部署到虚拟环境，部署环境和开发调试环境不一致。

2. 对操作系统有依赖，部署的应用程序只能在兼容的操作系统上运行。

3. 隔离级别较低，无法提供高于操作系统级别的沙盒机制。

4. 计算粒度不同，无法部署多个复制的应用程序，应用程序层上的负载平衡只能在单台计算机中运行，不能在非操作系统层中运行。

5. 在生产环境中修补应用程序很麻烦，在群集级别系统上部署不是很灵活，而且难以跨多个区域进行管理。

容器化可以非常方便的解决这些痛点问题，容器化比虚拟化的效率更高，是虚拟化的自然演进结果。虚拟化有助于在单个服务器上分发多个操作系统，而容器化则更为灵活，也更精细。接下来具体看一下什么是容器化。

二、容器化的含义

本质上，容器化是操作系统虚拟化技术的一种形式，可以让用户在使用相同共享操作系统的隔离用户空间中运行应用程序。而且对于操作系统的类型也没有限制，包括常见的linux系统、windows系统、mac OS系统。应用程序容器是一个完全打包、可迁移的可执行环境。

应用程序容器具备如下特点：

1. 容器拥有应用程序运行所需的全部内容，包括二进制文件、依赖关系、库和配置文件，所有文件都包含在容器中。

2. 容器化应用程序是指将容器从主机操作系统中提取出来，限制其对基础资源的访问权限，类似于轻量级虚拟机。

3. 容器化应用程序可以在各种类型基础架构和操作系统上运行应用程序，例如裸机、云服务器或虚拟机中，而不依赖具体的运行环境。

另外，容器化还可以减少启动时的开销。容器化的应用程序共享一个操作系统内核，无须为每个应用程序设置单独的访客操作系统。因此，可以在同一台机器上部署多个容器服务，而彼此之间互不影响。

三、容器化的优点

容器化技术允许将应用程序以容器的形式交付给客户、部署并对外提供服务。容器化为软件开发人员和开发团队带来卓越的敏捷性、可迁移性以及优化成本等众多优点。

容器化的应用程序具备如下优点：

1. 可迁移性

应用程序容器包含一个自主的操作系统，因此它并不依赖于主机操作系统，可以随便跨平台迁移，从而也避免了由于运行环境不一致导致的功能异常问题。

2. 速度快

开发人员之所以将容器称为“轻量型”，因为它们共享主机操作系统内核，无须额外开销，可以进一步提高服务器效率，减少服务器和授权许可成本。它们不必引导操作系统，因此可以显著加快启动的速度。

3. 可扩展性

应用程序容器技术具有高度的可扩展性，从而轻松应对日益增长的工作负载，在容器环境下，开发人员可以随时增添功能、更新服务，不会影响到原始应用程序。

4. 利用率

多个容器化应用程序共享主机的操作系统内核，同时，容器的容量本来就比虚拟机小，启动时间很短，所以支持单个服务器运行多个容器，提高了服务器的效率，同时降低了服务器和授权许可成本。

5. 故障隔离

容器化后，应用程序相对孤立，因此可独立于其他应用程序运行。所以，一个容器出现故障并不会影响其他容器的运行。同时，开发团队能快速找出和更正故障容器内的技术问题，不会造成其他容器停机。

6. 安全性

以容器形式隔离应用程序可防止恶意代码影响其他容器化应用程序或主机系统。您还可以规定安全权限，自动拦截对试图入侵其他容器或限制通信的恶意组件的访问。应用程序隔离可帮助开发人员共享其他功能，而不会产生风险。

7. 易于管理

借助容器编排平台，容器化工作负载和服务的安装、管理和扩展流程均可实现自动化。容器编排可显著简化管理任务，例如推出新的应用程序版本、扩展容器化应用程序或提供监控、日志记录和调试功能。

8. 便利性

容器化允许开发人员可使用同一个环境进行开发和生产，而这之前是 Web 应用程序开发很难办到的，所以容器对于开发人员来说非常方便。

四、容器化的缺点

当然，容器化也不是完美的，它也有一定的局限性。比如在制定和启动容器战略之前就要完成大量的准备工作。虽然，容器化可提高应用程序的灵活性，但它们也带来了其他方面的复杂性。这些复杂性主要体验在安全性、编排、监控等方面。

1. 安全性

相比较传统虚拟机，容器潜在的安全风险更高。容器需要多种级别的安全措施，因为它们有多个层。因此，除了要保护注册表、Docker 后台驻留程序以及主机操作系统，还要保护容器化应用程序本身。

2. 编排和数据存储

使用虚拟化解决方案随附的单一编排程序应对虚拟机（例如，适用于 VMware 的 VMware 编排程序）。不过，如果是容器，就要从 Kubernetes、Mesos 或 Swarm 等编排工具中进行选择。虚拟机的数据存储非常简单，但是容器却异常复杂。对于持久型容器数据，在启动容器时需要映射对应的物理机存储目录，否则容器一旦重启，其中的数据可能会永远消失。

3. 监控

监控容器的性能和安全问题也不容忽视。目前，可以选择使用各种监控工具、外部监控服务以及分析技术。云环境异常复杂，因此需要重视监控安全问题。

尽管存在缺陷，但是容器化依然利大于弊。

五、容器化的发展趋势

目前，很多企业都在大规模使用容器，容器的使用范围也开始有所变化，逐渐从在线业务逐渐向 AI 大数据演进，对 GPU 等异构资源的管理和 AI 任务和作业管理的需求也越来越多。同时，开发人员在考虑如何通过云原生技术，以统一架构、统一技术堆栈支撑更多类型的工作负载，从而进一步降低企业服务的运维成本。

深度学习、AI任务，正是社区寻求云原生技术支撑的重要工作负载之一。针对 AI 计算类任务的特性，在 Kubernetes 核心 Scheduler Framework 的基础上进行了大量扩展和增强，提供了支持 Gang Scheduling、Capacity Scheduling、Binpack 等任务调度策略，提升集群的资源利用率。并与 K8s 社区积极合作，持续推动 K8s 调度器框架演进，保证了 K8s 调度器通过标准的 plugin 机制，可按需扩展出各种调度策略，来满足各种工作负载的调度需求。同时避免了类似其他 custom scheduler 对集群资源分配带来数据不一致的风险。除此之外，支持 GPU 共享调度和拓扑感知调度，NPU/FPGA 等定制芯片调度，提升 AI 任务的资源利用率。

随着容器化技术的普及，很多云服务产品也都开始支持容器化部署。几乎所有的项目中都会用到数据库，接下就以云数据库产品为例进行介绍。

六、云服务产品实例

非关系型数据库 MongoDB，大家一定非常熟悉，另外一个非常有名的非关系型数据库 DBAmazon DynamoDB 也有必要了解一下，两种数据库都支持容器化部署。DynamoDB 是亚马逊云一种全托管 NoSQL 数据库服务，提供快速而可预测的性能，能够实现无缝扩展。DynamoDB 可以免除操作和扩展分布式数据库的管理工作负担，因而无需担心硬件预置、设置和配置、复制、软件修补或集群扩展等问题。此外，DynamoDB 提供了加密静态，这可以消除在保护敏感数据时涉及的操作负担和复杂性。

如果使用 MongoDB 遇到了难以解决的问题，可以考虑尝一下 DynamoDB。关于 DynamoDB 的好处，这里举一个例子，有一位使用过 MongoDB 和 DynamoDB 的网友分享了自己的经验：“我以低效的方式使用了 MongoDB，我有140万条记录，占用8G磁盘，但转移到 DynamoDB 后，只占用300M存储空间。从中可以看到 DynamoDB 对比 MongoDB 存在明显的优势。

 

总结

综上所述，容器化作为一门热门的技术，已经被广泛使用，并且凭借自身优势还在迅速抢占市场。对技术小伙伴来说，了解和掌握容器化技术已经成为一个加分项。本文通过讨论传统虚拟化技术面临的挑战，引出容器化技术，并介绍了容器化的发展现状、优缺点和未来趋势，最后以亚马逊非关系型云数据库 DynamoDB 为例介绍了支持容器化的云服务产品。相信大家通过本文的介绍，已经对容器化的概念有了一定程度上的认识，如果想深入了解，不妨亲自动手试一试。

粉丝福利

亚马逊云科技专为开发者们打造了多种学习平台：

1. 入门资源中心：从0到1 轻松上手云服务，内容涵盖：成本管理，上手训练，开发资源。AWS入门_AWS入门使用教程_AWS云计算资源-AWS云服务

2. 架构中心：亚马逊云科技架构中心提供了云平台参考架构图表、经过审查的架构解决方案、Well-Architected 最佳实践、模式、图标等。AWS架构中心部署说明_AWS云架构白皮书-AWS云服务

3. 构建者库：了解亚马逊云科技如何构建和运营软件。Amazon Builders' Library*all&awsf.filter-content-type=*all&awsf.filter-content-level=*all&trk=835e6894-d909-4691-aee1-3831428c04bd&sc_channel=el

4. 用于在亚马逊云科技平台上开发和管理应用程序的工具包：aws工具下载_aws开发工具_资源下载-AWS云服务

【专属福利】

福利一：100余种产品免费套餐。其中，计算资源Amazon EC2首年12个月免费，750小时/月；存储资源 Amazon S3 首年12个月免费，5GB标准存储容量。

https://aws.amazon.com/cn/free/?nc2=h_ql_pr_ft&all-free-tier.sort-by=item.additionalFields.SortRank&all-free-tier.sort-order=asc&awsf.Free%20Tier%20Types=*all&awsf.Free%20Tier%20Categories=*all&trk=e0213267-9c8c-4534-bf9b-ecb1c06e4ac6&sc_channel=el

福利二：最新优惠大礼包，200$数据与分析抵扣券，200$机器学习抵扣券，200$微服务与应用开发抵扣券。最新优惠活动_云服务器促销 - 亚马逊云科技

福利三：解决方案CloudFormation一键部署模版库

云服务解决方案部署快速入门_云服务部署-AWS云服务

摘要：无论公有云还是私有云厂商，都认识到了将虚拟化的隔离性和容器的高效运维特性相结合，是云原生平台发展的必然趋势。

容器是如何解决隔离问题的

众所周知，容器技术的出现有两个关键原因：

1.  软件运行过程中的资源和环境的隔离。

2.  软件因为运行环境多样带来的打包和配置的复杂性。

而对于软件运行环境的隔离需求，从计算机出现之初就已经开始了，多任务分时操作系统和虚拟地址的引入，都是为了解决多个任务在同一主机上运行，并且让任务本身认为自己独占机器。当然这样的隔离是远远不够的，当今软件，根据不同的层级，可以将隔离技术分为以下三类：

1.  进程级别的隔离

2.  操作系统级别的隔离

3.  虚拟化级别的隔离

操作系统以进程作为程序运行过程的抽象，进程拥有独立的地址空间，进程的执行依靠操作系统的调度。但是进程共享了文件系统，函数库等资源，程序之间出现互相干扰的可能性很大。这个层级的隔离适合在相同主机上运行单个用户的不同程序，由用户自己保证程序之间的资源分配。

上世纪70年代出现了chroot，进行文件系统的隔离，21世纪初开始，随着计算硬件的性能提升，软件隔离的需求更加强烈，这时候开始出现如jail，cgroup，namespace等各种不同资源的隔离技术。我们将这些技术统一划分到操作系统的隔离技术，这类隔离技术可以实现软件在诸如硬件资源、文件系统、网络、进程号等方面的隔离，但是不同的应用依然是运行在相同的操作系统内核上，对于恶意的利用漏洞攻击的场景，这种隔离技术依然会捉襟见肘。但是这种级别的隔离带来的额外资源消耗较小，适合相同的组织内不同用户的应用在相同主机上运行。

虚拟化技术的出现，让相同的物理机上也能运行多个不同的操作系统。操作系统对硬件的接口，由虚拟机管理程序(VMM)负责模拟。运行在不同系统中的程序，内核也是隔离的。硬件资源则通过各种硬件辅助手段进行划分，虚拟机上的程序很难突破虚拟化层加上的资源限制。并且因为内核的隔离，资源的可见性也做到了很强的隔离性。即使是恶意的用户，也很难突破这层虚拟化的限制，已达到攻击物理机，或者相同主机上其他虚拟机的目的。

以上三种隔离是按照层级一步一步加强的，同时带来的理论损耗也是逐步递进的。虚拟化由于需要模拟各种设备，带来的资源损耗比其他两种隔离方式要大很多。

 

什么是“安全容器”

容器概念出来的时候，最初大家做隔离的思路，几乎都是操作系统级的隔离，也就是基于内核提供的namespace、cgroup、seccomp等机制，实现容器内的资源、文件、系统调用等限制和隔离。这种隔离方式更加高效，损耗更小。但是随着容器的大规模使用，尤其是各种容器编排系统，如k8s的深入使用，人们逐渐发现这样的隔离级别往往不能满足要求。在公有云场景下，相同主机如果需要运行不同租户的应用，因为这种隔离级别依然采用了共内核的机制，存在这广泛的攻击面，容器的隔离级别完全不能满足要求。所以最初的公有云上的容器服务，都是配合虚拟机的使用来完成的，首先是用户需要创建一批虚拟机作为运行容器的节点，形成一个私有的集群，然后才能在其上创建容器应用。虚拟化级别的隔离已经被各种公有云的实践证明，是一种安全的隔离技术。

自从云计算的概念提出开始，虚拟机一直是云平台的基础，无论是平台本身服务还是用户的使用，都是从IaaS平台创建通用虚拟机开始的。一般都是创建相应的规格的虚拟机，使用一个完成操作系统镜像启动一个完整的操作系统，随后在其安装，配置，运行软件和服务。包括我们上节提到的公有云容器服务的提供形式也是如此。

虚拟化本身带来的隔离能力是受到普遍认可的，不过IaaS层希望提供的是一个和应用完全无关的基础设施层，它几乎完全不感知应用的任何信息。于是从基础设施到应用运维，中间巨大的鸿沟则是由PaaS和用户自己来填平，这中间依然需要耗费无数的人力和成本。通用的虚拟机服务诚然有它的好处，比如完整的操作系统很适合程序调试，或者作为工作办公环境等等。但是对于多数运行于云平台的软件，它需要的是它独有的运行环境，它的运行环境由它的镜像已经完全定义好了。如果在此之外，又启动一个完整的操作系统，既浪费资源，也增加了运维的成本。为什么不能直接将虚拟化级别的隔离引入到容器技术中呢？结合虚拟化的安全性和容器在软件生命周期管理方面的优势，是不是可以给软件开发运维带来巨大的便利呢？

也就是在这个时间，docker和coreos等一起成立了OCI组织，其目的是将容器的运行时和镜像管理等流程标准化。OCI标准定义了一套容器运行时的命令行接口和文件规范，docker将其RunC捐给OCI作为运行时标准的一个参考实现。2015年Hyper.sh开源了RunV，则是一种基于虚拟化的容器运行时接口的实现，它很好地结合了虚拟化的安全性和容器的便利性。后来RunV和ClearContainer合并成立了kata项目，kata提供了更加完整的基于虚拟化的容器实现。我们把这种基于虚拟化的容器实现称作安全容器。

除kata之外，还相继出现了多个安全容器的实现方式，比如google的gVisor、AWS的firecracker-containerd、IBM的Nabla、VMware的CRX等等，其原理不尽相同，但共同反应了一个趋势，就是将容器的便利和虚拟化的安全隔离结合起来，让虚拟化直接和应用运维结合，成为云原生技术的大势所趋。下面对这些“安全容器”的实现技术进行简要的介绍和对比。

Google gVisor

相比于其他几种实现，gVisor的显著不同之处在于，它通过拦截容器中应用的系统调用，模拟了一个操作系统内核，因此gVisor实际上没有虚拟化，而是在用户态实现了一个操作系统。这种方式可以降低因为虚拟化带来的模拟设备内存损耗。gVisor提供的runsc符合OCI标准，可以直接对接docker、containerd等容器平台，同时它也完全兼容docker的镜像格式。但是由于不是一个标准linux内核，因为应用的兼容性有较大问题。另外拦截系统调用带来的巨大的性能损耗也是阻止其广泛使用的一个阻碍。

 

图片来自https://gvisor.dev/docs/

 

IBM nabla

nabla是继承于unikernel的隔离方式，应用采用rumprun打包成一个unikernel镜像，直接运行在一个专为运行unikernel定制虚拟机(ukvm)中。应用直接打包首先可以降低很多内核态和用户态转换的开销，另外通过ukvm暴露非常有限的主机上的syscall(只剩7个)，可以大大缩小主机的攻击面。它是这些安全容器实现中，最安全的。不过由于它要求应用打包成unikernel镜像，因此和当前docker的镜像标准是不兼容的。另外，unikernel应用在诸如支持创建子进程等一些常规操作上都有很难解决的问题。

 

图片来自https://unit42.paloaltonetworks.com/making-containers-more-isolated-an-overview-of-sandboxed-container-technologies/

 

 AWS Firecracker

最初firecracker是为AWS的Lambda打造的高密度轻量级虚拟化组件。由于它是从头开始构建虚拟化，带着轻量化的目的，因此他抛掉了qemu这种通用虚拟化组件的大部分功能，只留下运行容器和Function必要的一些模拟设备。因此它的内存开销非常小（小于5M），启动速度非常快（小于125ms），一秒钟可以在一个节点上运行150个轻量级虚拟机。

为了让firecracker-microvm更好的运行容器，AWS启动了firecracker-containerd项目，firecracker-containerd是containerd-shim-v2的一个实现，不符合OCI标准，但是可以直接对接containerd启动容器，也就很容易通过containerd对接k8s的CRI接口。containerd-shim-v2是containerd定义的新的runtime接口，它是对最初shim-v1的一个简化，可以大大精简runtime的组件和内存使用。containerd是一个全插件化的代码框架，扩展性非常好。firecracker-containerd在该框架下，实现了一个snapshotter作为镜像插件，负责块设备镜像的生成；实现了一个shim-v2的runtime，负责容器的生命周期管理。另外还有个fc-control-plugin作为虚拟机的管理插件，提供grpc接口供runtime调用。在轻量级虚拟机内部，有一个agent负责监听runtime传进来的vsock，接收runtime的指令进行虚机内部真正的容器生命周期管理操作，它是直接调用runc来管理容器的。

 

图片来自https://github.com/firecracker-microvm/firecracker-containerd/blob/master/docs/architecture.md

 

VMware CRX

VMware发布的vSphere 7与kubernetes进行了融合，它利用k8s的CRD将其集群的虚拟机、容器、函数等运行实体管理的所有功能都集成到了k8s中。VMware是一个做虚拟化起家的公司，因此虚拟化作为它的老本行，这块的积累是很深厚的。它将虚拟化融合到它的容器runtime CRX中，因此和firecracker-containerd和kata类似，也是一个基于轻量级虚拟化的容器runtime的实现。通过对其虚拟化组件和guest内核的精简，CRX 容器同样做到了很低的内存损耗(20MB)、快速(100ms)的启动以及高密度部署(单个节点大于1000个pod)。

 

图片来自https://cormachogan.com/2019/11/22/project-pacific-vmworld-2019-deep-dive-updates/

vSphere对node上的kubelet组件改造比较大，节点上的Spherelet部分功能和kubelet重合，负责pod的生命周期管理（他们称之为Native Pod），运行在虚拟机中的SphereletAgent则集成了符合OCI接口规范的libcontainer，实现容器的生命周期管理，以及容器的监控日志采集、容器的shell登录(kubectl exec)。Spherelet和虚机中的SphereletAgent交互实现类似于kubelet使用CRI接口管理pod的效果。

 

kata containers

相比于以上几种，kata containers 最大的特点是它专注于实现一个开放的符合OCI标准的安全容器runtime实现，对于对接什么样的虚拟化方案，它抽象了一套hypervisor接口，如今已经对接了多种虚拟化实现，比如qemu、nemu、firecracker、cloud-hypervisor等等。

 

图片来自https://katacontainers.io/

 

通过containerd-shim-v2和vsock技术，kata精简了大量的组件，配合轻量级hypervisor和精简内核，kata可以做到将额外内存消耗降低到10MB以下。容器启动时间降低到100ms以下。后续还会通过rust语言重写等方式，提供更低内存额外消耗。

图片来自https://github.com/kata-containers/documentation/blob/master/design/architecture.md

 现有安全容器技术对比

	实现方式	安全隔离	性能/轻量化	兼容性
Google gVisor	用户态内核	拦截系统调用	IO、网络性能差	OS兼容性差
IBM nabla	Unikernel	裁剪系统调用+虚拟化	暂无数据	和现有镜像不兼容
AWS Firecracker	轻量级虚拟化	虚拟化	高	仅对接firecracker-microvm虚拟化
VMware CRX	轻量级虚拟化	虚拟化	高	仅对接VMware的ESXi
kata-containers	轻量级虚拟化	虚拟化	高	适配多种轻量级虚拟化技术

 

安全容器技术发展趋势

随着Serverless等技术的兴起，应用部署和运维工作已经下沉到云平台上，人们需要一个更加高效的云原生技术平台。从这几年涌现的安全容器实现技术可以观察到，无论公有云还是私有云厂商，都认识到了将虚拟化的隔离性和容器的高效运维特性相结合，是云原生平台发展的必然趋势。结合当前安全容器实现中遇到的一些问题，我们可以预见到，未来这项技术发展的几个走向：

1. 需要一个为安全容器而生的轻量级hypervisor，当前qemu+kvm是主流的虚拟化技术，但因为qemu是为通用的虚拟机而设计的，其体量过于庞大，而对于安全容器而言，一个模块化可定制的虚拟化实现尤为重要。如果结合gVisor和nabla的实现来看，内核的可定制性也是安全容器场景的必然要求。rust-vmm即是这样一种模块化的虚拟化组件库。linux内核本身的模块化特性可以部分满足容器场景下的内核定制需求，不过也许像gVisor那样实现一个专为容器而生的内核也许是未来的趋势。

2. 容器的启动时间是衡量一个云原生平台效率的重要指标，尤其是在Serverless场景下，程序运行时间本身可能很短，这时候启动时间可能占用了其绝大部分，那么这种低效就显得尤为明显。安全容器通过极致的轻量化，可以将容器启动时间降低到100ms以下，但是容器镜像拉取时间过长仍是当前容器部署过程中的一个短板。由于当前容器镜像格式和镜像挂载方式等方面的限制，需要在启动容器之前将容器镜像拉取到本地以后，才能启动容器。而容器启动本身需要的数据只占镜像的6%左右。因此我们亟需一个高效的镜像挂载方式，当前已经有一些免下载和懒加载（Lazy-Loading）的技术原型，后续需要尽快推出一个可商用的镜像下载加速方案。

3. 当前公有云的网络普遍采用原IaaS的网络管理模式，在地址分配，网络配置效率等方面完全赶不上容器快速启停的需求，docker容器采用的veth方式在性能等方面也很难满足高效转发的要求。因此需要一个专为云原生设计的网络管理方案。

4. 我们看到云平台对应用的管理逐步深入，从只管理基础设施的IaaS层，发展到管理应用整体部署和运维的PaaS，再到如今服务网格（Service Mesh）技术将平台管理能力深入到应用内部的微服务级别。同时我们也看到，以K8s容器、Istio服务网格为代表的云原生技术已经和下层的计算/网络虚拟化等技术逐步整合到了一起，比如安全容器即是容器与计算虚拟化的结合，而Istio服务网格也会与虚拟化网络进行深度整合以提供更高的性能与更精细的QoS控制。

5. 当前硬件加速技术在AI和大数据等领域大行其道，安全容器需要与各种计算加速硬件技术进行结合，使得AI、大数据、科学计算等批量计算领域的用户可以利用云平台直接投递其海量的计算任务，可大大降低他们在底层技术上的心智负担。通过硬件加速也是提升云平台本身效率、降低云平台运行成本的有效手段。比如华为云擎天架构在硬件加速方面拥有的技术优势在“安全容器”领域已得到充分的证明，CCE Turbo裸金属容器已经实现了安全容器的部分硬件卸载能力。

总结

未来必然是云原生技术大行其道的时代，我们已经看到很多传统行业也逐渐认识到云原生技术可以给传统企业的IT软件，工业自动化，线上运维和数据管理等带来明显的效率提升。我们将看到通过对底层硬件和上层服务的全栈整合，打造出一个高效智能的云计算技术平台，而这中间，容器将是串联整个技术栈的关键所在。

 

点击这里，了解更多精彩内容

背景

近几年，云原生和容器技术非常火爆，且日趋成熟，众多企业慢慢开始容器化建设，并在云原生技术方向上不断的探索和实践。基于这个大的趋势， 2020 年底 Qunar 也向云原生迈出了第一步——容器化。

云原生是一系列可以为业务赋能的技术架构准则，遵循它可以使应用具有扩展性、伸缩性、移植性、韧性等特点。云原生也是下一代技术栈的必选项，它可以让业务更敏捷。通过实践 DevOps、微服务、容器化、可观测性、反脆弱性(chaos engineering)、ServiceMesh、Serverless 等云原生技术栈，我们便可以享受到云原生带来的技术红利。

Qunar 容器化发展时间线

一项新技术要在企业内部落地从来都不是一蹴而就的，Qunar 的容器化落地也同样如此。Qunar 的容器后落地主要经历了 4 个时间节点:

• 2014 - 2015:

  业务线同学开始尝试通过 Docker、Docker-Compose 来解决联调环境搭建困难的问题，不过由于 Docker-Compose 的编排能力有限、无法解决真实的环境问题，因此容器化最后也没有推行起来。

• 2015 - 2017:

  ops 团队把为了提高 ELK 集群的运维效率，把 ES 集群迁移到了 Mesos 平台上。后来随着 K8s 生态的成熟，把 ES 集群从 Mesos 迁移到了 K8s 平台，运维效率得到了进一步的提升。

• 2018 - 2019:

  在业务需求不断增加的过程中，业务对测试环境的交付速度和质量有了更高的要求，为了解决 MySQL 的交付效率问题( 并发量大时，网络 IO 成为了瓶颈，导致单个实例交付时长在分钟级)，为了解这个问题，我们把 MySQL 容器化，通过 Docker on host 的模式可以在 10 秒之内就可以交付一个 MySQL 实例。

• 2020 - 2021:

  云原生技术已经非常成熟了，Qunar 也决定通过拥抱云原生来为业务增加势能。在各个团队齐心协力的努力下，300+ 的 P1、P2 应用已经完成了容器化，并且计划在 2021 年年底全部业务应用实现容器化。

落地过程与实践

容器化整体方案介绍

Qunar 在做容器化过程中，各个系统 Portal 平台、中间件、ops 基础设施、监控等都做了相应的适配改造，改造后的架构矩阵如下图所示。

• Portal：Qunar 的 PaaS 平台入口，提供 CI/CD 能力、资源管理、自助运维、应用画像、应用授权(db 授权、支付授权、应用间授权)等功能。

• 运维工具：提供应用的可观测性工具, 包括 watcher（监控和报警）、bistoury （Java 应用在线 Debug）、qtrace（tracing 系统）、loki/elk（提供实时日志/离线日志查看）。

• 中间件：应用用到的所有中间件，mq、配置中心、分布式调度系统 qschedule、dubbo 、mysql sdk 等。

• 虚拟化集群：底层的 K8s 和 OpenStack 集群。

• Noah：测试环境管理平台，支持应用 KVM/容器混合部署。

CI/CD 流程改造

CI/CD 改造前

CI/CD 改造后

主要改造点:

1. 应用画像: 把应用相关的运行时配置、白名单配置、发布参数等收敛到一起，为容器发布提供统一的声明式配置。

2. 授权系统: 应用所有的授权操作都通过一个入口进行，并实现自动化的授权。

3. K8s 多集群方案: 通过调研对比，KubeSphere 对运维优化、压测评估后也满足我们对性能的要求，最终我们选取了 KubeSphere 作为多集群方案。

中间件适配改造

改造关注点：由于容器化后，IP 经常变化是常态，所以各个公共组件和中间件要适配和接受这种变化。

应用平滑迁移方案设计

为了帮助业务快速平滑地迁移到容器，我们制定了一些规范和自动化测试验证等操作来实现这个目标。

1. 容器化的前置条件: 应用无状态、不存在 post_offline hook（服务下线后执行的脚本）、check_url 中不存在预热操作。

2. 测试环境验证: 自动升级 SDK、自动迁移。我们会在编译阶段帮助业务自动升级和更改 pom 文件来完成 SDK 的升级，并在测试环境部署和验证，如果升级失败会通知用户并提示。

3. 线上验证: 第一步线上发布，但不接线上流量，然后通过自动化测试验证，验证通过后接入线上流量。

4. 线上 KVM 与容器混部署：保险起见，线上的容器和 KVM 会同时在线一段时间，等验证期过后再逐步下线 KVM。

5. 线上全量发布: 确认服务没问题后，下线 KVM。

6. 观察: 观察一段时间，如果没有问题则回收 KVM。

容器化落地过程中碰到的问题

如何兼容过去 KVM 的使用方式，并支持 preStart、preOnline hook 自定义脚本？

KVM 场景中 hook 脚本使用场景介绍：

• preStart hook : 用户在这个脚本中会自定义命令，比如环境准备。

• preOnline hook：用户会定义一些数据预热操作等，这个动作需要在应用 checkurl 通过并且接入流量前执行。

问题点：

K8s 原生只提供了 preStop、postStart 2 种 hook, 它们的执行时机没有满足上述 2 个 KVM 场景下业务用到的 hook。

分析与解决过程:

1. preStart hook：在 entrypoint 中注入 preStart hook 阶段，容器启动过程中发现有自定义的 preStart 脚本则执行该脚本，至于这个脚本的位置目前规范是定义在代码指定目录下。

2. preOnline hook：由于 preOnline 脚本执行时机是在应用 checkurl 通过后，而应用容器是单进程，所以在应用容器中执行这个是行不通的。而 postStart hook 的设计就是异步的，与应用容器的启动也是解耦的， 所以我们初步的方案选择了 postStart hook 做这个事情。实施方案是 postStart hook 执行后会不断轮询应用的健康状态，如果健康检测 checkurl 通过了, 则执行 preOnline 脚本。脚本成功后则进行上线操作, 即在应用目录下创建 healthcheck.html 文件，OpenResty 和中间件发现这个文件后就会把流量接入到这个实例中。

按照上面的方案，Pod 的组成设计如下：

发布过程读不到标准输入输出

场景介绍：

在容器发布过程中如果应用启动失败，我们通过 K8s API 是拿不到实时的标准输入输出流，只能等到发布设置的超时阈值，这个过程中发布人员心里是很焦急的，因为不确定发生了什么。如下图所示，部署过程中应用的更新工作流中什么都看不到。

问题点:

K8s API 为什么拿不到标准输入输出？

分析与解决过程：

1. 通过 kubectl logs 查看当时的 Pod 日志，什么都没有拿到，超时时间过后才拿到。说明问题不在程序本身，而是在 K8s 的机制上；

2. 查看 postStart Hook 的相关文档，有一段介绍提到了 postHook 如果执行时间长或者 hang 住，容器的状态也会 hang 住，不会进入 running 状态, 看到这条信息，大概猜测到罪魁祸首就是这个 postStart hook 了。

基于上面的猜测，把 postStart hook 去掉后测试，应用容器的标准输入可以实时拿到了。

找到问题后，解决方法也就简单了，把 postStart hook 中实现的功能放到 Sidecar 中就可以解决。至于 Sidecar 如何在应用容器的目录中创建 healthcheck.html 文件，就需要用到共享卷了。新的方案设计如下：

使用上述方案后，发布流程的标准输入输出、自定义 hook 脚本的输出、Pod 事件等都是实时可见的了, 发布过程更透明了。

并发拉取镜像超时

场景介绍：

我们的应用是多机房多集群部署的，当一个应用的新版本发布时，由于应用的实例数较多，有 50+ 个并发从 harbor 拉取镜像时，其中一些任务收到了镜像拉取超时的报错信息，进而导致整个发布任务失败。超时时间是 kubelet 默认设置的 1 分钟。

分析与解决：

通过排查最终确认是 harbor 在并发拉取镜像时存在性能问题，我们采取的优化方案是通用的 p2p 方案，DragonFly + Harbor。

并发大时授权接口抗不住

场景介绍：

应用发布过程中调用授权接口失败，K8s 的自愈机制会不断重建容器并重新授权，并发量比较大，最终把授权服务拖垮。

我们的容器授权方案如下:

1. Pod init 容器启动时进行调研授权接口进行授权操作，包括 ACL 和 mysql 的白名单。

2. 容器销毁时会执行 Sidecar 容器的 preStop hook 中执行权限回收操作。

问题点:

ACL 授权接口涉及到了防火墙，QPS 比较低，大量容器进行 ACL 授权时把服务拖垮 。

分析与解决：

为了解决上述的问题，限量和降低授权接口调用次数是有效的解决方式。我们采取了下面几个措施:

1. init 容器中的重试次数限制为 1 次。

2. 授权接口按应用和 IP 限流， 超过 3 次则直接返回失败，不会再进行授权操作。

3. ACL 中涉及的一些通用的端口，我们统一做了白名单，应用无需再进行授权操作。

Java 应用在容器场景下如何支持远程 Debug

KVM 场景 Debug 介绍：

在开发 Java 应用的过程中，通过远程 Debug 可以快速排查定位问题，因此是开发人员必不可少的一个功能。Debug 具体流程: 开发人员在 Noah 环境管理平台的界面点击开启 Debug, Noah 会自动为该 Java 应用配置上 Debug 选项，-Xdebug -Xrunjdwp: transport=dt_socket, server=y, suspend=n, address=127.0.0.1:50005，并重启该 Java 应用，之后开发人员就可以在 IDE 中配置远程 Debug 并进入调试模式了。

容器场景的 Debug 方案：

测试环境的 Java 应用默认开启 Debug 模式，这样也避免了更改 Debug 重建 Pod 的过程，速度从 KVM 的分钟级到现在的秒级。当用户想开启 Debug 时，Noah 会调用 K8s exec 接口执行 socat 相关命令进行端口映射转发，让开发人员可以通过 socat 开的代理连接到 Java 应用的 Debug 端口。

问题点：

容器场景下在用户 Debug 过程中，当请求走到了设置的断点后，Debug 功能失效。

分析与解决过程：

1. 复现容器场景下 Debug，观察该 Pod 的各项指标，发现 Debug 功能失效的时候系统收到了一个 liveness probe failed，kill pod 的事件。根据这个事件可以判断出当时 liveness check 失败，应用容器才被 kill 的，应用容器重启代理进程也就随之消失了，Debug 也就失效了。

2. 关于 Debug 过程 checkurl 为什么失败的问题，得到的答案是 Debug 时当请求走到断点时，整个 JVM 是 hang 住的，这个时候任何请求过来也会被 hang 住，当然也包括 checkurl，于是我们也特地在 KVM 场景和容器场景分布做了测试，结果也确实是这样的。

3. 临时解决方案是把断点的阻断级别改为线程级的，这样就不会阻断 checkurl 了, idea 中默认的选项是 Suspend All，改为 Suspend Thread 即可。不过这个也不是最优解，因为这个需要用户手工配置阻断级别，有认知学习成本。

4. 回到最初的问题上，为什么容器场景下遇到这个问题，而 KVM 没有，主要是因为容器场景 K8s 提供了自愈能力，K8s 会定时执行 liveness check, 当失败次数达到指定的阈值时，K8s 会 kill 掉容器并重新拉起一个新的容器。

5. 那我们只好从 K8s 的 liveness 探针上着手了，探针默认支持 exec、tcp 、httpGet 3 种模式，当前使用的是 httpGet，这种方式只支持一个 url, 无法满足这个场景需求。经过组内讨论， 最后大家决定用这个表达式 (checkurl == 200) || (socat process && java process alive) 在作为应用的 liveness 检测方式，当 Debug 走到断点的时候, 应用容器就不会阻断了， 完美的解决了这个问题。

以上就是我们落地容器化过程中遇到的几个问题与我们的解决思路。其中很重要的一点是从 KVM 迁移到容器时需要考虑用户的使用习惯、历史功能兼容等要点，要做好兼容和取舍，只有这样容器化落地才会更顺畅。

未来展望

多集群稳定性治理

1. 让可观测性数据更全面、覆盖度更广，进而完善我们的 APM 系统，提升排查问题效率。

2. 通过实施混沌工程来验证、发现和消除容器化场景的稳定性盲区。

提高资源利用率

1. 根据业务指标实现弹性扩缩容。

2. 根据应用的历史数据智能的调整 requests。

ServiceMesh 方案落地

我们是基于 Istio 和 MOSN 以及当前的基础架构做的 mesh 方案，目前在测试阶段，这套方案落地后相信会让基础架构更敏捷。

作者

邹晟 去哪儿网基础平台技术专家