1. 本周 Seminar 总览

这周 Seminar 的核心主题是：为什么只有容器还不够，为什么我们还需要“容器编排（Container Orchestration）”。课件从上周的容器继续往前走，进入本周的 Docker Swarm 和 Kubernetes。课件本身的主线也很清楚：先讲“编排工具是什么、解决什么问题”，再讲 Docker Swarm，接着讲它背后的 Raft 共识算法，最后讲 Kubernetes 的基本架构，以及几个最重要的对象：Pod、Deployment、Service。

老师在 transcript 里其实补了一个非常重要的背景：容器虽然启动快、比 VM 轻量、适合微服务，但当请求量增加、服务变多、需要高可用和自动管理时，只靠手动管理容器会马上遇到问题。比如：扩容后用户不知道新容器的地址、多个容器怎么协调、怎么自动监控健康状态、怎么保证系统一直可用。老师就是从这些“真实部署会遇到的麻烦”切入，带出为什么要学 orchestration。

还有一个很关键的学习导向：这周内容不是单纯记概念，而是要学会带着场景做判断。老师多次说，quiz 和 assignment 里会有这种“solution architecting”风格的问题：给你一个系统场景，你要根据假设、需求、性能、可扩展性来解释为什么选某种技术。也就是说，这周内容既是理论，也是后面作业和考核的思维基础。

2. 核心知识点总结

知识点1：为什么要从“容器”走向“容器编排”

这部分在讲什么：

容器本身很好用，但当你只有一两个容器时还能手动管理；一旦服务变多、流量增长、要高可用、要自动扩缩容，就必须用 orchestration 工具。课件把编排工具定义为：在大规模下整合和管理容器的框架，能帮助你做网络、扩缩容、服务发现、负载均衡、健康检查、自愈、安全、滚动更新等事情。

为什么重要：

因为“能跑起来”和“能稳定上线”不是一回事。老师举了一个很实际的例子：假设你原来一个 web 容器能处理 1000 个用户，现在突然来了 5000 个请求，你当然可以加更多容器，但马上会遇到一个大问题：用户并不知道这些新容器的 IP 和端口。所以你虽然扩容了，用户却不一定能访问到新增资源。这就是为什么需要编排系统帮你做服务发现和负载分发。

怎么理解：

你可以把它理解成：

• 容器 = 单个工人
• Docker Compose = 小团队的手工协作表
• Orchestrator = 主管 / 调度员 / 现场经理

当团队很小，大家自己沟通就行；团队大了，没有调度系统就会乱。

知识点2：Orchestrator 到底在做什么