3.3 应用容器化改造

课程简介

在云原生时代，容器化已成为应用交付的标准。它通过“一次构建，到处运行”的特性，解决了环境一致性问题，极大提升了研发效率和资源利用率。本课程将系统讲解从传统应用向容器化架构演进的完整流程、技术难点及最佳实践，涵盖镜像构建、K8s 编排、存储挂载、网络发布及弹性伸缩等核心环节。

学习目标

通过本课程的学习，您将能够：

• ✓ 掌握改造流程：理解从业务调研、应用评估到最终上线的标准化步骤。
• ✓ 精通镜像制作：学会编写高效、安全的 Dockerfile（多阶段构建、层优化）。
• ✓ 落地 K8s 编排：熟练配置 Deployment、Service、ConfigMap、Secret 及健康检查探针。
• ✓ 解决存储难题：掌握 StatefulSet 配合 CBS/CFS 实现有状态应用的持久化。
• ✓ 实施高可用：运用 HPA（Pod 水平伸缩）与 CA（集群自动伸缩）应对流量波动。

---

第一部分：容器化改造流程与策略

本部分导读
并非所有应用都适合立刻容器化。我们需要一套科学的方法论来评估和规划。

一、改造六步法

1. 分析与解耦：识别应用组件依赖，拆分单体架构。
2. 镜像准备：选择基础镜像，安装运行时环境。
3. 配置管理：将配置文件、数据库连接串等外部化（ConfigMap/Secret）。
4. 构建与测试：编写 Dockerfile，构建镜像，进行单元测试。
5. K8s 编排：编写 YAML 文件，定义 Deployment、Service、Ingress。
6. 部署与运维：发布到 TKE 集群，配置监控日志，制定回滚方案。

二、业务调研与应用诊断

2.1 调研清单

• 技术架构：语言版本、依赖组件、操作系统要求。
• 状态管理：是否有本地 Session？（需改造为 Redis 集中存储）。
• 配置方式：硬编码还是配置文件？（需改造为环境变量注入）。
• 日志输出：写本地文件还是 stdout？（建议改为 stdout）。
• 资源需求：CPU/内存的日常与峰值用量。

2.2 什么样的应用适合容器化？（云原生特征）

• 无状态：实例可随时销毁重建，不丢失业务数据。
• 配置分离：配置通过环境变量或 ConfigMap 挂载。
• 快速启动：启动时间 < 5分钟（理想 < 1分钟）。
• 日志标准：日志输出到标准输出 (stdout/stderr)。
• 健康检查：提供 HTTP/TCP 探针接口。

三、改造策略：四象限法则

应用类型	特征	改造策略	优先级
无状态应用	Web 前端、API 服务	直接容器化 (Rehost)	⭐⭐⭐⭐ (首选)
自研/可控应用	源码在手，架构可调	重构后容器化 (Refactor)	⭐⭐⭐
有状态应用	数据库、中间件	谨慎容器化，推荐使用云服务 (PaaS)	⭐
遗留/套装软件	商业 ERP、老旧系统	维持现状或迁移至 CVM	❌ (不推荐)

---

第二部分：容器镜像最佳实践

本部分导读
镜像大小直接影响发布速度和存储成本。优秀的 Dockerfile 是容器化的第一步。

一、Dockerfile 优化技巧

1. 选择精简基础镜像：优先使用 Alpine 或 Distroless，体积小且安全漏洞少。
2. 串联 RUN 指令：将 apt-get update, install, clean 等命令合并为一条 RUN，减少镜像层数（Layer）。
3. 多阶段构建 (Multi-stage Build)：
   • 第一阶段（Builder）：安装编译器（如 Maven/Go），编译源码。
   • 第二阶段（Runner）：仅复制编译好的二进制文件到精简镜像，丢弃源代码和编译工具。
4. 清理缓存：在安装完依赖后，立即执行 rm -rf /var/cache/apk/* 或 yum clean all。
5. 非 Root 运行：创建普通用户运行业务进程，防止容器逃逸风险。

---

第三部分：K8s 编排与配置管理

一、无状态应用编排 (Deployment)

推荐配置规范： - 优雅停机：应用需能接收 SIGTERM 信号，处理完当前请求后再退出。 - 反亲和性 (Anti-Affinity)：配置 Pod 反亲和性，避免同一应用的多个副本调度到同一台节点上（容灾）。 - 健康检查 (Probes)： - Liveness Probe (存活检查)：探测失败重启容器（解决死锁）。 - Readiness Probe (就绪检查)：探测成功才接收流量（解决启动慢）。

二、配置与敏感信息管理

• ConfigMap：存储非敏感配置（如 nginx.conf, application.yaml）。
  • 使用方式：挂载为文件或注入为环境变量。
• Secret：存储敏感信息（如 DB 密码、证书）。
  • 数据 Base64 编码，加密存储于 Etcd。
  • 推荐挂载为内存卷（tmpfs），避免落盘。

三、资源限制与 QoS

K8s 通过 resources.requests 和 resources.limits 定义资源。

QoS 类别	定义条件	特点	适用场景
Guaranteed (有保证)	CPU/内存的 request = limit	资源绝对保障，最后被驱逐。	核心生产业务、数据库。
Burstable (弹性)	request < limit	允许短时突发，资源紧张时可能被驱逐。	大多数 Web 服务。
BestEffort (尽力而为)	未设置 request/limit	资源紧张时最先被驱逐。	开发测试、非关键任务。

最佳实践：生产环境务必设置 Request 和 Limit，防止“吵闹邻居”效应。

---

第四部分：存储、网络与高可用

一、数据持久化

容器是短暂的，数据是持久的。

• 云硬盘 CBS：
  • 特点：高性能，单点挂载（ReadWriteOnce）。
  • 适用：数据库（MySQL/Redis）、StatefulSet（每个 Pod 一块盘）。
• 文件存储 CFS：
  • 特点：支持多 Pod 同时读写（ReadWriteMany）。
  • 适用：共享文件、日志收集、Web 静态资源。

二、应用对外发布 (Service & Ingress)

1. Service (CLB)：
   • 模式：LoadBalancer。
   • 直通模式 (VPC-CNI)：CLB 直接转发流量到 Pod IP，不经过 NodePort，性能最高，支持源 IP 透传。
2. Ingress：
   • 适用：HTTP/HTTPS 七层路由。
   • TKE Ingress：基于腾讯云 CLB 实现，支持路径转发、TLS 卸载。

三、极致弹性伸缩

TKE 提供双重弹性机制：

3.1 业务层：HPA (Horizontal Pod Autoscaler)

• 原理：根据 CPU/内存利用率或自定义指标（如 QPS），自动调整 Pod 副本数。
• 效果：秒级应对流量洪峰。

3.2 资源层：CA (Cluster Autoscaler)

• 原理：当集群资源不足（Pod Pending）时，自动购买并添加 CVM 节点；负载低时自动缩容节点。
• 策略：
  • 多可用区打散：扩容时优先平衡各 AZ 的节点数量，容灾能力强。
  • 成本优先：优先扩容竞价实例或低价机型。

---

课程总结

知识体系回顾

1. 改造核心：无状态化、配置分离、日志标准输出。
2. 镜像构建：多阶段构建是减小镜像体积的神器。
3. K8s 编排：合理配置 Probe 和 QoS 是稳定性的基石。
4. 高可用：利用 HPA+CA 实现从 Pod 到 Node 的全栈自动伸缩。

架构师实践清单 (Checklist)

• [ ] 应用诊断：应用是否依赖本地 IP 或本地文件存储？（需改造）。
• [ ] Dockerfile：是否清理了 apt/yum 缓存？是否使用了非 Root 用户？
• [ ] 资源配额：生产环境 Pod 是否设置了 Request/Limit？
• [ ] 健康检查：是否配置了 Readiness Probe，防止启动期间报错？
• [ ] 数据持久化：有状态服务是否使用了 StatefulSet + PVC？

本章课程到此结束。下一章，我们将进入 AI 与云架构结合的前沿领域，讲解 3.4 AI 和大模型。