Day33-06｜14.3.1 容器技术：云原生应用的标准化交付与运行基础

一、教材定位与学习目标

14.3.1“容器技术”是云原生相关技术中最常见、也最容易被简单化理解的一节。容器并不是轻量级虚拟机，也不是把应用打包后就自动获得高可用。它通过操作系统级隔离和标准化镜像，把应用及其运行依赖封装为可复制的运行单元，再由运行时和编排平台负责调度、网络、存储、健康检查和生命周期管理。

高级系统架构设计师考试可能从多个角度考查容器：比较容器和虚拟机；分析镜像、容器、仓库和运行时的关系；设计容器化应用的网络和持久化；说明资源限制与弹性；识别镜像供应链、特权容器和本地状态等风险。本篇将这些内容串成一条完整链路。

二、容器解决了什么问题

传统应用经常遇到“在开发环境可以运行，换到测试或生产就出问题”的现象，原因包括操作系统版本、运行库、环境变量、文件路径和依赖组件不同。容器通过镜像把应用及其用户态依赖封装起来，使构建产物在不同环境中具有更一致的运行基础。

容器还解决了交付单元过大的问题。虚拟机通常包含完整操作系统，启动和复制开销较大；容器共享宿主机内核，只封装用户态文件和应用进程，启动速度快，便于快速扩展和替换。配合镜像仓库与编排平台，团队可以使用相同镜像在开发、测试、灰度和生产环境中部署。

但容器的价值有边界：它不能自动修复错误代码，不能替代数据库备份，不能保证跨服务事务，也不能解决架构中的单点和容量瓶颈。容器只是云原生运行基础，必须与自动化、弹性、治理和可观测能力结合。

三、容器、虚拟机和物理机的区别

虚拟机和容器并非互相排斥。云平台常在虚拟机中运行容器，虚拟机提供基础隔离，容器提供应用交付和调度效率。架构师应根据安全隔离、操作系统需求、性能、运维能力和合规要求进行组合。

四、容器技术的基本组成

4.1 镜像

镜像是只读的应用运行模板，通常由多个分层组成。每一层代表一组文件变更，多个镜像可以共享基础层，从而减少存储和传输。镜像应具有明确版本和摘要，生产环境不能只使用容易变化的浮动标签。

镜像构建要遵循最小化原则：使用精简基础镜像，删除编译缓存和无关工具，避免把密钥写进镜像，固定依赖版本，并以非特权用户运行。镜像内容应可追溯到源代码、依赖和构建流程。

4.2 容器

容器是镜像的运行实例，拥有自己的进程、文件视图、网络和资源限制。容器可以被启动、停止、替换和迁移。容器本地文件通常适合临时缓存和运行日志缓冲，不适合保存订单、用户上传文件和必须长期存在的业务状态。

4.3 仓库

镜像仓库保存、分发和管理镜像。仓库需要进行身份认证、访问授权、镜像签名、漏洞扫描、版本保留和删除策略。公共镜像不应未经验证直接用于生产；企业还应维护可信基础镜像和依赖来源清单。

4.4 运行时和编排平台

运行时负责拉取镜像、创建容器、设置隔离和启动进程。编排平台在更高层负责调度、服务发现、滚动升级、健康检查、扩缩、配置注入、密钥引用和故障恢复。两者职责不同，不能把编排平台等同于容器本身。

五、容器的隔离机制与资源治理

容器通常利用命名空间实现进程、网络、挂载点和用户视图隔离，利用控制组对 CPU、内存、进程数和块设备等资源进行限制。资源限制的目的不是让容器永远使用固定资源，而是防止一个工作负载无限消耗节点资源，并为调度和容量规划提供依据。

5.1 CPU 和内存

应为容器设置请求值和上限。请求值可用于调度和容量预留，上限用于限制最大消耗。内存超限可能导致进程被终止，应用需要正确处理退出和重启；CPU 限制可能造成延迟上升。参数不能只凭默认值，应通过压测、峰值流量和故障场景验证。

5.2 资源配额与优先级

集群和命名空间应设置总量配额，避免某个团队占满所有资源；关键服务可以设置优先级和抢占策略，但要防止低优先级任务长期饥饿。批处理、在线交易和监控组件的资源行为不同，最好按工作负载类型进行隔离。

5.3 健康检查

存活检查用于判断进程是否需要重启，就绪检查用于判断实例是否可以接收流量，启动检查用于保护启动较慢的应用。检查接口应轻量、可靠，不应在健康检查中执行昂贵查询或依赖所有外部服务。否则数据库短暂抖动可能导致全部实例同时被重启，形成更大故障。

六、容器网络设计

容器网络需要解决容器到容器、容器到服务、服务到外部系统以及跨节点通信。编排平台通常为服务提供稳定的访问入口，把变化的容器实例隐藏在服务发现之后。

6.1 服务发现与负载均衡

调用方不应依赖某个具体容器 IP，而应通过服务名或注册发现机制访问。服务发现需要处理实例注册、健康状态、注销和缓存失效。负载均衡要结合连接复用、会话状态和故障剔除，不能只实现简单轮询。

6.2 网络隔离

不同业务域、环境和租户之间应使用网络策略限制访问。默认允许所有容器互通会扩大攻击面，服务只应访问完成业务所需的端口和目标。管理面、数据面和外部入口应尽量隔离，跨边界访问通过网关或安全代理控制。

6.3 外部依赖

容器中的应用访问数据库、消息和第三方服务时，仍需设置超时、连接池和证书校验。网络策略不能代替业务鉴权，TLS 也不能代替最小权限。外部依赖异常时，应用要执行熔断、降级和补偿。

七、容器存储与有状态应用

容器生命周期短且可替换，容器文件系统一般随容器删除而消失。临时文件、缓存和运行时生成的非关键文件可以放在本地；持久化业务数据需要使用持久卷、数据库、对象存储或消息系统。

7.1 持久化设计原则

首先明确数据的所有权、保存周期、吞吐、延迟和恢复目标；再选择数据库、对象存储或分布式文件系统。持久卷解决的是容器访问持久化存储的问题，不等于自动获得高可用和备份。仍需考虑副本、快照、跨区域恢复、访问权限和容量增长。

7.2 有状态工作负载

数据库、消息队列和搜索引擎可以容器化，但其运维复杂度通常高于无状态应用。需要配置稳定身份、顺序启动、数据副本、故障切换、滚动升级和备份恢复。对于团队缺乏经验或业务关键的场景，优先使用成熟托管服务可能更稳妥。

八、容器化应用的生命周期

一个可运营的容器化应用通常经历以下过程：源代码提交、自动构建、单元与集成测试、镜像生成、漏洞扫描、签名和入库、部署到测试环境、灰度发布、运行监控、扩缩和最终替换。每一步都应记录版本、责任人、配置和结果。

容器应支持优雅关闭，在收到终止信号后停止接收新请求，完成或转移正在处理的工作，再释放连接和资源。对于异步任务，应保存进度或使用可重试消息，避免容器被替换时任务丢失。发布时还要考虑旧版本和新版本同时存在，接口和消息契约必须兼容。

九、镜像与运行时安全

9.1 镜像供应链

基础镜像和第三方依赖可能包含漏洞或恶意代码。应维护可信来源，锁定版本和摘要，进行软件成分分析、漏洞扫描、签名验证和补丁更新。构建过程要隔离凭证，构建产物需要可追溯。

9.2 最小权限

容器应尽量以非 root 用户运行，禁止不必要的特权和宿主机目录挂载，限制 Linux 能力和系统调用，使用只读根文件系统或临时可写目录。访问数据库、对象存储和管理 API 时使用专用身份，不共享全能密钥。

9.3 运行时防护

需要监控异常进程、网络连接、文件访问和资源突增；对敏感命名空间和管理接口实施访问控制；生产集群区分开发、测试和生产权限。安全事件发生后，要能够定位镜像版本、部署对象、访问主体和影响范围。

十、容器编排与发布策略

编排平台一般提供工作负载描述、服务发现、负载均衡、滚动更新和自动恢复。架构设计时要说明期望状态与实际状态之间的控制关系：用户声明需要多少副本、使用什么镜像和资源，平台持续观察并尽量把实际状态调整到期望状态。

发布可采用滚动、蓝绿、金丝雀和灰度方式。滚动发布要设置最大不可用实例数和最大新增实例数；蓝绿发布要考虑两套环境的数据库兼容；金丝雀发布要按流量比例和业务指标验证；灰度发布要有用户、地区或租户规则。回滚不只是换回旧镜像，还要考虑数据库变更、消息兼容和已产生的业务数据。

十一、案例分析：传统订单系统容器化

某订单系统部署在两台虚拟机上，应用、上传文件和临时会话都写在本地；发布需要手工停止进程，系统高峰时无法快速扩容。改造目标是缩短发布时间并支持弹性扩展。

合理方案不是直接把现有目录打成镜像，而是先识别状态：会话外置到集中式会话存储，上传文件转移到对象存储，订单和库存仍由受控数据库保存，临时缓存明确可重建；应用改造为可重复启动和优雅关闭，配置通过外部配置和密钥注入；镜像采用固定版本、非 root 用户和漏洞扫描；编排平台配置请求、上限、就绪检查和滚动发布；入口通过服务发现和负载均衡分发请求；指标、日志和追踪中加入版本和订单号。

数据库不一定与应用一起容器化。若团队没有成熟数据库运维能力，可优先使用云托管数据库，并设计备份、恢复和连接容量；若必须容器化，则要单独设计持久卷、副本、故障切换和升级策略。改造验证应包括峰值压测、实例故障、节点故障、发布回滚和存储恢复。

十二、课后练习

练习一：选择题

下列关于容器的说法正确的是（ ）。

A. 容器包含完整客户操作系统，因此一定比虚拟机隔离更强

B. 容器本地文件适合保存永久业务数据

C. 容器是标准化运行单元，持久化、高可用和安全仍需额外设计

D. 使用容器后不需要编排和监控

答案：C。 容器通常共享宿主机内核，本地文件随生命周期变化，编排、持久化、安全和监控都需要单独治理。

练习二：简答题

请说明镜像、容器、仓库和编排平台之间的关系。

参考答案： 镜像是包含应用及依赖的只读运行模板；容器是镜像的运行实例；仓库负责镜像存储、版本管理和分发；运行时负责创建和运行容器；编排平台在集群层面负责调度、服务发现、健康检查、扩缩、配置、发布和故障恢复。它们共同构成从构建、分发到运行治理的容器生命周期。

练习三：案例题

某团队把数据库和订单应用都放入容器，数据库容器重启后出现数据丢失。请分析原因并提出改进。

参考答案： 团队把容器生命周期误认为数据生命周期，数据库数据保存在临时容器文件系统中，且没有持久卷、备份和恢复验证。应将数据库数据存储在受控持久化存储中，设计副本、快照、备份、故障切换和恢复目标；如果团队缺乏有状态服务运维能力，优先采用成熟托管数据库。订单应用与数据库应分别治理，应用容器保持可替换，数据库升级要考虑版本兼容和数据迁移。改造后通过删除实例、节点故障和备份恢复演练验证数据可靠性。

十三、论文写作素材

在“论容器化改造及其架构治理”类论文中，可以围绕三个难点展开：一是通过镜像和流水线解决环境不一致与发布效率问题；二是通过无状态化、外部存储、服务发现和健康检查实现弹性运行；三是通过资源限制、网络策略、镜像扫描、密钥管理和可观测性控制新增风险。

论文必须区分应用容器化和有状态组件容器化。应用服务的容器化通常重点在交付和弹性；数据库、消息等组件则重点在持久化、备份、故障切换和升级。写出这种差异，能够体现架构师对运行边界的理解。

十四、今日复盘清单

• 我能否清楚解释容器与虚拟机的区别？
• 我能否说出镜像、容器、仓库、运行时和编排平台各自的职责？
• 我能否说明容器网络、资源限制和健康检查的设计要点？
• 我能否判断哪些数据不能保存在容器本地？
• 我能否从供应链、最小权限和运行时三个层面分析容器安全？
• 我能否写出容器化改造的验证方案？

本节的核心结论是：容器通过标准化镜像和轻量运行环境提高交付一致性与资源调度效率，但它不是高可用、持久化和安全的自动保证。完整的容器架构必须同时考虑镜像供应链、运行时隔离、网络、资源、存储、编排、发布、观测和故障恢复。