课程导入：学习目标、适用人群与Edge AI容器化部署的整体背景

欢迎来到《Edge AI容器滚动升级与服务不中断部署》课程的第一章。在正式开始技术细节之前，我们需要先建立一个全局视角：为什么边缘AI（Edge AI）与容器化技术的结合如此重要？为什么“滚动升级”和“服务不中断”会成为生产环境中的核心诉求？本章将帮助你明确学习路径、判断自身定位，并理解这门课程所依托的技术与业务背景。我们将从三个维度展开：学习目标与课程地图、适用人群与前置要求、以及Edge AI与容器化部署的整体背景与商业价值。

1.1 学习目标：从“能部署”到“会升级”

本课程并非简单的容器入门教程，而是聚焦于一个非常具体且极具挑战的生产场景：在边缘AI环境中，如何安全、自动、可回滚地完成容器化应用的版本升级，同时保证推理服务不中断。完成本课程后，你将具备以下核心能力：

• 理解边缘AI部署的特殊性：掌握边缘设备（如工业网关、智能摄像头、车载计算单元）在算力、存储、网络、功耗方面的约束，以及这些约束如何影响容器化策略。
• 掌握容器化基础与工具链：熟练使用Docker/Containerd进行镜像构建与分发，理解OCI标准，并能在资源受限的边缘节点上运行轻量化容器运行时。
• 精通滚动升级策略：深入理解Kubernetes（K8s）及轻量级发行版（K3s、KubeEdge）中的滚动更新（Rolling Update）机制，包括maxSurge、maxUnavailable等关键参数调优。
• 实现服务不中断的实战技巧：掌握Readiness Probe、PreStop Hook、优雅退出等机制，确保在Pod替换期间流量无损切换。
• 构建可观测性与回滚体系：学会使用Prometheus、Grafana等工具监控升级过程，并设计自动回滚策略以应对升级失败。

1.2 适用人群：谁需要这门课程？

本课程面向的受众具有明显的“复合型”特征，既需要一定的开发背景，也需要对运维和AI部署有基本认知。具体包括以下四类人群：

前置要求： 学员需要具备基础的Linux命令行操作能力，了解Docker的基本概念（如镜像、容器、Dockerfile），并对HTTP/REST API、JSON数据格式有基本认知。如果你对Kubernetes完全陌生，也不必担心，本课程第3章会专门补充必要的K8s基础，但不会从零讲解所有概念，而是聚焦于与部署、升级相关的核心对象（Deployment、Service、Pod）。

1.3 Edge AI与容器化部署的整体背景

要理解为什么“滚动升级”在Edge AI中如此重要，必须先看清整个技术演进的大背景。边缘AI指的是在靠近数据源头的网络边缘侧（如摄像头、传感器、工业控制器）直接运行AI推理算法，而非将数据全部上传至云端处理。这种模式带来了显著的低延迟、数据隐私、带宽节省优势，但同时也将复杂的软件管理问题从集中式的云数据中心扩散到了成千上万个分散、异构、网络条件各异的边缘节点上。

容器化技术天然适合解决边缘AI的软件交付难题。通过将AI模型、推理引擎（如TensorRT、OpenVINO）、依赖库和业务逻辑打包成一个独立的容器镜像，可以实现“一次构建，到处运行”的效果。然而，边缘场景的特殊性给容器化部署带来了新的挑战：

1. 资源约束：边缘设备往往只有2-4GB内存，存储空间有限，无法运行完整的Kubernetes集群，需要引入K3s、MicroK8s等轻量级方案。
2. 网络不稳定：边缘节点可能通过4G/5G或Wi-Fi连接，带宽有限且时断时续，导致镜像拉取失败或升级中断。
3. 设备异构性：不同厂商的AI加速芯片（如NVIDIA Jetson、华为昇腾、寒武纪）需要不同的驱动和运行时，容器镜像需要针对特定硬件进行优化。
4. 业务连续性要求高：在工业质检、自动驾驶等场景中，AI推理服务的中断可能直接导致产线停摆或安全事故，因此升级过程必须做到“无缝切换”。

1.4 滚动升级的核心原理与价值

滚动升级（Rolling Update）是一种优雅的部署策略，其核心思想是逐步用新版本Pod替换旧版本Pod，在整个过程中始终保持有足够数量的Pod在运行，从而保证服务的连续可用性。在Kubernetes中，这一机制由Deployment控制器自动实现，但默认参数往往无法满足边缘AI场景的严苛要求。

滚动升级的关键参数包括：

• maxSurge：允许超出期望副本数的最大Pod数量。例如，期望副本数为3，maxSurge=1，则升级期间最多允许4个Pod同时存在。
• maxUnavailable：允许不可用Pod的最大数量或百分比。例如，maxUnavailable=0表示升级期间不允许任何Pod处于不可用状态，这是服务不中断的硬性要求。
• minReadySeconds：Pod就绪后需要等待多少秒才被视为可用，用于避免因启动抖动导致的误判。

在边缘AI场景中，默认的滚动升级策略往往需要调整。例如，由于边缘设备算力有限，同时启动多个新Pod可能导致资源争抢，因此需要将maxSurge设置为0，采用“先删后建”或“逐个替换”的方式。此外，由于模型加载需要时间（尤其是大模型），Readiness Probe的初始延迟（initialDelaySeconds）必须设置得足够大，否则新Pod会被过早地杀死。

1.5 案例拆解：从一次失败的升级到滚动策略的引入

为了让你更直观地理解滚动升级的价值，我们来看一个真实的项目复盘。某智慧零售公司在全国200家门店部署了基于边缘服务器的客流统计系统，每台服务器运行一个容器化的TensorFlow模型，通过RTSP协议分析摄像头视频流。

初始状态与问题： 最初，该公司采用“脚本+定时任务”的方式手动升级模型。每次升级时，运维人员通过SSH登录每台服务器，执行docker stop和docker run命令。这种方式存在三个严重问题：

1. 升级期间服务中断：从停止旧容器到新容器完全启动并加载模型，大约需要40-60秒，期间门店的客流统计完全失效。
2. 人工操作易出错：200台服务器逐一操作，容易遗漏或输错命令，导致部分门店版本不一致。
3. 无法快速回滚：如果新模型存在bug（如误检率过高），需要再次手动操作回退到旧版本，耗时更长。

关键数据与指标： 在一次升级中，由于新模型对光线变化过于敏感，导致某门店的客流统计准确率从95%骤降至70%。从发现问题到完成回滚，耗时2小时15分钟，期间该门店的运营决策基于错误数据，造成了约3000元的经济损失（主要是营销资源浪费）。

解决方案与实施步骤： 该团队随后引入了K3s（轻量级Kubernetes）和GitLab CI/CD流水线，实现了以下流程：

1. 将模型推理服务容器化，并编写Deployment YAML，设置replicas: 2（每台服务器运行2个推理实例，利用多核CPU并行处理）。
2. 配置Readiness Probe，通过HTTP请求/health端点检查模型是否加载完成，设置initialDelaySeconds: 30，periodSeconds: 10。
3. 设置滚动升级策略：maxSurge: 0，maxUnavailable: 1，确保每次只替换一个Pod，且始终有一个Pod在提供服务。
4. 在CI/CD流水线中，将新镜像推送到私有仓库后，自动执行kubectl set image deployment/retail-counter retail-counter=registry.example.com/retail-counter:v2.1。
5. 配置Prometheus监控Pod的启动时间、错误率等指标，并设置告警规则。如果新Pod在5分钟内无法通过Readiness Probe，自动触发回滚。

结果对比： 引入滚动升级后，单台服务器的升级时间从原来的“停机60秒+手动操作10分钟”缩短为“自动滚动替换，单Pod切换时间约2秒”。更重要的是，由于始终有一个Pod在运行，客流统计服务完全无感知。在后续的一次模型升级中，新模型在部分门店出现了推理延迟升高的问题，监控系统在3分钟内捕捉到P99延迟超过500ms的异常，自动触发了回滚，将影响范围控制在5家门店，且每家门店的服务中断时间不超过10秒。

复盘经验： 这次实践揭示了三个关键教训：第一，边缘AI升级的核心不是“快”，而是“稳”，宁可牺牲升级速度也要保证业务连续性；第二，Readiness Probe的设计必须贴合模型加载的实际耗时，否则会导致新Pod被反复重启；第三，自动回滚机制不是可选项，而是必备项，因为人工决策在分布式环境中往往太慢。

1.6 常见误区与总结

在课程正式开始前，我们有必要澄清几个关于Edge AI容器化部署的常见误区，这些误区可能导致你在后续学习中走弯路：

本章总结： 我们明确了本课程的学习目标——掌握在Edge AI环境中实现容器化应用滚动升级与零停机部署的完整方法论。你了解了课程的适用人群，并建立了对Edge AI与容器化结合的整体认知。更重要的是，通过一个真实的案例拆解，你看到了从“手动停机升级”到“自动滚动升级”的转变过程，以及这种转变带来的巨大价值。在接下来的章节中，我们将逐步深入，从边缘AI的硬件与系统环境开始，逐步构建起一套完整的、可落地的滚动升级体系。