1 Kubernetes 架构要回答什么
订单 API 已经能在容器中运行，接下来要解决的是持续运行的问题：谁决定容器放在哪台机器，机器失联后谁补齐服务，发布要求怎样变成实际进程，运维人员又从哪里知道系统有没有完成要求。Kubernetes 把这些问题组织成可观察、可重复的控制过程。理解架构，就是能把“提交要求”“安排位置”“启动进程”“接收请求”分别交给正确的组件，并知道每个环节的证据在哪里。
先认识 Pod。它是 Kubernetes 调度和管理的基本运行单位，通常包含服务容器，也可以包含需要紧密协作的辅助容器。同属 Pod 的容器共享网络环境，并可以共享声明的卷。Pod 有自己的生命周期；旧 Pod 消失后创建的新 Pod 即使名称相似，也不能被当成原来的进程。订单记录因此不能只保存在某个容器的可写层中，应用仍需要数据库或合适的持久存储。
集群可以先分成控制面与工作节点。控制面接收期望、保存对象、选择节点，并持续比较期望与观察结果。工作节点提供实际的计算资源，让 Pod 中的容器运行。这里的“面”表示职责，不能直接换算成固定的机器数量。学习时可以把组件集中放置；生产方案需要明确哪些故障会同时影响多个组件，以及哪些资源必须隔离。
还有另一个容易混淆的区分：管理请求与业务请求。运维人员通过 Kubernetes API 创建对象，订单用户通过入口和服务网络访问 API 应用。正常业务请求通常不经过 Kubernetes API Server。即使控制面暂时无法接受新操作，已有 Pod 仍可能继续处理订单；但补副本、修改配置和更新路由信息等能力可能受影响。继续运行多久，取决于节点、网络、依赖与故障范围，不能只靠这张逻辑图保证。
用订单服务看云资源的连接关系：节点提供计算，网络插件帮助 Pod 获得连通性，存储组件协助挂载卷，身份与权限决定谁可以修改对象，监控系统收集控制过程和应用表现。Kubernetes 将这些资源纳入共同的声明式接口，却不会自动替应用完成数据库备份、业务鉴权或订单幂等。平台权限与订单用户权限也是不同的边界。
阅读后面的架构时，始终带着 3 个问题：期望保存在哪里，谁推动状态变化，成功由什么证据确认。应用响应失败可能发生在业务路径，Pod 无法启动可能发生在执行路径，发布无法提交可能发生在管理路径。先定位路径，才能避免把所有问题都归结为“集群坏了”。本课只建立这些基本关系，复杂调度策略、网络转发细节和存储内部机制留到后续专题。
2 API Server、调度与控制器闭环
API Server 是 Kubernetes API 的入口。用户、自动化程序和集群组件通过它读取或修改资源对象。创建请求通常要经过身份认证、权限检查、准入处理与对象校验等步骤，才会被持久化。认证回答“你是谁”，授权回答“你能对哪些资源做什么”，准入则可以继续检查或调整被提交的对象。拿到访问凭据，不代表已经获得创建任意工作负载的权限。
etcd 是控制面保存集群状态的关键存储，保存的是 Kubernetes 对象等信息，例如 Pod 的声明、节点记录和相关状态；订单数据库的业务记录通常在另一个系统中。其他组件通过 API Server 操作资源，不应绕过 API 直接修改 etcd。API 的写入成功说明对象已被接受并保存到相应阶段，不说明镜像已经拉取，也不说明用户已经能够访问订单服务。声明落库和业务可用之间存在控制与执行过程。
控制器负责持续缩小期望与实际之间的差距。例如 Deployment 声明订单 API 应有 3 个副本，相关控制器会通过 ReplicaSet 等对象推动 Pod 的创建。控制器观察的是它能够获得的状态，状态传播可能需要时间。它反复执行协调，而不是只在第一次提交时运行。进程重启或连接恢复后，只要期望还在，控制器就有机会继续协调；这也是声明式管理能适应中途故障的重要原因。
调度器负责为尚未分配节点的 Pod 寻找合适位置。它根据资源请求、节点条件和声明的约束筛选与选择节点，再通过 API 记录分配结果。它不会替节点启动容器，也不负责让所有运行中的 Pod 持续搬家以达到完美均衡。订单 Pod 的资源请求若超过任何可用节点的余量，调度器就可能让它保持等待；增加期望副本数不能凭空产生机器资源。
闭环可以概括为：观察对象，比较期望，执行允许的动作，再报告新的观察结果。这个过程没有要求所有组件同时看到完全相同的画面。控制器可能刚创建 Pod，调度器还没看到；调度结果已经保存，节点还没开始拉镜像。因此短暂的中间状态本身不一定是故障。判断是否异常，需要结合状态持续时间、事件和对应组件的健康情况。
这里还要区分“对象存在”和“目标实现”。Pod 出现在查询结果里，只证明管理系统知道这个对象；出现节点名，说明已经分配位置；容器运行、探针成功和应用能正确访问数据库，分别提供更进一步的证据。不要用最早的证据替代最终目标。声明式接口减少了手工指挥每个步骤的需要，但方案仍应为协调耗时、失败重试和业务验收分别设置可解释的判断标准。
3 节点代理、运行时与网络插件边界
Pod 被分配给节点后，主要执行责任落到该节点上的 kubelet。它是节点代理，会观察分配给本节点的 Pod，推动本地容器与声明保持一致，并向 API Server 上报节点和 Pod 状态。它还会参与卷挂载、执行已配置的探针等工作。kubelet 能重启本节点上的失败容器，却不能在机器彻底失联时亲自到另一台机器上补副本；跨节点的恢复还需要控制面的判断与协调。
容器运行时负责执行实际的容器操作。kubelet 通过 CRI，也就是容器运行时接口，请求兼容的运行时完成相关动作，例如准备 Pod 运行环境、拉取镜像和启动容器。运行时再使用操作系统提供的隔离与资源能力。本课不展开这些底层机制，只需记住：API Server 保存 Pod 对象，调度器决定位置，kubelet 推动节点执行，运行时创建和管理容器进程。它们不是可互换的角色。
网络插件常通过 CNI 接口参与 Pod 网络的配置。Pod 获得地址不等于所有访问都已打通：地址分配、跨节点路由、域名解析、Service 转发、入口配置以及网络策略，都可能有各自的组件和故障范围。Service 提供面向一组后端的稳定访问方式，后端集合随 Pod 状态变化而更新。常见实现使用 kube-proxy 处理部分 Service 转发规则，也有其他实现方式，不能把某个组件名称当成所有集群都采用的网络路径。
存储也有类似的分工。工作负载通过卷声明表达需要，存储相关控制器和节点组件协助供应、连接或挂载；CSI 是常见的存储扩展接口。挂载成功仍不代表应用数据已经有备份，数据库的一致性和恢复流程也不能由 Pod 状态推断。订单 API 如果依赖外部数据库，架构图应把该依赖单独画出，而不是因为它没有运行在集群内就将其遗漏。
身份边界在节点上尤其重要。拉取私有镜像需要相应凭据，Pod 内访问 Kubernetes API 可以使用 ServiceAccount 身份，访问云资源或数据库则取决于实际配置的身份机制。这些凭据用途不同，不应为了方便把集群管理员权限交给订单 API。平台侧应按需要赋予读取或修改资源的权限，应用侧仍要验证订单用户身份。能运行容器与有权读取客户订单是不同的能力。
排查时按职责拆开“启动失败”。节点已分配但镜像拉取失败，先检查镜像位置、访问凭据与节点连通性；容器已启动但没有就绪，检查探针、应用配置和依赖；Pod 间无法通信，检查网络路径及策略。这样得到的是具体的边界问题。反复删除 Pod 可能暂时改变现象，也可能丢失现场，无法替代对事件、节点日志和组件状态的检查。
4 动手：追踪一次 Pod 创建的控制路径
下面在有访问权限的练习集群中追踪 1 个 Pod。选择允许创建资源的练习命名空间，确保其中没有同名对象，并使用实验提供的可访问镜像。示例中的 training、order-api-trace 和镜像地址需要与实际环境一致。直接创建 Pod 是为了缩短观察路径；长期维护副本和发布版本通常交给更高层的工作负载对象，下一课再展开。练习结束后只删除本次创建的资源。
先准备清单。镜像约定在容器内监听 8080 端口，资源数值只是练习起点。requests 表达调度时使用的资源需求，并不保证应用延迟；清单里的 containerPort 是端口声明，也不会自动把应用暴露到集群外。由于本节聚焦控制路径，示例没有配置 Service。练习只确认对象、分配与启动各阶段，不把它当成生产发布方案。
apiVersion: v1
kind: Pod
metadata:
name: order-api-trace
namespace: training
spec:
restartPolicy: Always
containers:
- name: api
image: registry.example.com/training/order-api:1.0
ports:
- containerPort: 8080
resources:
requests:
cpu: 100m
memory: 128Mi将清单保存为 order-api-trace.yaml。在终端提交并观察：
kubectl auth can-i create pods -n training
kubectl apply -f order-api-trace.yaml
kubectl get pod order-api-trace -n training -w首个命令用于预查创建权限，不能替代实际请求中的准入检查。提交成功后，关注 Pod 是否出现、是否从等待转向运行。另开终端查询节点分配和事件；观察完成后可以用 Ctrl+C 结束持续查询，这不会删除 Pod。
kubectl get pod order-api-trace -n training -o wide
kubectl describe pod order-api-trace -n training
kubectl get events -n training \
--field-selector involvedObject.name=order-api-trace \
--sort-by=.metadata.creationTimestamp按证据还原过程：查询到对象，表明 API 中存在该声明；看到节点名或成功调度事件，表明位置已分配；看到镜像拉取、容器创建和启动事件，表明节点正在执行；看到容器状态，才进入运行结果。事件可能被聚合、过期或因采样时机而缺失，同名对象重建也可能混入旧事件，因此不要把事件列表当成完整审计日志。需要严格区分实例时，记录对象 UID；需要证明谁提交了操作时，再使用按策略采集的审计记录。
示例没有定义就绪探针，所以就绪状态不能证明订单接口和数据库已经通过业务检查。可以继续查看容器日志，确认进程是否按预期启动，但日志本身也不能取代实际请求验证。若实验镜像不可访问，停在拉取失败阶段同样能说明前面的对象创建和调度已经完成。清理命令如下；不要删除命名空间，以免影响其他练习资源。
kubectl logs order-api-trace -n training -c api
kubectl delete pod order-api-trace -n training5 控制面高可用与升级窗口取舍
高可用首先要说明需要保住什么能力。订单 API 的已有流量能继续，与控制面能够接受新发布，是不同的目标。多个 API Server 实例配合可用的访问入口，可以降低单个入口进程或主机故障的影响；但如果它们共用同一个脆弱入口、同一故障域或同一套不健康的状态存储，实例数量就不能直接代表整体可用性。方案应从依赖关系出发，而不是只写“控制面做多副本”。
etcd 通过多数成员参与的机制保持一致性。以常见的 3 成员部署为例，需要 2 个成员形成多数，在其他条件正常时可以容忍 1 个成员失效。失去多数后，不能指望继续正常完成依赖一致性存储的写入。增加到 4 个成员仍需要 3 个形成多数，不能比 3 成员多容忍 1 个成员故障。成员规模、故障域和通信延迟需要一起考虑，不能把副本数当成唯一旋钮。
分散故障域能够降低同时损坏的风险，却可能增加成员间通信耗时。etcd 对磁盘持久化和成员通信的表现敏感，把成员随意跨越很远的地域可能损害控制操作的响应。这里不要求记住具体延迟阈值，而是要求明确部署范围、监测基线与恢复目标。备份还应验证能否在隔离环境恢复；有多个在线成员并不能替代备份，因为错误修改也可能被正常复制。
调度器和控制器管理器可以部署多个实例，通常通过领导者选举让相应实例承担活动职责。备用实例的意义是接替故障实例，不能简单理解成实例越多、同一份协调工作就越快。真正的处理能力还受 API、存储、对象规模、队列和具体控制器行为影响。入门方案先识别活动角色、接替过程和共同依赖，不展开选举算法内部细节。
升级窗口也要分清控制面与节点。控制面升级可能暂时影响 API 操作和协调速度；节点维护可能驱逐或重建应用 Pod，直接影响可承载的业务副本。应按目标 Kubernetes 版本的兼容要求安排顺序，先检查插件和扩展兼容性，再进行分阶段升级，避免把多个故障域同时带入维护。节点排空也不是应用一定无损的保证，应用仍需足够副本、正确的就绪检查与优雅退出能力。
交互中的数字只说明维护期余量怎样变化。它把各实例视为同容量、同负载，忽略存储瓶颈和共同故障，因此不能用来采购控制面机器。真实评估应把 API 延迟、写入表现、协调积压和维护期间的业务目标放在同一时间轴上。升级成功也不能只以版本号变化验收，还要确认发布、调度、状态更新和故障恢复等基本操作在窗口后恢复正常。
6 常见坑：把 etcd 延迟当应用故障
值班时收到“订单变慢”和“发布卡住”这 2 类信号，容易把它们混成同一个问题。etcd 延迟升高可能拖慢依赖它的 API 操作，继而让控制器协调、调度和状态更新变慢；但已有业务请求通常不直接读写 etcd。反过来，订单数据库变慢也不会自动说明 Kubernetes 状态存储出了问题。先把用户看到的错误、发生时间和受影响路径写清楚，再判断它们是否有关联。
可以从业务和控制面各取一组证据。业务侧查看请求延迟、错误率、可用后端、连接情况及数据库表现；控制面侧查看 API 请求的延迟与错误，区分读写、资源类型和调用方，再查看 etcd 的磁盘写入表现、成员通信、领导者变化与相关告警。不要只看一个平均值：少量很慢的请求可能淹没在平均值里，大量正常读取也可能掩盖写入变慢。对照分位数、失败请求和时间线更有帮助。
假设订单接口延迟正常，但新 Pod 很久无法创建，API 写入也明显变慢，同时 etcd 所在机器出现存储延迟。这个组合支持优先检查控制面存储路径，却还不足以证明磁盘是唯一原因。可能还有请求量突增、机器资源争用或成员通信问题。应继续对照负载、资源和日志，确认问题开始的顺序，并检查是不是某个控制器先产生了异常写入。相关性用于缩小范围，结论仍需要多处证据。
另一种情况是 API 请求正常、Pod 已运行且就绪，订单访问却超时。此时应沿入口、Service、后端连接和数据库继续排查；如果应用动态依赖 Kubernetes API，也要把这条依赖明确画出来。架构中的常规分工不能替代对真实应用的了解。尤其要警惕监控缺口：控制面故障可能导致状态上报滞后，界面上最后一次显示的绿色并不必然代表当前健康。
恢复动作应与证据对应。确认控制请求被异常调用压满时，可以先暂停已识别的非关键调用源；确认底层磁盘或网络异常时，应按既定运维流程处理相关资源。不要因看到 etcd 这个名字就重启所有成员，也不要直接删改它的数据文件。此类动作可能扩大控制面不可用的范围。入门阶段最重要的能力是识别风险边界，保留时间线，并把调查交给有相应权限和恢复经验的人员。
最后单独核实业务影响。控制面恢复后，积压的发布和协调动作可能陆续执行，节点上的工作量也可能突然增加。先观察 API 与协调速度是否稳定，再确认副本、就绪后端与业务请求恢复情况。控制面指标回落只能证明部分条件改善；订单是否被重复提交、请求是否成功，需要应用层证据。平台恢复与业务恢复应分别记录完成时间。
7 案例：控制器风暴放大 API 压力
订单平台引入了一个自定义控制器，用于为应用补充统一标签。正常情况下，它观察目标对象，只在标签缺失或错误时写回。某次更新后，控制器每轮协调都刷新一个时间戳，即使目标配置已经满足要求也会写入；另一个辅助程序又订阅了这些对象的变化，并在收到通知后重新读取关联对象。对象数量没有明显增加，API 请求量却随着对象变化不断放大。
问题并不来自“控制器”这个角色本身，而是协调动作没有收敛。写入产生新的对象变化，变化触发观察者，观察者再读取和写入。当 API 开始变慢，调用方又立即重试，请求积压与重试相互加强。多个程序若同时恢复连接，也可能在短时间内重新列举大量对象。业务 Pod 的 CPU 仍很空闲，发布却越来越慢，说明应用资源余量不能代表控制面有余量。
调查从“谁在调用什么”开始。按调用身份、客户端、请求类型和资源类别查看 API 指标；在已启用且保留范围合适的审计记录中确认异常操作。再对照控制器日志，观察相同对象是否反复进入协调、每轮是否确实需要修改。审计也有采集成本，不宜临时无差别记录所有内容。为控制器使用独立身份和可识别的客户端信息，有助于归因；共享管理员凭据会使调查和权限收敛都更困难。
处置时先暂停被证据指向的非关键自动化，观察 API 延迟和请求量是否改善，并保留必要的原生协调能力。不能为了“停止风暴”随意关闭全部控制器，否则副本恢复等功能也会受损。暂停前还要说明它负责的功能会如何降级，例如标签补齐暂缓。控制面压力下降后，先修复产生无效写入的逻辑，再有限度恢复调用源，避免所有实例同时启动形成新的请求尖峰。
修复原则是让协调在目标已满足时停止写入，并让失败重试逐渐退让。具体做法包括比较目标字段后再更新、避免每次协调都修改无业务意义的时间字段、采用有退避和随机扰动的重试，以及限制并发和不必要的全量读取。缓存与持续观察可以减少重复拉取，但同样需要正确处理重连和状态滞后。这里理解“减少无效工作”的原则即可，不必提前实现控制器框架。
这个案例给容量估算补上了一个维度：对象总量相同，变化频率和观察者数量不同，控制面成本可能相差很大。因此验收既要看稳定运行，也要看批量发布、节点恢复、控制器重启等变化场景。增加 API Server 实例可能缓解部分入口压力，却不会自动消除无效写入，也未必缓解共享存储瓶颈。容量扩展与调用行为修复应分别有证据和验收结果。
8 把控制面容量写进集群方案
应用容量通常从请求量和单个副本的处理能力估算；控制面容量则还要考虑对象数量、对象变化速度与调用方式。相同的 300 个 Pod，持续稳定运行与反复批量重建会产生不同的管理负载。节点数量增加会带来状态与心跳相关工作，自定义资源和附加控制器也会增加读取、写入与观察活动。只按业务每秒请求数估算集群规模，会漏掉这些管理成本。
方案可以先列 4 类输入：稳定对象规模，日常发布频率，异常时可能同时恢复的节点或对象，以及外部自动化的调用方式。每项写清测量来源和不确定性，例如“当前规模来自资源清单，发布峰值来自最近 7 天记录”。不要把课堂数字直接当成集群上限。对象大小、版本、插件和部署方式都会改变表现，容量结论应附带适用条件。
再把“够用”改写成可验证的目标：常见 API 操作应在约定时间内完成，批量创建后 Pod 应在约定窗口内进入后续阶段，节点故障后替代副本应在业务能够接受的时间内恢复。这里要区分控制面等待、镜像拉取与应用启动，否则可能把大镜像下载慢误判为 API 容量不足。目标值由业务恢复要求与实际基线共同决定，而不是套用一个通用秒数。
观测面板至少覆盖 API 请求量、延迟和错误，状态存储的持久化与成员健康，控制器协调积压，以及调度等待情况。不同组件和版本暴露的指标名称可能不同，方案先定义想回答的问题，再映射实际指标。把这些数据与发布、升级和控制器重启记录对齐，才能解释一次尖峰。还应规定告警的持续窗口，避免短暂正常协调造成过多误报，同时保留异常持续时的响应路径。
验证要在隔离或受控环境中覆盖稳定运行、批量变更和维护退化。每次只改变能够解释的条件，记录对象规模、调用速率、组件版本和资源配置。测试停止条件也应明确，例如关键 API 错误持续增加或业务验证出现异常时停止加压。不能为了测“最大值”把生产控制面推到不可恢复的边缘。容量测试的目的，是为约定场景留下余量，而不是得到一个脱离条件的漂亮数字。
最后写清容量责任。谁管理控制面资源，谁批准新的集群级控制器，谁维护调用配额和重试规则，谁验证升级前后的表现，都需要有角色归属。使用托管控制面时也仍需确认提供方暴露哪些指标、允许哪些调整、故障时如何协作；责任边界不会消除工作负载行为带来的压力。将扩展触发条件写成可观察事实，才能在增长前安排变更，而不是等到发布卡住才临时加机器。
9 从Kubernetes 架构走向K8s 工作负载（C29）
回到订单 API，架构已经解释了对象如何进入集群、位置如何确定、容器如何启动，以及状态如何回到观察者。下一步是选择怎样表达长期运行的应用。直接创建 Pod 适合观察基本路径，但它没有完整表达稳定副本、版本替换和发布进度等意图。下一课将从工作负载对象出发，把这些需求交给合适的控制器，并继续沿用“声明、协调、执行、观察”的分析方法。
先把 3 层意图分开。业务意图是订单接口在可接受的延迟内处理请求；运行意图是维持所需的健康副本，并在更新时控制影响；基础条件是节点、网络、身份和数据依赖能够支持这些副本。Kubernetes 对象能表达其中部分运行要求，应用与平台仍需共同完成业务目标。把副本数写成 3，不代表数据库吞吐扩大到原来的 3 倍，也不代表每个故障域都一定有副本。
阅读下一课的清单时，可以先找期望字段，再找负责它的控制器，最后找结果证据。若副本不够，先区分 Pod 尚未创建、已经创建但未调度、已经调度但未启动，以及已经运行但未就绪。相同的“可用副本不足”可能落在不同环节，修复方式也不同。掌握架构能减少盲目修改副本数、反复重启和扩大权限等动作，让工作负载配置与故障现象形成可解释的联系。
发布还涉及状态与数据的边界。容器替换时可以重建进程，但订单记录和外部支付结果需要保持正确；平台重试与应用重试叠加时，业务必须考虑重复请求。声明式协调只说明系统会持续努力满足期望，不承诺每个业务动作只执行 1 次。工作负载课程会继续讨论运行与发布要求，本课先留下这个约束，避免把平台恢复误解为业务事务自动恢复。
可以用 3 个口头问题检查架构理解：API Server 接受创建请求后，为什么还不能宣布服务可用；Pod 已有节点名但容器没有启动时，应先找哪条证据；已有订单请求正常而新发布变慢时，为什么要分别检查业务与控制路径。回答时应说出组件职责和下一步证据，而不是只报一个组件名称。例如节点已分配后，应结合事件与 kubelet 所在节点的情况继续判断运行时、镜像或其他节点执行问题。
进入 C29 前，整理一张属于自己服务的路径图：谁提交对象，谁维持副本，Pod 怎样访问数据库，用户流量怎样到达后端，以及哪些监控能够证明每个阶段。暂时不了解的网络或存储细节可以标注为待确认，不能直接当成已具备的能力。这样选择工作负载对象时，讨论就会落在真实的运行要求上，也能把平台承诺、应用责任和后续需要验证的条件逐项对应起来。
放进方案里
为订单 API 编写集群方案时，先画出控制请求和业务请求的路径，标出 API 入口、状态存储、工作节点、应用入口与数据库。说明控制面失效时哪些能力可能暂停，哪些已有业务路径仍有条件继续运行，并列出限制条件。将控制面与节点的故障域分开记录，避免把逻辑组件多副本误写成物理故障已隔离。
明确 API Server、调度器、控制器、kubelet、容器运行时及网络和存储组件的责任。记录运维人员、自动化控制器与应用的身份及权限范围，说明镜像凭据、ServiceAccount 和数据库凭据分别用于什么。应用数据的备份与恢复另设条目，不能用 etcd 备份替代订单数据库备份。
容量部分列出对象规模、发布频率、批量恢复场景和主要调用方，并记录数据来源。用 API 延迟与错误、状态存储表现、协调积压和调度等待建立基线。扩展条件与业务恢复目标对应，保留维护期余量；实际阈值由测量确定。新增集群级控制器前，应审查其权限、写入频率、并发与失败重试行为。
升级部分写明兼容性检查、分阶段顺序、维护窗口及恢复路径。验证备份可恢复，并在受控环境演练关键组件或节点暂时不可用时的表现。验收既包含创建、调度和状态更新，也包含订单接口、数据库访问与业务错误率；分别记录控制面恢复和业务恢复时间。
交付物至少包括架构图、责任表、容量假设、监控入口和故障分流步骤。每项指定负责角色与检查时机，特别说明谁可以暂停异常自动化、谁处理状态存储故障。尚未测量的性能、插件行为和提供方限制应列为待验证条件，安排验证窗口后再形成最终承诺。
10 小结：下一步K8s 工作负载（C29）
Kubernetes 用 API 保存期望，用控制器持续协调，用调度器选择节点，再由 kubelet、运行时和相关插件执行。判断结果要从对象存在继续追到运行、就绪与业务验证；判断故障则要区分控制路径和业务路径。控制面容量取决于规模，也取决于变化和调用行为。
下一课进入 K8s 工作负载（C29）：选择表达副本、更新与任务的对象，并把本课的组件分工用于解释它们的实际行为。