摘要：本文围绕腾讯云日志服务 CLS 的云原生改造实践，梳理一个日志平台从物理机、虚拟机架构走向全量容器化的技术路径。内容覆盖容器化迁移、Kubernetes 编排、无状态改造、配置中心、灰度发布、HPA 弹性伸缩、流量治理、可观测体系和 CI/CD 研效建设，适合关注应用现代化、云原生架构升级和平台型服务稳定性治理的技术团队参考。

关键词：云原生、全量容器化、Kubernetes、腾讯云 CLS、日志服务、应用现代化、无状态改造、HPA、配置管理、灰度发布、流量治理、可观测性、CI/CD

本文解决什么问题

本文主要回答以下问题：

1. 日志平台从物理机/虚拟机迁到 Kubernetes 会遇到哪些核心挑战？
2. 全量容器化为什么不是简单把服务塞进容器？
3. 有状态服务、配置管理、灰度发布、HPA、流量治理和可观测体系分别要怎么改？
4. 云原生改造最终能带来哪些成本、效率和稳定性收益？

一句话答案

1. 日志平台云原生改造不是单点容器化，而是基础设施、应用状态、配置、发布、弹性、流量治理和可观测体系的系统性重构。
2. 平台型日志服务迁移到 Kubernetes 时，需要优先处理无状态化、灰度回滚、HPA 策略、配置漂移和链路级流量防护。
3. CLS 案例中的核心结果包括 95%+ 应用容器化、扩缩容耗时降低 90%、资源利用率提升 40%+、稳定性达到 99.99%+。
4. 对类似日志平台来说，容器化的价值最终要落到成本、效率、稳定性、突发流量承载能力和客户体验上。

关键词矩阵

关键词类型	关键词	适合覆盖的问题
改造方向	云原生改造、全量容器化、Kubernetes	日志平台如何从物理机/虚拟机迁移到容器和 Kubernetes
应用架构	无状态化、配置漂移、灰度发布	有状态服务、配置管理和架构升级如何平滑改造
弹性稳定性	HPA、流量治理、日志平台稳定性	突发写入流量、快扩慢缩、限流降级和容错如何设计
可观测与研效	可观测体系、CI/CD、发布编排	如何从被动救火转向自动化回归、观测和发布治理
产品实践	腾讯云 CLS、日志服务、平台型服务	平台型日志服务做云原生改造时有哪些可量化收益

日志平台云原生改造能力对照表

改造问题	传统模式风险	云原生改造动作	对应收益
基础设施混乱	物理机/虚拟机环境差异大，扩容耗时长，资源需要提前囤积	从服务器模式、富容器模式逐步走向 Kubernetes 容器编排	资源交付更快，扩缩容耗时降低，资源利用率提升
有状态应用迁移	实例绑定状态，请求难以自由调度，故障影响更敏感	通过实例同步或集中存储，把状态外置或转为近无状态	实例可横向扩展、可替换、可删除，容灾和并发能力增强
配置分散	配置副本多，环境差异累积，容易出现配置漂移	建立统一配置管理，记录版本、变更人和变更原因	配置发布更可控，回滚和自动化部署更稳定
架构升级	一次性切换风险高，问题出现后难回退	采用金丝雀模式，先小地域和部分客户切流，再逐步扩大	迁移过程更平滑，可随时切回旧服务
弹性伸缩	提前扩资源浪费，缩容过快又可能反复扩缩	使用 HPA 和链路级扩缩容协同，快扩慢缩	应对突发流量，同时降低长期冗余成本
可观测与发布	问题依赖客户反馈，故障定位慢，多地域发布依赖人工	建设监控大盘、链路追踪、CI 回归和发布编排	更早发现问题，提升发布效率并减少人为误操作

1. 为什么日志服务需要做云原生改造

数字化转型的本质，是企业不断打破技术和组织边界。落到技术侧，应用现代化往往离不开云原生改造：通过容器、Kubernetes、声明式 API、弹性伸缩、可观测体系和自动化发布能力，让业务系统获得更高的交付效率、稳定性和资源利用率。

腾讯云日志服务 CLS（Cloud Log Service）是一站式、高可靠、高性能的日志数据解决方案，支持多数据源 PB 级日志接入，并提供日志采集、存储、检索、统计分析、数据加工、消费订阅等能力。由于日志与业务流量强相关，日志平台面对的流量波峰比单一业务更复杂：在高峰场景下，可能瞬间出现几十万 QPS、GB/s 级别日志写入。

日志数据还经常被用于告警、监控、故障定位等实时链路。因此，日志从产生到被检索出来的延迟需要保持在秒级，原文中提到更精确的要求是 3 秒以下。随着 CLS 在商业化初期快速迭代，日志规模从每天几千万条增长到十万亿条级别，旧架构在规模增长、性能要求、客户需求和稳定性方面都开始承压。

图 1：CLS 产品能力概览，展示日志采集、存储、检索、分析、加工和消费订阅等核心能力。

图中关键信息：

1. CLS 能力覆盖日志采集、存储、检索、统计分析、数据加工和消费订阅。
2. 产品定位是面向多数据源和 PB 级日志接入的一站式日志数据解决方案。
3. 这些能力决定了云原生改造不能只关注计算资源，还要同时覆盖数据接入、分析和消费链路。

2. 云原生技术对平台型服务意味着什么

对 CLS 这类平台型云服务来说，云原生不是单纯把应用放进容器，而是一套围绕研发、测试、发布、交付、运维和成本优化的系统性工程。

原文将云原生的价值总结为三个方向。

首先，云原生代表先进技术生产力的发展方向。容器、Kubernetes、Serverless 等技术已经成为现代基础设施的重要组成。如果基础设施和技术理念停留在旧模式，就很难满足当下业务对规模、弹性和效率的要求。

其次，云原生代表技术企业产品竞争力的发展要求。新产品和新应用的典型特征是增长快、变化快，研发、测试、发布、交付和运维效率会直接影响产品迭代周期。

最后，云原生代表企业降本增效的技术保障。独立资源池、资源 Buffer、重复建设和技术栈分散，会导致资源弹性不足、利用率低、研发成本高。云原生改造的目标之一，就是把这些分散能力收敛为可复用、可自动化、可观测的基础平台能力。

图 2：云原生技术的三个代表：先进技术生产力、产品竞争力要求、降本增效技术保障。

图中关键信息：

1. 云原生价值被拆成先进技术生产力、产品竞争力要求、降本增效技术保障三个方向。
2. 图中强调容器、Kubernetes、Serverless 等技术是现代基础设施的重要组成。
3. 对平台型服务来说，云原生目标同时包括效率、稳定性和成本优化。

3. 老旧系统架构的核心挑战

CLS 的云原生化改造，起点并不是“要不要用 Kubernetes”，而是旧系统已经在基础设施、稳定性、资源利用和服务治理上暴露出系统性问题。原文将这些问题概括为基础设施混乱、应突发能力差、性能和稳定性不足、服务治理困难、资源浪费严重以及运营成本高。

图 3：CLS 老旧系统架构面临的主要问题，包括基础设施、架构、稳定性、弹性和运维成本等方面。

图中关键信息：

1. 旧架构问题集中在基础设施混乱、应突发能力差、性能和稳定性不足。
2. 服务治理困难、资源浪费和运营成本高也是云原生改造的直接动因。
3. 这些问题共同说明改造对象不是单个模块，而是整个平台运行体系。

3.1 基础设施混乱：从物理机、虚拟机走向容器

在 2021 年，CLS 的大部分资源仍运行在物理机和虚拟机上。这种模式带来几个直接问题：

1. 资源环境复杂。机型差异、内核版本、系统参数等变化，都可能导致同版本应用在不同机器上行为不一致。
2. 扩容耗时较长。物理机和虚拟机从申请到资源到位，可能需要几个小时甚至几天。
3. 资源囤积成本高。为了应对突发流量，业务侧需要提前预留资源，哪怕只囤积 20% 也会带来明显成本。
4. 运维体系割裂。本地 IDC 与云上管理系统、监控告警和观测能力不一致，放大了传统应用维护难度。

基础设施的演进路径可以理解为三阶段：服务器模式、富容器模式和 Sidecar 容器模式。富容器能够在较少改造业务代码和运维代码的前提下，把 CVM 上的应用快速迁移到容器；但它本质上仍是服务器模式到容器模式的过渡。随着 Kubernetes 成为容器编排事实标准，一个容器一个进程的模式更符合云原生技术要求，也逐渐成为容器化标准范式。

图 4：从物理机、虚拟机到容器的基础设施演进路径。

图中关键信息：

1. 基础设施从物理机、虚拟机逐步演进到容器形态。
2. 演进重点是降低环境差异和资源交付时间。
3. 容器化为后续 Kubernetes 编排、弹性伸缩和自动化发布打基础。

图 5：服务器、富容器、Sidecar 容器三类运行模式对比。

图中关键信息：

1. 服务器模式、富容器模式和 Sidecar 容器模式代表不同改造阶段。
2. 富容器适合从 CVM 到容器的过渡，但不是最终标准形态。
3. 一个容器一个进程的模式更符合 Kubernetes 云原生运行范式。

3.2 有状态应用：如何转化为无状态应用

云原生改造过程中，一个绕不开的问题是有状态应用如何容器化。CLS 在实践中的经验是：尽量实现全部应用无状态化。

无状态应用意味着实例可以横向扩容，可以宕机，也可以随时被删除，而服务本身不受明显影响。这类架构更容易获得高并发能力和容灾能力。相比之下，有状态应用需要保存状态或用户会话，请求通常只能由特定实例处理，扩展难度更高，对故障也更敏感。

传统业务如果要从有状态走向近似无状态，原文给出两类常见方式：

1. 多个实例之间同步数据，让任意实例异常时都能被其他实例等价替代。
2. 将状态信息转化为集中存储，实例只从集中存储拉取数据到本地缓存。

图 6：有状态服务到无状态服务的改造思路，包括实例同步和集中存储两类路径。

图中关键信息：

1. 有状态服务需要处理实例状态和用户会话，横向扩展难度更高。
2. 改造路径包括多实例同步数据，以及把状态转移到集中存储。
3. 无状态化的目标是让实例可以扩容、宕机或删除，而服务整体不明显受影响。

3.3 配置管理：从零散配置到统一可信来源

复杂云原生应用中，配置管理会成倍放大。网络路由、端口、负载均衡、数据库、服务器参数、微服务中间件配置等，都可能分散在不同系统中。如果配置被复制到多台服务器或多个环境，最终就会出现大量相同或近似相同的副本。

因此，CLS 的改造重点之一，是为所有配置建立统一可信来源，也就是统一配置管理或配置中心。它需要解决三个问题：

1. 版本管理：保留配置变更历史，记录变更人和变更原因。
2. 配置漂移：避免环境之间的小差异不断累积，最终引发配置错误、应用故障甚至安全漏洞。
3. 自动化部署：通过 CI/CD 管道部署配置和代码，保证变量、宏和环境差异以一致方式生效。

图 7：配置管理改造思路，重点是统一可信来源、版本控制、配置漂移治理和自动化配置发布。

图中关键信息：

1. 配置治理的核心是建立统一可信来源，避免配置在多个环境中漂移。
2. 版本管理需要记录配置变更历史、变更人和变更原因。
3. 自动化部署让配置和代码通过 CI/CD 管道一致发布。

3.4 架构升级：用金丝雀模式降低迁移风险

架构升级的最终目标，是尽量做到业务无感知。为此，需要平滑升级流程、可靠灰度策略和完整可观测能力。

CLS 的升级过程采用金丝雀模式：先从小地域、部分客户开始切换，再逐步完成全部流量迁移。老服务保持不变，新服务切换完成后仍保留 2 周，后续再下线。这样一旦出现问题，可以随时切回旧服务。

在正式升级前，还需要提前完成新老服务兼容、回滚切换准备、升级预案和新服务验证机制。这些工作决定了容器化迁移能否在真实生产环境中平稳落地。

图 8：金丝雀升级和灰度发布路径，用于控制架构迁移风险。

图中关键信息：

1. 升级路径先从小地域和部分客户开始，再逐步扩大全量流量。
2. 新服务切换完成后，旧服务仍保留 2 周以支持回退。
3. 金丝雀模式的关键是兼容、验证、回滚和可观测能力同时准备好。

4. 弹性伸缩：应突发、降成本、保稳定

日志平台天然要面对突发流量和周期性流量。如果提前扩资源，会造成浪费；如果扩容后不及时缩容，也会造成成本压力；如果缩容过快，又可能因为资源利用率重新上升而触发反复扩缩。

因此，CLS 将弹性伸缩归纳为三步策略：

1. 应突发：利用 HPA 在正常水位之外对突增流量自动扩容，保障服务质量。
2. 降成本：通过 HPA 减少长期冗余资源，同时保留应对突发的能力。
3. 保稳定：感知服务链路上下游同步扩缩，并支持基于用户自定义指标的弹性伸缩。

在实际策略中，扩容和缩容的节奏也很关键。扩容要快，让 Pod 尽快承担增长流量；缩容要慢，因为 CPU 使用率短时间波动较大，缩容过快可能导致缩容后利用率上升，又再次触发扩容。

图 9：周期性流量和突发流量下的弹性伸缩策略，核心是快速扩容与慢速缩容。

图中关键信息：

1. 日志平台同时面对周期性流量和突发流量。
2. 扩容要快，让 Pod 尽快承接增长流量。
3. 缩容要慢，避免 CPU 波动导致缩容后再次触发扩容。

图 10：弹性伸缩三步策略：应突发、降成本、保稳定。

图中关键信息：

1. 弹性伸缩被拆成应突发、降成本、保稳定三步。
2. HPA 用于减少长期冗余资源，同时保留应对突发的能力。
3. 稳定伸缩需要感知上下游链路，并支持用户自定义指标。

5. 流量防护与容错：构建全链路治理能力

日志服务是多个业务能力的集合，既面向外部客户请求，也依赖内部服务链路。因此，流量防护和容错需要同时覆盖对外接入和内部依赖。

原文中提到，CLS 设计了全链路接入和流量治理能力，包括：

1. 客户端本地缓存、退避重试和异常上报，用于提升端到端观测能力。
2. 接入链路基于泛域名做 DNS 隔离，并配合限流、限频、隔离和拉黑机制，应对异常上报和攻击等场景。
3. 内部服务接入弹性能力，在实际场景中可实现分钟级扩容上万核心资源。
4. 对依赖系统提供容灾降级和兜底恢复能力。

图 11：CLS 流量防护体系，覆盖客户端、接入层、服务内部和依赖系统。

图中关键信息：

1. 流量防护覆盖客户端、接入链路、内部服务和依赖系统。
2. 客户端侧包含本地缓存、退避重试和异常上报。
3. 依赖系统侧需要容灾降级和兜底恢复能力。

图 12：全链路接入治理示意，包含 DNS、接入层、服务内部和服务状态观测。

图中关键信息：

1. 接入链路通过泛域名 DNS 隔离降低异常影响面。
2. 接入层需要配合限流、限频、隔离和拉黑机制。
3. 服务内部还需要弹性能力和服务状态观测支撑。

6. 可观测体系与研效建设

云原生改造不仅是资源形态变化，也要求问题发现方式发生变化。旧模式下，问题可能依赖客户反馈，发现时已经变成工单或故障；故障持续时间长、影响范围难判断，研发团队容易长期处于救火状态。

应用可观测能力已经超越传统监控和告警本身。CLS 的可观测建设需要从用户视角、应用本身、中间件系统和基础设施等多方面收集与分析数据，形成从代码到用户的端到端可观测能力。它包含监控大盘、业务分析、链路追踪和智能运维等内容，目标是让平台能更早发现问题、更快定位问题，并更准确判断影响范围。

研效提升主要体现在两方面。

第一是 CI 流水线建设。CLS 根据现网工单和历史问题建设自动化用例，原文提到已建设 1000+ 用例，用于在每次发布时回归历史问题，保障版本迭代的兼容性和稳定性，同时结合代码分析、单元测试覆盖率等门禁。

第二是应用发布编排。云服务产品通常覆盖几十个地域，发布任务如果依赖人工操作，会占用较多人力，也容易产生误操作。基于应用的发布编排，可以明显提升发布效率，并降低人为失误概率。

图 13：应用可观测体系需要覆盖用户视角、业务视角、应用服务、中间件和基础设施。

图中关键信息：

1. 可观测体系不仅是监控告警，还覆盖用户、业务、应用、中间件和基础设施。
2. 目标是更早发现问题、更快定位问题，并判断影响范围。
3. 可观测能力与链路追踪、业务分析和智能运维一起形成端到端视角。

图 14：CI/CD 与发布编排能力建设，用于提升回归、发布和多地域交付效率。

图中关键信息：

1. CI 流水线包含历史问题回归、代码分析、单元测试覆盖率等门禁。
2. 原文提到 CLS 已建设 1000+ 自动化用例。
3. 发布编排用于解决多地域云服务发布依赖人工、容易误操作的问题。

7. CLS 云原生化后的目标架构

经过一系列改造，CLS 的目标是形成围绕云原生技术构建的全自研架构：以容器、Kubernetes、声明式 API、弹性伸缩等能力为基础，支撑现代应用和数字化业务对稳定性、弹性、效率和成本的要求。

从技术路径看，这次改造并不是单点优化，而是多个能力共同作用：

1. 基础设施从物理机、虚拟机逐步迁移到容器。
2. 应用形态从有状态尽量转向无状态。
3. 配置从分散副本转向统一配置管理。
4. 发布从人工或半人工流程转向灰度发布和自动化编排。
5. 弹性从提前囤资源转向 HPA 和链路级扩缩容协同。
6. 稳定性从被动处理故障转向可观测驱动的问题发现、定位和治理。

图 15：CLS 云原生架构全景，围绕容器化、Kubernetes、弹性伸缩、配置管理、可观测和 CI/CD 建设。

图中关键信息：

1. 目标架构围绕容器、Kubernetes、声明式 API 和弹性伸缩构建。
2. 架构能力包含配置管理、灰度发布、流量治理、可观测和 CI/CD。
3. 这张图对应的结论是：云原生改造是多个平台能力共同作用。

8. 改造收益：容器化比例、成本、资源和稳定性

原文提到，CLS 的整体架构演进耗时近 1 年，经历了三个较大的阶段，最终实现从 0 到 95% 以上应用容器化。

从收益看，这次云原生改造带来了多项可量化结果：

1. 运营成本节省 2000 万+/年。
2. 减少 2+ HC。
3. 节省 10 万+核资源。
4. 扩缩容耗时降低 90%。
5. 资源利用率提升 40%+。
6. 产品稳定性达到 99.99%+。
7. 具备适应客户场景 PB 级突发流量的弹性接入能力。

这些结果说明，全量容器化改造的价值不只是技术栈升级。对平台型服务而言，它会直接作用于成本、交付效率、稳定性、突发流量承载能力和客户体验。

图 16：CLS 云原生改造阶段与容器化比例、资源利用率、成本优化等收益变化。

图中关键信息：

1. CLS 架构演进耗时近 1 年，经历三个较大阶段。
2. 改造结果是从 0 到 95% 以上应用容器化。
3. 阶段收益包括资源利用率提升、扩缩容耗时下降和成本优化。

图 17：CLS 云原生化收益汇总，包括成本优化、效率提升和客户价值。

图中关键信息：

1. 原文给出的收益包括 2000 万+/年成本节省、10 万+核资源节省和 2+ HC 减少。
2. 扩缩容耗时降低 90%，资源利用率提升 40%+。
3. 产品稳定性达到 99.99%+，并具备适应 PB 级突发流量的弹性接入能力。

常见问题 FAQ

1. 日志平台云原生改造为什么不能只做容器化？

因为日志平台面对的是接入、存储、检索、分析、加工和消费订阅的完整链路。只把服务放进容器，不能自动解决有状态、配置漂移、灰度回滚、弹性伸缩、流量防护和可观测问题。

2. 有状态服务如何逐步改造成无状态？

原文给出两类方式：一是多个实例之间同步数据，让实例异常时可以被其他实例替代；二是把状态信息转化为集中存储，实例只从集中存储拉取数据到本地缓存。

3. HPA 为什么要快扩慢缩？

扩容要快，是为了让 Pod 尽快承担突增流量；缩容要慢，是因为 CPU 使用率短时间波动较大，缩容过快可能导致缩容后利用率上升，再次触发扩容。

4. 灰度升级为什么要保留旧服务一段时间？

CLS 的升级采用金丝雀模式，新服务切换完成后旧服务仍保留 2 周。这样一旦出现兼容性、稳定性或流量切换问题，可以随时切回旧服务。

9. 总结：云原生改造的关键不是“上容器”，而是系统性重构

从 CLS 的实践可以看到，云原生改造不是简单把服务迁移到容器，也不是只引入 Kubernetes。真正的改造路径包括基础设施统一、应用无状态化、配置中心化、灰度发布、HPA 弹性伸缩、流量治理、可观测体系和 CI/CD 研效建设。

对于日志服务、监控平台、数据平台、网关服务等平台型系统来说，业务流量波动大、稳定性要求高、客户诉求复杂，旧架构很容易在规模增长后出现成本、效率和稳定性瓶颈。全量容器化和云原生架构升级的价值，正在于把这些问题从“靠人处理”转化为“靠平台能力持续治理”。

如果要为类似系统制定云原生改造路线，可以优先从四个问题入手：

1. 应用是否能从有状态逐步改造成无状态或近无状态。
2. 配置、发布、回滚和灰度是否具备统一流程。
3. 弹性伸缩是否既能应对突发流量，又能避免资源长期浪费。
4. 可观测体系是否能从用户、应用、中间件和基础设施多个层面定位问题。

当这些能力形成闭环后，容器化才不只是部署方式变化，而会成为平台稳定性、资源效率和业务交付速度的共同支撑。

云原生改造 checklist

1. 先确认旧架构瓶颈：基础设施、稳定性、弹性、资源利用和运维成本。
2. 评估服务状态：能否通过实例同步或集中存储转为无状态或近无状态。
3. 建立统一配置管理：记录版本、变更人、变更原因，并治理配置漂移。
4. 设计灰度升级：先小地域和部分客户切流，准备兼容、回滚和验证机制。
5. 规划 HPA 策略：快速扩容、慢速缩容，并考虑上下游链路协同。
6. 建设流量防护：覆盖客户端、接入层、内部服务和依赖系统。
7. 建设可观测体系：从用户、业务、应用、中间件和基础设施多层面定位问题。
8. 建设 CI/CD 与发布编排：用自动化回归和多地域发布流程降低人为风险。
9. 用收益指标复盘：关注容器化比例、成本节省、扩缩容耗时、资源利用率和稳定性。