1 大规模 Kubernetes 要关注什么
订单服务从 20 个 Pod 扩到 200 个时，团队通常先检查机器是否够用。扩到更多业务、更多团队之后，问题会变成：发布为何变慢，新增 Pod 为何排队，某个团队反复修改配置为何影响其他团队。节点数量只是规模的外观。真正要管理的是对象数量、对象变化速度，以及故障需要影响多大范围。
可以把 Kubernetes 想成 1 个持续工作的协调系统。使用者提交期望，控制面记录期望并安排工作，节点运行容器、报告状态。这里的控制面包括 API Server、调度器和控制器等组件；etcd 保存集群需要持久化的状态。应用请求走的网络与容器执行路径属于数据面。已经运行的订单 API，通常不需要每处理 1 笔订单就访问 Kubernetes API。
这种分工解释了常见现象：控制面出现问题时，已有容器可能继续处理订单，但新版本无法部署，故障副本无法及时替换，扩容也可能停止。于是“接口还能访问”不能证明集群健康，“部署失败”也不等于所有订单请求已经中断。平台需要分别观察应用服务能力与集群协调能力，才能判断应急措施的优先级。
描述规模时，应至少保留 4 个维度。存量包括节点、Pod、Secret、自定义资源等对象；变化包括发布、自动扩缩容和状态更新；读取包括控制台、监控组件及控制器的查询与监听；恢复则关注故障后多久能重新安排工作。相同的 Pod 数量，稳定运行的订单 API 与不断创建短任务的批处理平台，对控制面的压力可能很不相同。
一个实用起点是写出业务情境：订单 API 有 60 个副本，每天发布 8 次；后台任务会在整点集中启动；节点故障时要求在约定时间内补齐副本。这些数字不是容量结论，而是负载模型。还应说明身份认证来自哪里、服务如何被访问、订单数据存在哪里、告警由谁接收。否则只测到 Pod 能创建，仍无法证明服务可以正常交付。
规模规划最终要回答 3 个问题：平时是否有余量，突发时是否能保持关键操作，恢复时是否会进一步放大负载。本课用订单 API 串起这些问题，不追求某个通用的“最大节点数”。公开限制可以作为检查起点，真正的边界仍要结合 Kubernetes 版本、扩展组件、机器配置和自己的业务负载来验证。
2 控制面容量与 etcd
先看 1 次发布。客户端把 Deployment 的新配置交给 API Server，请求经过身份认证、权限检查、准入处理和数据校验，成功后持久化。控制器观察到期望变化，创建相应的工作对象；调度器为尚未分配节点的 Pod 选择位置；节点上的 kubelet 启动容器并上报状态。这些动作互相衔接，但不是客户端请求中同步执行完的 1 段程序。
这条路径上，每段都有自己的容量约束。API Server 要处理并发请求、序列化对象并执行准入逻辑；外部准入服务响应变慢，也会拖住发布。调度器需要评估节点是否满足资源和放置约束；控制器需要在队列中处理变化。只增加 API Server 实例，无法自动修复缓慢的准入服务，也无法让已经饱和的状态存储恢复写入能力。
etcd 可以理解为保存集群关键状态的数据库。它保存 Pod 定义、配置及相关元数据等内容，不负责保存订单数据库中的业务记录，也不是容器日志仓库。把大段业务文档、频繁变化的报表或大体积结果塞进 Kubernetes 对象，会同时增加存储、传输、缓存和处理负担。对象看起来只是配置文件，规模扩大后仍然有真实成本。
etcd 的写入需要可靠落盘，并在成员之间形成一致的结果。因此低延迟、稳定的磁盘与成员间网络很重要。常见部署使用 3 个或 5 个成员提高容错能力，但成员数增加并不等于写入吞吐按比例增加。入门阶段只需记住：它需要多数成员可用，不能把增加成员当作简单的扩容按钮；一致性协议的内部过程留到后续课程。
还要区分主机文件系统空间、etcd 后端数据库大小与数据库配额。它们相关，却不是同 1 个指标。主机磁盘可能被其他文件占满；数据库也可能先达到自身配额。历史版本清理与空间整理各有作用，不能把“删除了对象”直接理解为“主机已经释放相同大小的空间”。维护命令必须按当前版本的官方流程执行，并安排容量和恢复余量。
对规模更有用的指标包括请求速率、请求错误比例、API 延迟分布、正在处理的请求、控制器队列、调度等待，以及 etcd 提交和磁盘写入延迟。延迟要看 p95、p99 等分位数，避免平均值掩盖少量严重等待；也要记录统计窗口和请求类型。读取小对象的延迟，不能替代大批量发布时的写入体验。
备份属于容量方案的一部分。快照应安全存放在集群外，并定期验证恢复步骤、凭据和所需时间。能够生成快照，并不证明能在故障现场恢复服务。恢复通常涉及隔离故障环境、核对版本、重建状态与重新接入业务，必须预先演练。不要等到磁盘只剩很少空间，才第一次研究备份文件是否可用。
3 多集群与联邦边界
当单个集群的协调能力、故障影响或组织边界无法满足要求时，多集群会成为合理选择。订单平台可以把生产与实验环境分开，把不同地域的业务分别部署，也可以让要求较强隔离的团队使用独立集群。切分依据应来自故障域、数据位置、合规要求和运维责任，而不是看到节点增加就立刻复制 1 套集群。
单集群的优势是资源池集中、服务发现直接、管理入口较少。多集群缩小了某些故障的影响，却引入版本、配置、身份和流量治理的重复工作。例如同名 Namespace 并不表示同 1 个租户身份，同名 Service 也不会自动跨集群发现。集群数量增加后，平台需要能清楚回答“这次操作会作用于哪个集群”。
身份方面，人的登录可以统一接入身份系统，但每个集群仍应独立授予最小权限。自动化程序应有明确的服务身份与凭据轮换方式。用于测试集群的流水线权限，不应因为入口统一就自然扩展到所有生产集群。操作记录还要带上集群、环境和操作者，使审计能够还原真正的影响范围。
网络方面，Pod 地址与 Service 地址通常只在约定范围内有意义。跨集群访问需要设计名称解析、入口、路由、加密和访问控制。复制 Deployment 不会自动得到跨地域服务发现，也不会消除网络延迟。对于订单 API，可以先用明确的服务入口连接其他集群的能力，避免把所有 Pod 网络强行连成 1 个没有边界的大平面。
数据方面，计算副本可以重新创建，订单记录不能随意重复或丢失。多集群部署必须说明哪些实例写同 1 个数据库、写入权限怎样转移、数据复制有多大延迟。把无状态服务发布到另 1 个集群，只解决了部分恢复问题。如果订单数据库仍在原故障域，应用切换后也可能无法接单；跨地域写入还可能引入额外延迟和一致性取舍。
“联邦”在这里指跨集群分发或协调资源的管理能力，不代表各集群自动合成 1 个透明系统。不同工具对资源分发、状态汇总和故障切换的支持不同。应明确其边界：它是否只复制配置，是否负责流量迁移，是否管理数据恢复。不要因为有统一控制台，就假设网络、身份与数据语义也已经统一。
适合入门平台的做法是先统一模板、版本基线、监控和交付记录，再根据明确需求增加跨集群自动化。切分后要重新压测故障切换：备用集群是否有容量，镜像是否可拉取，入口是否能改向，数据是否满足恢复要求。多集群提供新的组织方式，并不会免除容量验证，只是把验证范围扩展到了边界之间。
4 动手：压测一次 API 与调度延迟
本实验的目标是建立可解释的测量方法。它从 12 个轻量 Pod 开始，只在获准使用的独立测试集群执行。这个起点是小规模探针，不能据此宣称完成大规模容量认证。先确认当前上下文、节点余量、可用监控和清理权限；测试期间保留观察窗口，并约定停止条件。不要把生产集群当作寻找极限的试验场。
先画清 3 段时间。API 请求耗时从客户端发出请求到收到响应；调度等待从 Pod 创建后进入待调度状态到获得节点；容器就绪还包含镜像拉取、启动和探针等待。客户端命令结束时刻只是可观察的边界。尤其 Deployment 创建成功，仅说明这个对象已被接受，后续 Pod 创建和调度仍是异步动作。
先检查目标并建立专用命名空间。以下命令中的配置读取仅用于确认实验环境，不要把含敏感信息的完整配置贴进报告。
kubectl config current-context
kubectl get nodes
kubectl create namespace c48-scale-lab
time kubectl get namespace c48-scale-lab -o name把下面的清单保存为 scale-probe.yaml。选择环境允许且能拉取的轻量镜像；示例镜像用于保持容器运行，不承载订单业务。requests 声明调度所需资源，limits 限制容器可使用的资源。这里的数值只服务于小实验，不代表真实订单服务的配置建议。
apiVersion: apps/v1
kind: Deployment
metadata:
name: scale-probe
namespace: c48-scale-lab
spec:
replicas: 12
selector:
matchLabels:
app: scale-probe
template:
metadata:
labels:
app: scale-probe
spec:
containers:
- name: probe
image: registry.k8s.io/pause:3.10
resources:
requests:
cpu: 10m
memory: 16Mi
limits:
cpu: 100m
memory: 64Mi先做服务端试运行，再正式提交。试运行会经过服务端校验及适用的准入处理，但不持久化资源，不能代表 etcd 写入性能。正式应用的耗时则混合了客户端、网络和服务端处理时间，也不是纯 API Server 延迟。报告应如实写出测量边界，避免把几个不同指标命名成同 1 个“发布延迟”。
time kubectl apply --dry-run=server -f scale-probe.yaml
time kubectl apply -f scale-probe.yaml
kubectl get pods -n c48-scale-lab -l app=scale-probe -w观察到 12 个 Pod 对象都已创建后，退出持续观察，再等待调度条件。若过早执行等待命令，可能因为控制器尚未创建对象而提示没有匹配资源。这是异步流程的正常现象，不应通过无限重试掩盖。下面的等待耗时只是从命令开始到所选 Pod 满足条件的剩余时间，并非每个 Pod 从创建起的完整调度延迟。
time kubectl wait -n c48-scale-lab pod -l app=scale-probe \
--for=condition=PodScheduled --timeout=120s
kubectl get pods -n c48-scale-lab -l app=scale-probe -o wide
kubectl get events -n c48-scale-lab --sort-by=.metadata.creationTimestamp完整调度观察应结合 Pod 的创建时间、PodScheduled 条件与调度器指标；条件时间只能提供粗粒度线索。使用监控中的调度耗时分布时，应核对当前版本的指标定义和标签。Pending 也不必然表示调度器太慢：资源不足、配额、污点或放置约束，都可能使 Pod 暂时没有可用节点。先看事件解释，再判断是否存在性能瓶颈。
采集基线后，只改变 1 个因素，例如在剩余容量允许时把副本改成 24，再比较相同窗口的请求量、错误率、延迟与节点资源。每档恢复到稳定状态再继续，记录首次拉镜像等干扰。若 API 出现持续错误、etcd 存储告警或达到事先约定的延迟门槛，立即停止加压并保存证据。实验结束后执行 kubectl delete namespace c48-scale-lab，观察删除产生的回收负载，确认资源释放。
5 密度与隔离取舍
节点密度指每个节点承载的工作量。提高密度能够减少闲置，却会增加共享资源竞争，并放大单节点故障时需要迁移的副本数量。对于订单服务，关心的不是“还能塞进几个 Pod”，而是流量高峰时延迟是否稳定，以及失去 1 个节点后是否仍有位置容纳替代副本。装得下与恢复得了，是不同的容量要求。
调度器通常依据 requests 判断资源是否足够，并不会把当前低使用率当作长期保证。若 requests 普遍偏小，调度结果看似宽松，业务高峰却可能同时争抢 CPU 或内存。内存不足可能导致容器被终止，CPU 受限可能使响应变慢。requests 应来自测量与业务目标，limits 也要结合应用行为设置，不能只为提高表面利用率而统一压低。
隔离有不同层次。Namespace 方便按团队组织资源，但它本身不构成完整的安全隔离。需要结合 RBAC 控制操作权限，以 ResourceQuota 约束对象或资源总量，以 LimitRange 提供合理的默认值和边界，并通过合适的网络策略限制通信。网络策略还依赖所选网络实现的支持与正确配置，写下策略文件不等于已经验证阻断效果。
节点池和独立集群可以提供更清晰的放置或故障边界，也会增加保留容量和管理成本。把订单 API 与突发批处理分到不同节点池，可能减少资源干扰，但仍共用控制面。若批处理反复创建大量对象，订单服务的发布仍可能受到影响。因此计算隔离与控制面隔离需要分别说明，不能用同 1 个“已隔离”覆盖所有风险。
例如 6 个节点各提供 16 核可分配 CPU，总计 96 核。若已请求资源达到 84 核，失去 1 个节点后只剩 80 核，单从总量看就无法完整承接原有请求。实际还要考虑内存、系统预留、Pod 数量上限、卷挂载和放置限制。即使总量足够，剩余资源也可能分散在不满足条件的节点上，形成无法利用的碎片。
副本分散可以降低单节点故障的冲击，但过严的放置规则也可能让扩容无处可去。应根据服务目标选择跨节点或跨可用区分散，并验证资源紧张时的表现。密度方案要同时给出正常水位、故障水位和扩容耗时。只有在约定故障场景下仍能恢复，节约出来的机器成本才有明确的服务保障基础。
6 常见坑：单集群无限扩节点
最容易形成的误判是“Pending 增加，所以继续加节点”。如果原因确实是计算资源不足，这可能有效；如果原因是配额、存储约束、调度规则或控制面拥塞，加节点就未必有帮助。新增节点还会带来注册、心跳、状态更新与监控目标，增加对象和通信数量。机器变多与协调能力变强，并不存在自动对应关系。
另 1 个误区是只盯着平稳状态。平时每分钟创建的 Pod 很少，发布时却可能集中替换大量副本；节点维护与自动扩容也可能撞在同 1 个窗口。每个动作单独看都合理，叠加后却超出平台验证过的变化速率。容量计划必须包含发布、维护和故障恢复的组合负载，不能只拿日常平均曲线证明安全。
查询方式也会放大问题。很多脚本不断列出全部命名空间的全部 Pod，再在本地筛选，即使脚本只关心很小范围，也会制造较多读取与传输。合理利用作用域、标签选择、分页和官方客户端的监听机制，可以减少重复全量读取。但监听也占用连接与处理资源，不能简单把所有轮询替换成无限量监听后就停止测量。
重试是另 1 个放大器。API 延迟升高后，客户端若立即重试，原始请求还未完成，新请求又到达，控制面会承受更大压力。应设置合理超时、有限重试、退避和随机抖动；检查操作是否可安全重复，避免重复创建业务动作。自动化系统尤其要有并发上限，并优先保留告警、诊断和必要恢复操作的访问能力。
扩展组件也需要纳入预算。准入服务、网络插件、存储控制器、日志采集和自定义控制器都可能成为规模链条的一部分。新装 1 个会监听大量资源的组件，等于新增持续读取者；为每次对象修改调用外部服务，等于在变更路径上增加依赖。组件升级与策略变化后，应重新验证关键场景，而不是沿用很久以前的容量报告。
当单集群逼近已经验证的边界时，先限制突发变更、修复低效客户端、调整已确认的瓶颈，再评估拆分。拆分也有代价，不能替代故障定位。合理的结论可能是继续使用单集群，也可能是按环境或地域分开；共同要求是给出证据、故障范围和下一次复测的触发条件，而不是承诺节点可以无限增加。
7 案例：etcd 磁盘打满集群失控
某订单平台的测试与生产任务共用集群。团队新增了短任务控制器，持续创建自定义资源，完成后也没有及时回收。etcd 所在磁盘又缺少足够余量，存储增长告警无人跟进。早高峰发布时，API 写入开始报错，新增 Pod 迟迟没有出现。已有订单 API 仍在运行，因此入口成功率短时间内没有明显下降，故障最初被误认为只是流水线异常。
这个案例首先要拆开“磁盘满”的含义。可能是主机文件系统耗尽，也可能是 etcd 数据库达到配额。前者要检查磁盘空间和文件来源，后者要核对数据库大小与存储告警；若发生写入失败，还要看实际错误。不能仅凭发布页面显示超时，就直接执行数据库维护。错误分类决定了处置路径，表面相似的症状可能需要不同措施。
值班人员先暂停新的批量发布与任务创建，限制非必要自动化重试，保留现有订单副本，避免制造更多变更。随后分别检查应用请求、API 读写、节点状态与存储指标。若运行节点仍健康，贸然重启全部节点会把可以继续服务的容器也卷入故障。此时优先目标是稳定服务并恢复协调能力，而不是追求所有面板立刻变绿。
证据显示该次事故的直接原因是主机文件系统空间耗尽，数据库增长是主要来源。处置人员核对了成员健康、存储挂载与可用快照，并按预案选择受支持的扩容路径。对有用数据的删除必须有明确范围和授权；etcd 数据目录中的日志、快照或数据库文件，不能当作普通临时文件随意清理。手工删错文件可能把容量事故升级成数据恢复事故。
若遇到的是数据库配额告警，扩主机磁盘本身未必解除问题。需要按当前版本与部署方式的流程控制对象增长、处理不再需要的数据，并在合适条件下完成历史压缩、空间整理及告警处理。这些操作有顺序、成员与可用性要求，应由熟悉流程的人员执行。恢复快照也不是清空间的通用动作，它可能使状态回退，必须明确接受的损失与恢复目标。
恢复后，团队先用少量、可回收的写入检查 API，再验证新 Pod 创建与调度，最后逐步放开发布和任务并发。同时观察 etcd 写入延迟、成员健康、存储增长与订单成功率。只看到读取恢复或告警消失，还不足以证明恢复完成；控制器可能积压大量工作，重新放开流量后仍会产生 1 次变化洪峰。
复盘的改进包括为任务对象设置生命周期、对创建速率和存量设限、给存储增长设置有负责人的预警，并演练容量耗尽后的恢复步骤。事故损失还应包含补副本延迟与发布冻结时间，而不只统计订单接口中断时长。这样才能把“已有容器还能跑”的幸运，转化为可持续的规模管理能力。
8 把规模上限写进平台方案
平台方案中的规模上限应是一份带条件的承诺。例如“在指定版本、组件与机器配置下，支持约定数量的节点和对象，并在约定变更速率下满足延迟目标”。缺少条件的单个 Pod 数字，很难指导扩容，也无法帮助事故时做决定。上限至少要同时描述存量、变化速率、控制面表现和故障恢复能力。
先建立资源清单，记录节点数、各类对象数、常见对象大小、命名空间数量与活跃客户端。再列出典型动作：日常发布、整点任务、节点维护、失去节点后的补副本，以及集群切换。每个场景写明输入规模、持续时间与观测指标。这样测试的是平台真实需要完成的工作，而不是只有漂亮数值、业务却无法复用的极限实验。
把服务目标转化为可测条件。例如订单 API 的发布应在业务约定的时间内完成，同时错误率保持在可接受范围；调度目标只对资源与放置条件满足的 Pod 统计，资源不足的情况另行报告。API 延迟要写明请求类型与统计窗口，恢复时间要写明起止事件。条件清楚后，团队之间才不会拿不同口径互相证明“没有问题”。
容量水位应留出故障和增长余量，而不是让所有资源长期贴着已测上限运行。预警线、停止加压线与必须扩容或拆分的触发线应各有用途。某次测试达到的最高点，只能说明该条件下的观察结果，不自动成为长期运行目标。还要说明新增节点、扩展存储或启用备用集群分别需要多久，避免把无法及时交付的资源算作现成余量。
多租户平台还需要分配变化预算。除了限制 CPU、内存和对象数量，还应控制批量发布与任务创建并发，让单个团队的自动化失误不容易占满协调路径。配额不能替代所有速率控制，客户端限速也不能代替容量监控。方案应说明各层约束由谁实现、在哪里观察效果，以及业务遇到限制时如何申请调整。
备份、恢复与维护责任需要写成可执行约定：谁处理 etcd 容量告警，谁决定暂停发布，谁确认备用集群的数据状态，恢复后由谁批准逐步放开并发。这里的批准是平台内部的运行职责，不应只留下“联系管理员”这样的空话。值班入口、操作记录与演练周期都应有实际负责人，避免故障发生时临时拼凑权限。
最后写明复测触发条件。Kubernetes 升级、网络或存储组件变更、新增准入逻辑、大量自定义资源接入，以及业务变化速率明显增加，都可能使原来的测试失效。容量报告应注明日期、环境和限制。规模上限不是永久标签，而是目前证据所支持的运行范围；平台的任务是持续维护这个范围，并提前安排下一次验证。
9 从大规模 Kubernetes走向K8s 内核（C49）
大规模 Kubernetes 的核心认识是：它持续协调期望与现实，任何变化都需要经过有限的处理能力。节点负责运行工作，控制面负责记录和协调工作；资源存量与变化速率共同决定压力。读到这里，应能解释为何机器仍有余量而发布变慢，也能解释为何控制面短暂失效时，已有容器可能继续提供部分服务。
接下来学习 K8s 内核，会把本课看到的现象接到更具体的内部机制：对象变化怎样被观察，控制器为何反复检查状态，调度工作如何进入处理流程。现在不必背下内部队列、缓存或一致性算法的细节。先保留外部证据与清楚的问题，后续学习才知道每个机制是在解决哪种实际约束，而不会把组件名称当作答案。
可以带着本课的实验记录进入 C49。若 Deployment 已创建而 Pod 尚未出现，应追踪哪个控制过程还没完成；若 Pod 已出现却未分配节点，应先判断条件不满足还是处理变慢；若节点已分配而容器未就绪，则继续看镜像、存储、网络与应用启动。沿着对象状态逐段缩小范围，比把所有等待统一称为“Kubernetes 慢”更有帮助。
还有 1 条值得保留的边界：Kubernetes 能帮助运行数据库容器、挂载存储与组织恢复动作，但业务数据的正确性仍要由数据库和应用设计保证。多集群、更多副本和更快调度，都不能自动解决重复扣款、订单丢失或跨地域写入冲突。平台能力应与应用责任对齐，避免把扩容能力误当作业务正确性的证明。
检验自己是否理解，可以尝试向同事说明 3 件事：这个服务的规模由哪些维度描述；控制面慢时先看哪些证据；当前集群何时必须扩容、限流或拆分。若回答只能给出节点总数，说明方案还缺少变化和恢复视角。若能同时说明测量口径、故障边界和下一步动作，就已经具备继续理解 K8s 内部工作方式的基础。
放进方案里
为订单平台写规模承诺时，先标明 Kubernetes 版本、网络与存储组件、控制面配置、etcd 部署方式及测试日期。规模表同时记录节点、Pod、主要对象存量、对象增长趋势，以及发布和任务创建速率。每个上限都附上适用负载与保留余量，避免把某次实验的最高结果直接写成日常运行额度。
把验收写成业务动作：在约定并发下完成订单 API 发布，模拟失去 1 个节点后补齐副本，并在整个窗口观察订单成功率。分别记录 API 请求延迟、调度等待、容器就绪和恢复耗时，注明起止事件与统计口径。资源不足、放置约束不满足和控制面处理缓慢应分别归因，不能混成同 1 个延迟数字。
再写身份、网络与数据边界。每个集群明确管理员和自动化身份、入口路由、允许的跨集群访问，以及订单数据库的写入位置。若采用多集群，说明配置由谁分发、流量由谁切换、数据复制延迟如何影响恢复。统一入口只代表管理方式统一，服务切换能力仍需单独验证。
运行约定必须给出存储增长预警、API 错误和调度积压的处置人，以及暂停发布、限制重试和恢复并发的条件。快照应离开原故障域保存，并用演练确认可恢复。磁盘耗尽、数据库配额触发与成员故障采用各自的受控流程，禁止把删除 etcd 数据文件当作清理空间手段。
最后列明容量调整与复测条件：接近预警水位时先核查负载来源，再决定扩容、限速或拆分；版本升级、准入逻辑变化及新控制器接入后重新验证。交付物应包含负载模型、监控看板、实验记录、恢复预案和责任表，使下一位值班人员能够依据证据行动，而不必猜测当初的容量承诺。
10 小结：下一步K8s 内核（C49）
规模来自对象存量、变化速率与恢复要求的共同作用。控制面和 etcd 有自己的容量边界；多集群增加了故障隔离，也带来身份、网络和数据协作成本。密度优化必须保留故障余量，压测必须区分 API 接受、调度完成与容器就绪。
进入 C49 前，保留本课的流程图与测量口径。下一步围绕对象变化、控制循环和调度路径理解 K8s 内部机制，把“看见等待”推进到“解释等待发生在哪里”。