部署与云CASE 01
为什么代码在开发电脑能跑，上线却报错？
用户正在做什么
开发使用某个 Node 版本和系统库，服务器环境不同。
业务会出什么问题
环境差异造成依赖缺失、版本冲突和难以复现的问题。
技术怎样介入
Docker 把应用和运行依赖打包为 Image，在任何兼容 Host 上启动一致的 Container。
产品与设计怎样落地
问题反馈中记录版本和环境，避免只描述“页面坏了”。
M4 · Chapter 11
Docker 与 Kubernetes
理解应用如何被打包、复制、调度和自动恢复。
先看哪些场景
部署与云、研发协作、性能与扩容、项目与协作
它是什么
容器把应用和运行依赖打包成一致环境，Kubernetes 管理大量容器的部署、扩容和恢复。
为什么需要
团队需要让应用在开发、测试和生产中一致运行，并自动管理多个实例。
位于哪一层
位于应用与云基础设施之间，是现代运行与编排层。
和谁连接
Image、Container、Dockerfile、Registry、Compose、Pod、Deployment、Service、Ingress 和 Cluster。
项目里怎么出现
前端、后端、数据库工具和 Worker 都可以被容器化并部署到集群。
Learning Outcomes
学完这一章，你应该能
- 区分 Image 与 Container
- 理解 Dockerfile、Registry 和 Compose
- 看懂 Kubernetes 的核心资源关系
- 区分后端 Service、微服务与 Kubernetes Service
11.01
Docker 解决什么问题？
把代码、运行时和依赖封装成可重复运行的镜像。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
应用依赖特定 Node、Python、系统库和配置。本地与服务器环境不同会导致运行差异。Docker 使用标准镜像描述环境，让同一版本在多处一致启动。
容器共享宿主机内核，比完整虚拟机更轻。它提供隔离和可复制环境，但数据持久化、网络和安全仍需设计。
Code + Runtime + Dependencies + Config → Image → Container
System View
直接部署
- 依赖安装在服务器
- 环境差异明显
- 迁移和回滚困难
容器部署
- 环境随镜像版本化
- 启动方式统一
- 易复制和回滚
Designer Lens
Docker 处理运行环境，页面交互和业务逻辑仍由应用代码负责。
ContainerImageHost
11.02
Image、Container 与 Registry
镜像像发布包，容器是镜像正在运行的实例。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
部署与云CASE 01
同一个订单服务怎样发布 1.2 和 1.3 两个版本？
用户正在做什么
测试环境验证新版，生产环境仍运行稳定版。
业务会出什么问题
没有版本化制品会导致部署内容不确定，也无法快速回滚。
技术怎样介入
Image 通过 Tag 标记版本并推送到 Registry；Container 从指定版本启动；Volume 保存需要持久化的数据。
产品与设计怎样落地
后台或诊断页可展示当前版本，便于问题对照。
构建一次镜像后，可以启动多个容器。Registry 保存和分发镜像版本，部署系统从 Registry 拉取指定版本。
容器自身文件通常被视为临时状态，数据库和上传文件应使用 Volume 或外部托管存储。
Dockerfile → Build Image → Push Registry → Pull → Run Containers
System View
源码
→
构建镜像 v1.4
→
推送 Registry
→
服务器拉取
→
启动多个容器
Designer Lens
版本号应对应可追踪发布，避免使用无法确认内容的模糊标签。
RegistryTagVolume
11.03
Dockerfile 与 Docker Compose
Dockerfile 描述单个镜像，Compose 编排一组本地或简单环境服务。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
研发协作CASE 01
新成员如何一条命令启动前端、API 和数据库？
用户正在做什么
项目包含三个服务，每个都有不同依赖和启动方式。
业务会出什么问题
手工安装会导致环境不一致，入门成本高。
技术怎样介入
Dockerfile 描述单个镜像，Docker Compose 编排多个容器，Base Image 提供基础运行环境。
产品与设计怎样落地
README 和本地演示流程应明确数据初始化、端口和失败排查。
Dockerfile 声明基础镜像、复制文件、安装依赖、构建应用和启动命令。良好镜像要小、可缓存、权限合理并避免包含密钥。
Compose 可以一次启动 Web、API、PostgreSQL 和 Redis，适合本地开发、课程演示和简单部署。
Dockerfile → One Image；compose.yaml → Multiple Services
System View
services:
web:
build: ./web
api:
build: ./api
db:
image: postgres
redis:
image: redisDesigner Lens
一个完整产品本地运行时，往往已经包含多个容器，即使生产架构仍是单体。
DockerfileDocker ComposeBase Image
11.04
为什么需要 Kubernetes？
当容器数量和机器数量增加，需要统一调度与自动化管理。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
性能与扩容CASE 01
几十个微服务和几百个容器谁来管理？
用户正在做什么
业务高峰需要增加实例，故障后还要自动恢复。
业务会出什么问题
人工登录服务器启动和搬迁容器无法应对大规模变化。
技术怎样介入
Kubernetes 在 Cluster 中通过 Control Plane 调度、扩缩和恢复容器工作负载。
产品与设计怎样落地
产品要接受实例动态变化，用户状态不能依赖某一台机器。
Kubernetes 根据声明状态把容器放到合适节点，保持期望副本数，发现故障后重新启动，并支持滚动发布和自动扩缩。
它解决大规模运行问题，也增加概念、配置和运维成本。小型应用可以使用托管平台或简单容器部署。
Desired State → Kubernetes Control Plane → Nodes → Pods
System View
提交 Deployment
→
调度到 Node
→
创建 Pods
→
健康检查
→
故障重建
→
扩容与滚动更新
Designer Lens
Kubernetes 不会自动修复业务 Bug，它保证容器按声明运行，并提供运行治理能力。
KubernetesClusterControl Plane
11.05
Pod、Deployment、Service 与 Ingress
这些资源分别负责运行单元、版本与副本、稳定入口和外部路由。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
部署与云CASE 01
一个订单请求在 Kubernetes 里怎样找到正确容器？
用户正在做什么
外部用户访问 /orders，后台同时运行多个订单 Pod。
业务会出什么问题
Pod 地址会变化，客户端无法直接依赖某个实例。
技术怎样介入
Ingress 接收外部流量，Kubernetes Service 提供稳定入口，Deployment 管理多个 Pod。
产品与设计怎样落地
维护和扩容过程应保持用户入口稳定，避免暴露内部拓扑。
Pod 是最小调度单元，通常包含一个主要容器。Deployment 声明镜像版本和副本数，并管理更新。
Kubernetes Service 为变化的 Pod 提供稳定内部地址，Ingress 把外部域名和路径转发到不同 Service。
Ingress → Kubernetes Service → Deployment → Pods → Containers
System View
Ingress：外部路由
Kubernetes Service：稳定网络入口
Deployment：版本与副本
Pod：调度单元
Container：应用进程
Designer Lens
Pod 地址会变化，Service 提供稳定访问；这与后端代码中的 Service 含义完全不同。
PodDeploymentKubernetes ServiceIngress
11.06
滚动更新、自愈与自动扩缩
Kubernetes 根据健康状态和负载维持应用运行。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
性能与扩容CASE 01
发布新版时为什么用户几乎感觉不到停机？
用户正在做什么
订单服务从 v1 更新到 v2，同时流量持续进入。
业务会出什么问题
一次关闭全部旧实例再启动新版会造成中断，新实例未准备好也会返回错误。
技术怎样介入
Rolling Update 分批替换；Readiness Probe 确认实例可接流量；Autoscaling 根据负载增加实例。
产品与设计怎样落地
设计兼容旧新版本同时运行的状态，重要操作避免在切换中丢失。
Rolling Update 逐步替换旧 Pod，减少停机。Readiness Probe 决定实例是否接收流量，Liveness Probe 判断是否需要重启。
Horizontal Pod Autoscaler 可以根据 CPU 或自定义指标调整副本数。自动扩缩仍受数据库、队列和外部依赖容量限制。
New Version → Gradual Pods → Readiness → Traffic Shift → Old Pods Removed
System View
创建新 Pod
健康检查
加入流量
逐步替换
发现异常暂停或回滚
完成发布
Designer Lens
发布过程中用户可能同时访问新旧版本，接口和数据结构需要兼容。
Rolling UpdateReadiness ProbeAutoscaling
11.07
三个 Service 如何区分？
同一个词在代码、架构和 Kubernetes 中代表不同层级。
Business Scenario First
先从真实业务问题进入
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
项目与协作CASE 01
开发会议里三个 Service 分别指什么？
用户正在做什么
团队说“Project Service 里加校验”“拆成文档微服务”“K8s Service 没转发到 Pod”。
业务会出什么问题
同一个词跨代码、架构和平台层使用，容易造成理解错位。
技术怎样介入
Service Layer 是代码中的业务层；Microservice 是独立部署应用；Kubernetes Service 是集群网络入口。
产品与设计怎样落地
沟通时补上层级和完整名称，设计师可以继续追问它影响哪段用户流程。
后端 Service 是代码层，封装业务逻辑；微服务是架构层，可独立部署的业务能力；Kubernetes Service 是基础设施层，为 Pod 提供稳定网络地址。
判断含义时看它的上下文：代码目录、系统架构图或集群配置。技术沟通里明确层级可以减少大量误解。
Code Service ≠ Microservice ≠ Kubernetes Service
System View
代码层 Service：业务逻辑
架构层 Microservice：独立业务服务
K8s Service：稳定网络入口
Designer Lens
这类同名概念正是全景学习的价值：先放到层级里，再理解细节。
Service LayerMicroserviceKubernetes Service
Chapter Recap
本章小结
- 01Docker 镜像封装运行环境，容器是运行实例。
- 02Registry 保存镜像，Compose 组织多个容器。
- 03Kubernetes 管理调度、副本、更新、恢复和扩缩。
- 04Pod、Deployment、Service、Ingress 位于不同运行层级。
Practice
把认知变成一张图
画出浏览器请求进入 Kubernetes 后经过 Ingress、Service、Deployment、Pod、Container 的路径。
Quick Check
随堂检查
QUESTION 01
Docker Image 与 Container 的关系是什么？
镜像用于创建一个或多个运行中的容器。
QUESTION 02
Kubernetes Service 主要提供什么？
Kubernetes Service 为动态 Pod 提供稳定地址和流量入口。