跳到正文Lab学后总结 · Jimmy Huang's BlogLab学后总结
本页目录· 53 条
1. 一句话总结这个 Lab
这个 Lab 的核心是：让你理解 Kubernetes 如何把一个或多个容器应用放进集群里运行，并通过 Deployment、Pod、Service 等对象实现自动调度、扩缩容、故障恢复和对外访问。
换成初学者语言就是：
Docker 负责“把程序装进标准箱子”，Kubernetes 负责“管理一整堆箱子应该放在哪里、坏了怎么办、怎么对外提供服务”。
2. 这个 Lab 实际做了什么
由于 Lab 页面正文材料未显示，下面不能断言具体命令和资源名称。根据标题 Container Orchestration with Kubernetes，这个 Lab 大概率围绕下面这条主线展开：
2.1 先准备一个 Kubernetes 环境
你需要先有一个可以运行 Kubernetes 的地方，例如：
材料未显示/不确定：具体使用的是哪一种环境。
初学者要理解的是：
Kubernetes 不是单独运行一个容器的工具，而是一个“集群管理系统”。你需要先有一个 Kubernetes cluster，它才能帮你管理容器。
2.2 使用 kubectl 和 Kubernetes 沟通
通常 Kubernetes Lab 会使用 kubectl 命令行工具，例如：
这些命令的目的不是“运行普通 Linux 命令”，而是：
你通过 kubectl 把指令发给 Kubernetes 控制中心，让 Kubernetes 去创建、查看、修改或删除资源。
材料未显示/不确定：Lab 里具体用了哪些 kubectl 命令。
2.3 把应用描述成 Kubernetes YAML
Kubernetes 不通常让你手动点按钮去创建每个容器，而是让你写一个配置文件，常见格式是 YAML。
要运行什么镜像；
要运行几个副本；
Pod 需要什么标签；
Service 如何把流量转发到 Pod；
应用是否需要环境变量、端口、资源限制等。
YAML 文件像一张“施工图纸”。你告诉 Kubernetes：我想要最终系统长什么样。Kubernetes 会努力让真实状态变成这张图纸描述的状态。
材料未显示/不确定：Lab 中的 YAML 文件内容、文件名、镜像名和端口号。
2.4 创建 Pod / Deployment 来运行应用
在 Kubernetes 里，应用通常不是直接以“Docker container”的身份被你管理，而是被包在 Pod 里面。
更常见的做法是：你创建一个 Deployment，Deployment 再帮你维护 Pod。
你一般不直接长期管理 Pod，而是管理 Deployment。因为 Pod 坏了会被替换，Deployment 才是更稳定、更适合声明应用状态的对象。
材料未显示/不确定：Lab 是否显式讲了 ReplicaSet，还是只让你使用 Deployment。
2.5 创建 Service，让别人能稳定访问应用
Pod 是会变化的。它可能被删除、重建、迁移到别的 Node 上，所以 Pod IP 不是一个适合作为长期入口的地址。
材料未显示/不确定：Lab 中使用的是 ClusterIP、NodePort、LoadBalancer，还是其他方式。
2.6 观察 Kubernetes 的自动管理能力
Kubernetes Lab 通常会让你观察这些现象：
这些操作是为了让你理解 Kubernetes 的核心能力：
Kubernetes 不是只负责“启动容器”，而是持续检查系统状态。如果真实状态和你声明的期望状态不一致，它会自动修正。
材料未显示/不确定：Lab 是否包含删除 Pod、扩缩容、滚动更新等操作。
3. 每个核心组件有什么用
下面按初学者最容易遇到的 Kubernetes 概念来解释。具体哪些组件出现在 Lab 页面里：材料未显示/不确定。
3.1 Container：真正运行程序的小盒子
Container 是运行应用程序的隔离环境。比如一个 Web API、一个前端页面、一个后台任务，都可以放在容器里。
没有容器，Kubernetes 就没有具体应用可以调度和管理。
Container 通常被放在 Pod 里面运行；Kubernetes 不直接把“裸程序”部署到机器上，而是调度 Pod。
3.2 Image：容器的模板
Image 是创建 Container 的模板。它包含应用代码、依赖、运行环境和启动命令。
Deployment 需要指定 Image，Kubernetes 才知道要启动什么应用。
没有 Image，Kubernetes 不知道容器里应该运行什么。
Deployment 中会写 Image 名称；Node 会拉取 Image；Pod 里的 Container 基于这个 Image 启动。
3.3 Kubernetes Cluster：管理容器的“大系统”
Cluster 是 Kubernetes 的整体环境，由控制平面和多个工作节点组成。
它是所有 Pod、Deployment、Service 运行和被管理的地方。
没有 Cluster，就没有 Kubernetes 编排能力，只能像普通 Docker 那样单独运行容器。
所有 Kubernetes 对象都存在于 Cluster 中；kubectl 也是连接 Cluster 来操作资源。
3.4 Node：真正干活的机器
Node 是 Kubernetes 集群中的工作机器，可以是虚拟机、云服务器，也可以是本地实验环境里的节点。
Kubernetes 控制平面决定 Pod 应该调度到哪个 Node；Node 上的 kubelet 负责把 Pod 跑起来。
3.5 Control Plane：Kubernetes 的“大脑”
Control Plane 是 Kubernetes 的控制中心，负责接收指令、保存状态、调度资源、检测变化。
当你执行 kubectl apply 时，Control Plane 会接收你的配置，并决定如何让集群达到目标状态。
没有 Control Plane，Kubernetes 就无法自动调度、扩缩容和恢复故障。
kubectl 和 Control Plane 通信；Control Plane 再指挥 Node 去运行 Pod。
3.6 kubectl：你和 Kubernetes 对话的工具
kubectl 是 Kubernetes 的命令行客户端。
它负责把你的命令发送给 Kubernetes，例如创建 Deployment、查看 Pod、暴露 Service。
你仍然可以通过 API 或图形界面操作 Kubernetes，但在 Lab 中通常就很难完成实验步骤。
kubectl 不直接运行容器；它只是把请求发给 Kubernetes API Server。
3.7 YAML Manifest：声明系统目标状态的图纸
YAML Manifest 是 Kubernetes 配置文件，用来描述资源对象。
它告诉 Kubernetes：我要什么 Deployment、几个副本、开放哪个端口、用什么标签匹配 Pod 等。
你可能只能用命令手动创建资源，不利于复现、版本控制和团队协作。
kubectl apply -f xxx.yaml 会把 YAML 提交给 Kubernetes；Kubernetes 再按 YAML 创建对象。
3.8 Pod：Kubernetes 里最小的部署单位
Pod 是 Kubernetes 调度的最小单位。一个 Pod 里可以有一个或多个容器。
Kubernetes 没法直接运行你的应用，因为容器通常是被包在 Pod 里调度的。
Deployment 管理 Pod；Service 通过标签找到 Pod；Node 负责运行 Pod。
3.9 Deployment：管理应用副本和更新的对象
Deployment 是 Kubernetes 中非常常用的应用部署对象，用来声明“我希望这个应用有几个副本、用哪个镜像、如何更新”。
你可以直接创建 Pod，但 Pod 坏了、更新了、扩缩容时会很难管理。
Deployment 创建 ReplicaSet，ReplicaSet 维护 Pod 数量，Pod 运行容器。
3.10 ReplicaSet：保证 Pod 数量正确的对象
ReplicaSet 的任务是确保某类 Pod 的数量符合预期。
如果 Deployment 要 3 个副本，ReplicaSet 会尽量确保有 3 个 Pod 在运行。
Pod 数量可能无法自动维持。某个 Pod 坏了后，不一定会自动补回来。
通常你不会手动管理 ReplicaSet，而是通过 Deployment 间接使用它。
材料未显示/不确定：Lab 是否要求你直接查看 ReplicaSet。
3.11 Service：给 Pod 提供稳定入口
Service 是 Kubernetes 的网络抽象。它给一组 Pod 提供一个稳定访问地址。
它让请求能够找到正确的 Pod，即使 Pod 被重建、IP 改变，也不会影响入口。
你只能直接访问 Pod IP，但 Pod IP 不稳定，不适合真实服务。
Service 通过 label selector 找到 Pod；请求先进 Service，再转发给后端 Pod。
3.12 Label 和 Selector：Kubernetes 的“标签匹配系统”
Label 是贴在资源上的标签；Selector 是根据标签筛选资源的规则。
Service 依靠 selector 找到应该转发流量的 Pod。
Service 可能找不到 Pod，请求就无法正确转发。
Deployment 会给 Pod 打 label；Service 用 selector 匹配这些 label。
3.13 Namespace：给资源分区的逻辑空间
Namespace 是 Kubernetes 内部的逻辑隔离空间。
如果 Lab 使用 Namespace，它可以把本 Lab 的资源和其他资源分开。
Pod、Deployment、Service 等资源可以放在某个 Namespace 里。
材料未显示/不确定：Lab 是否使用 Namespace。
3.14 ConfigMap 和 Secret：配置与敏感信息管理
如果 Lab 涉及配置管理，它们可能用于把配置注入到 Pod。
配置可能被硬编码在镜像或 YAML 中，不利于维护；敏感信息也可能不安全。
Deployment 可以把 ConfigMap 或 Secret 注入到 Pod 的环境变量或文件中。
材料未显示/不确定：Lab 是否使用 ConfigMap 或 Secret。
4. 用初学者类比解释
可以把 Kubernetes 想象成一个“智能小区物业系统”。
4.1 Kubernetes Cluster = 整个小区
Kubernetes Cluster 就像一个大型小区。小区里有很多楼、很多房间，还有一个物业管理中心。
小区 = Kubernetes Cluster；
楼 = Node；
房间 = Pod；
房间里的住户/设备 = Container；
物业管理中心 = Control Plane；
小区门口服务台 = Service；
施工图纸 = YAML；
你给物业发指令的 App = kubectl。
4.2 Node = 小区里的楼
Node 就像小区里的一栋楼。真正的房间都在楼里，所以真正运行应用的 Pod 也在 Node 上。
如果一栋楼空间不够，物业可能会把新的房间安排到另一栋楼。
4.3 Pod = 房间
Pod 就像一个房间。房间里可以放一个或多个设备。
多数时候，一个 Pod 里只跑一个主要容器，就像一个房间里住一个主要租户。
4.4 Container = 房间里的设备/租户
一个后端 API 容器负责处理请求；
一个前端容器负责提供网页；
一个数据库容器负责存数据。
但要注意：这个 Lab 是否包含数据库，材料未显示/不确定。
4.5 Deployment = 物业的长期安排计划
我要有 3 间一模一样的服务房间，里面都运行同一个应用。如果坏了一间，请自动补一间。
是不是少了一间；
是不是有房间坏了；
是不是需要换新版本；
是不是要从 3 间扩到 5 间。
4.6 Service = 小区前台/门牌号
Pod 会变，房间号可能换，但用户不能每次都自己找新房间。
Service 就像小区前台。用户只需要找前台，前台知道现在哪些房间可以服务，然后把请求转过去。
这就是为什么不能让用户直接依赖 Pod IP，而应该通过 Service 访问。
4.7 Label / Selector = 房间门牌标签和筛选规则
有些房间贴着 app=web；
有些房间贴着 app=database；
有些房间贴着 version=v1。
我要把请求发给所有贴着 app=web 标签的房间。
这就是 label 和 selector 的作用。
4.8 YAML = 施工图纸
你不是每次都口头告诉物业怎么安排，而是交一份图纸：
我要几个房间，用什么设备，开放哪个门，贴什么标签。
5. 重点区分容易混淆的概念
5.1 Docker 和 Kubernetes 的区别
Docker 解决“怎么把程序装箱”；Kubernetes 解决“很多箱子怎么被统一管理”。
5.2 Container 和 Pod 的区别
在 Kubernetes 里，你通常看到和管理的是 Pod，但真正运行代码的是 Pod 里的 Container。
5.3 Pod 和 Deployment 的区别
Pod 像临时房间，Deployment 像长期租赁合同。你要管理合同，而不是天天盯着每个房间。
5.4 Deployment 和 ReplicaSet 的区别
Deployment 是总管，ReplicaSet 是帮它数房间数量的小主管。
5.5 Service 和 Pod IP 的区别
不要把 Pod IP 当成正式访问入口。Pod 重建后 IP 可能变，Service 才是稳定入口。
5.6 ClusterIP、NodePort、LoadBalancer 的区别
材料未显示/不确定：这个 Lab 具体使用哪一种 Service 类型。
5.7 Service 和 Ingress 的区别
Service 像小区前台，Ingress 像更高级的大门保安，可以根据“你要去哪栋楼/哪个部门”分流。
材料未显示/不确定：这个 Lab 是否包含 Ingress。
5.8 ConfigMap 和 Secret 的区别
Secret 不是“绝对安全保险箱”，但它比把密码直接写进代码或普通 YAML 更合适。
材料未显示/不确定：这个 Lab 是否包含 ConfigMap 或 Secret。
5.9 谁能访问谁？
在一个基础 Kubernetes 应用里，可以这样理解：
外部用户通常不能直接访问 Pod；
外部用户应该通过 Service、Ingress 或 LoadBalancer 访问应用；
Service 可以根据标签找到 Pod；
Pod 之间是否能互相访问，取决于 Service、DNS、网络策略等配置；
如果设置了 NetworkPolicy，某些 Pod 之间的访问可能会被禁止。
材料未显示/不确定：Lab 是否涉及 NetworkPolicy 或安全隔离规则。
5.10 哪个是入口？哪个是数据库？哪个是权限控制？哪个是网络控制？
6. 这个 Lab 有什么实际用途
这个 Lab 的实际用途非常大，因为 Kubernetes 是现代云原生后端、DevOps 和平台工程里的核心技能之一。
6.1 在真实后端项目中的用途
FastAPI；
Flask；
Spring Boot；
Node.js Express；
Go API；
你可以把它打包成 Docker Image，然后交给 Kubernetes 部署。
应用坏了可以自动重启；
流量变大可以增加副本；
新版本可以滚动发布；
不用手动登录服务器一个个启动进程。
6.2 在云架构里的用途
在云平台中，Kubernetes 常用于部署微服务系统。
用户服务；
商品服务；
订单服务；
支付服务；
推荐服务；
后台管理服务。
每个服务都可以作为 Deployment 部署，再用 Service 互相访问。
Kubernetes 帮你把这些服务组织起来，而不是让它们混乱地跑在几台服务器上。
6.3 在 DevOps / CI/CD 里的用途
Kubernetes 很适合和 CI/CD 流程结合：
开发者提交代码；
CI 系统构建 Docker Image；
Image 推送到镜像仓库；
CD 系统更新 Kubernetes Deployment；
Kubernetes 滚动发布新版本；
如果新版本有问题，可以回滚。
这就是为什么很多公司把 Kubernetes 当作部署平台。
6.4 在可靠性设计里的用途
材料未显示/不确定：Lab 是否具体配置了 liveness/readiness probe。
6.5 在安全设计里的用途
材料未显示/不确定：Lab 是否涉及这些安全内容。
6.6 和课程/作业的关系
如果你的课程涉及云计算、DevOps、微服务、容器化部署或云原生架构，那么这个 Lab 很关键。
它帮助你从“我会运行一个 Docker 容器”升级到：
我知道如何让一个容器化应用在集群中稳定运行、对外服务、自动恢复并支持扩展。
7. 生动形象的示意图
下面是一张适合初学者理解的 Kubernetes 架构 / 请求流程图。
由于 Markdown 文件不能直接放置生成图片，这里使用 Mermaid 图。你可以把它复制到支持 Mermaid 的编辑器、Notion、GitLab、GitHub 或 Markdown Preview 中查看。
最后复习：这个 Lab 你最应该带走什么
Kubernetes 是容器编排系统，不是单纯运行容器的工具。
Pod 是 Kubernetes 运行容器的最小单位，但通常不要直接长期管理 Pod。
Deployment 用来声明和维护应用副本，是部署无状态应用最常见的对象。
Service 是稳定入口，负责把请求转发给后端 Pod。
YAML 描述期望状态，Kubernetes 会持续让真实状态接近期望状态。
材料未显示 / 不确定清单
Lab 使用的 Kubernetes 环境：Minikube、Docker Desktop、kind、云端集群或课程环境；
具体 Docker Image 名称；
具体 Deployment / Service YAML 内容；
具体端口号；
是否使用 Namespace；
是否使用 ConfigMap / Secret；
是否使用 Ingress；
是否配置健康检查 Probe；
是否包含扩缩容、滚动更新、删除 Pod 自动恢复等实验步骤；
是否包含数据库；
是否包含 RBAC、NetworkPolicy、ServiceAccount 等安全配置。
如果之后你能把 Notion 页面正文、截图或导出的 PDF 发给我，我可以再把这份总结升级成“完全贴合 Lab 原文步骤”的版本。
kubectl get nodes
kubectl get pods
kubectl apply -f xxx.yaml
kubectl get services
Deployment 负责管理期望状态
↓
ReplicaSet 负责维持副本数量
↓
Pod 负责承载真正运行的容器
↓
Container 里面运行你的应用程序
flowchart TB
title["Lab 04: Container Orchestration with Kubernetes<br/>用 Kubernetes 管理容器应用"]
user["👤 外部用户 / Browser / Client"]
internet["🌐 网络请求"]
subgraph cluster["🏙️ Kubernetes Cluster：容器应用运行的小区"]
apiserver["🧠 Control Plane<br/>Kubernetes 大脑<br/>接收 kubectl 指令并维持期望状态"]
kubectl["💻 kubectl<br/>你发命令的工具"]
yaml["📄 YAML Manifest<br/>应用部署图纸"]
subgraph node1["🏢 Node 1：工作机器"]
svc["🚪 Service<br/>稳定入口 / 前台<br/>根据 Label 找 Pod"]
pod1["🏠 Pod A<br/>label: app=web<br/>Container: Web App"]
pod2["🏠 Pod B<br/>label: app=web<br/>Container: Web App"]
end
subgraph node2["🏢 Node 2：工作机器"]
pod3["🏠 Pod C<br/>label: app=web<br/>Container: Web App"]
end
deploy["📦 Deployment<br/>声明：我要几个副本、用哪个镜像、如何更新"]
rs["🔁 ReplicaSet<br/>保证 Pod 数量正确"]
end
blocked["❌ 不推荐直接访问 Pod IP<br/>Pod 会被删除 / 重建 / 换 IP"]
user --> internet --> svc
svc -->|"根据 selector: app=web 转发"| pod1
svc -->|"负载均衡"| pod2
svc -->|"负载均衡"| pod3
kubectl -->|"apply / get / delete / scale"| apiserver
yaml -->|"kubectl apply -f"| apiserver
apiserver --> deploy
deploy --> rs
rs --> pod1
rs --> pod2
rs --> pod3
user -. "❌ 不稳定，不应该作为正式入口" .-> blocked
blocked -. "❌" .-> pod1
remember["✅ 你要记住的核心区别<br/>1. Container 运行程序，Pod 承载 Container<br/>2. Deployment 管理 Pod 副本和更新<br/>3. Service 才是稳定访问入口<br/>4. kubectl 只是发指令，真正执行的是 Kubernetes<br/>5. YAML 是声明目标状态，不是普通脚本"]
cluster --> remember
classDef red fill:#ffe6e6,stroke:#cc0000,color:#990000;
classDef green fill:#e8f7e8,stroke:#228b22,color:#0b4d0b;
classDef blue fill:#e6f0ff,stroke:#3366cc,color:#002b80;
classDef yellow fill:#fff8dc,stroke:#d6a300,color:#6b4e00;
class blocked red;
class remember green;
class apiserver,kubectl,yaml blue;
class svc,deploy,rs yellow;