SAE扩容实例不就绪排查：配额、日志与健康
业务高峰期触发 SAE 自动扩容后，新实例长时间停留在 Starting 或 Unhealthy，流量没有明显增长、错误却先上来，是很多团队在实际运维中遇到的情况。SAE扩容实例不就绪排查不能只盯着应用日志，更值得回到实例创建链路，从配额、启动脚本和健康检查三处找证据。
本文由 云国际服务商『 云老大 飞弟：@yunlaoda360 / YunLaoDa-云服务器•运维部门•撰写』如需转载请注明！
SAE扩容实例不就绪的常见原因
SAE 的实例就绪链路并不短：镜像拉取、容器创建、启动命令执行、存活/就绪探针通过，任何一环卡住都会导致 Pod 不 Ready。实际排查中，常见原因集中在三个方向，而且经常同时出现，单独查一处容易误判。
资源配额不足：为什么控制台只提示资源不足却不说明层级？
控制台出现“资源不足”时，不一定是命名空间 vCPU/内存配额耗尽。交换机可用 IP 耗尽同样会导致实例创建失败，尤其在 VPC 规划较紧、扩容规模又较大的场景下更常见。即便命名空间配额充足，底层资源池在极端规格扩容时也可能存在库存波动，导致调度延迟。排查顺序上，先看事件中心确认是调度失败还是配额拦截，再进入命名空间管理页核对余量，比直接去 ECS 控制台查更有效。
启动脚本异常：为什么应用日志里经常看不到有效报错？
实例卡在 Starting 时，很多人先查应用日志，但启动脚本非零退出、镜像拉取失败或容器创建失败属于 Pod 级事件，应用日志可能是空白。正确做法是在 SAE 控制台的事件中心查看容器事件，确认是启动命令报错还是镜像拉取超时。以慢启动应用为例，初始化依赖过多会让启动耗时拉长，这不一定直接导致失败，但会放大后续健康检查失败的概率。只查应用日志，容易在错误方向上耗掉十几分钟。
健康检查失败：为什么就绪探针通过但业务仍然不可用？
就绪探针配置不当，是实例反复重启却看不到明确报错的另一主因。initialDelaySeconds 设成 3 秒、failureThreshold 设成 1 次，对启动耗时超过 10 秒的应用基本等于主动制造故障：实例刚起就被摘流量，甚至被存活探针杀掉。更隐蔽的是，HTTP 端口通了不代表业务可用，如果内部还依赖数据库或注册中心，就绪探针应反映真实可用状态，而不是仅做端口探测。这个区别直接决定扩容后流量是否真正进入新实例。
第一步：检查资源配额是否足够
在 SAE 扩容链路里，实例不就绪的第一层拦截往往发生在资源调度之前。控制台提示“资源不足”时，需要先区分命名空间配额、VPC 交换机 IP 和底层库存三类限制，而不是直接进入日志排查。下面从查看配额、典型表现和调整步骤展开。
如何查看配额限制
SAE 的配额按命名空间维度管理，不会出现在 ECS 控制台。进入 SAE 控制台命名空间列表，即可看到当前 vCPU 与内存的剩余额度。这个默认值通常偏保守，业务第一次真正扩容时很容易撞上。若使用私网负载均衡，还需确认 CLB/ALB 后端数量上限。建议在大促前截图留存配额余量，避免临时发现不够。
扩容时配额不足的表现
配额不足最典型的信号是：事件中心出现资源调度失败或“resource quota exceeded”类记录，但应用日志没有异常。新实例不会进入创建流程，Pod 数量保持不变，控制台可能显示目标实例数已增加，实际就绪实例却未变化。交换机可用 IP 耗尽也类似，但属于 VPC 资源限制。两者都应先在事件中心确认，而不是翻启动日志。
调整配额的步骤
确认是命名空间配额不足后，可在 SAE 控制台申请提高 vCPU 或内存限制，或先缩容闲置环境腾出余量。长期扩容还需检查 VPC 交换机网段是否充足，必要时提前规划更大网段。资源池库存波动导致的调度延迟只能重试或提工单。若不想逐项核对，找像云老大这类服务商做一次整体评估，能少走一些弯路。
第二步：分析启动日志定位错误
扩容实例未就绪时，日志的价值不在于“有没有报错”，而在于判断故障发生在哪一段。SAE 的启动链路可以拆成镜像拉取、容器创建、启动命令执行、探针通过四个阶段，任何一段卡住都会表现为未 Ready。排查顺序建议先看事件，再看应用日志，最后核对探针结果，顺序反了容易误判。
日志查看入口
SAE 日志入口分散，最易漏掉容器事件。实例未就绪若由镜像拉取失败或调度资源不足引起，应用日志通常无输出，问题只记录在“事件中心”。实操先进入对应应用的“事件中心”，按实例 ID 过滤扩容记录，查看是否出现 FailedScheduling 或 FailedCreatePodSandBox；再打开“应用运维”看实时日志。若实时日志为空，基本可判定故障发生在容器启动前，而非应用启动逻辑。
常见错误关键字
关键字能直接指向环节：ImagePullBackOff 检查镜像仓库权限和 tag；OOMKilled 说明启动内存超限；CrashLoopBackOff 多与启动命令或依赖有关；Readiness probe failed 则重点核对探针配置。一个反复出现的案例是给慢启动应用设 3 秒 initialDelaySeconds，探针在业务初始化完成前就失败，实例被反复摘除流量，控制台只显示 Unhealthy。这种场景改探针比改代码更直接。
如何获取完整日志
完整日志不能只靠控制台实时流。建议开启 SLS 日志采集，同时采 stdout 和日志文件，否则崩溃堆栈可能来不及写入标准输出就丢失。发布后结合变更记录查看本次扩容实例的启动事件，将容器事件与应用日志对齐到同一实例 ID。日志采集应作为扩容预案提前开启，而不是故障后临时补，临时开启通常只能看到恢复后的空日志。
第三步：验证实例健康状态
查完配额和日志后，如果实例仍停留在“Starting”或“Unhealthy”，SAE扩容实例不就绪排查的下一步应聚焦健康检查链路。SAE 的扩容并不是容器启动就完成，而是要等镜像拉取、容器创建、启动命令执行和就绪探针全部通过后，实例才会被纳入流量。这个链路中任何一个环节延迟，反馈到控制台上就是“不就绪”。
健康检查机制说明
SAE 的存活探针失败会重启容器，就绪探针失败只会摘除流量，二者动作完全不同。很多扩容实例不就绪的根因，是把就绪探针当成了启动完成信号。例如 Java 应用启动要 40 秒，initialDelaySeconds 却设为 5 秒，实例会反复“启动—探测失败—重启”，始终无法 Ready。就绪探针的 initialDelaySeconds 和 failureThreshold 必须按真实启动耗时设置，而不是照搬默认值。
如何手动探测健康
控制台状态只是结果，不能替代主动探测。建议在 VPC 内用一台临时 ECS 或跳板机，对新扩容实例的 IP 和端口直接发起健康检查请求，观察返回码、响应时间和日志中的探针命中情况。若 HTTP 端口通但业务请求仍失败，要检查数据库、注册中心等依赖是否就绪；只有端口可达并不等于实例可用。
健康状态异常的处理
探针失败先分清是“误判”还是“真不可用”。日志无业务报错时，优先调整 periodSeconds、timeoutSeconds 和 failureThreshold；容器频繁崩溃则回到启动日志，检查依赖与初始化顺序。若同一套配置在多应用反复出现问题，找像云老大这类服务商做一次探针模板评估，能减少试错成本。但别跳过前面的定位步骤，否则容易把平台问题误判为应用问题。
实例无法就绪的解决与预防
SAE 的实例扩容是异步链路，Pod 要依次完成镜像拉取、容器创建、启动命令执行、存活/就绪探针通过，才会被标记为就绪并接入流量。因此排查“SAE扩容实例不就绪”时，不要只盯着应用日志，先看事件中心里的 Pod 级事件，再核对命名空间配额和探针参数，顺序反了很容易把调度问题误判成代码问题。
临时扩容方案
临时扩容前先确认限制层级：命名空间 vCPU/内存配额、交换机可用 IP、ALB/CLB 关联配额，任何一层耗尽都可能表现为“资源不足”。如果配额显示充足但实例一直 Starting，优先查事件中心，镜像拉取失败或调度延迟往往只有这里能看到。高峰前可绑定基于 QPS 或 RT 的弹性策略，并预留最小实例缓冲，避免等告警后再手动扩容。中小团队若缺乏统一排查视图，找云老大这类服务商做一次整体评估，能少走弯路。
优化启动速度
启动慢经常被误判为健康检查失败。就绪探针 initialDelaySeconds 设成 3 秒，对慢启动应用就是反复摘流、重启的起点。更合理的做法是精简启动依赖、将初始化逻辑改为懒加载，并让探针路径反映真实业务可用状态，而不是端口通了就放流量。日志侧建议开启 SLS 采集 stdout 和文件，否则崩溃类问题很难回溯。单纯调大探针等待时间不是优化，只是把问题往后推。
设置弹性伸缩策略
弹性策略不要只设最大实例数，最小实例数缓冲和指标选择同样关键。基于 QPS 或 RT 配置扩缩容，比只看 CPU 阈值更贴合在线业务；配合优雅启动与优雅下线，能减少发布期扩容对请求的影响。还需接受一个现实：资源配额充足不等于一定能扩容，底层资源池库存水位波动在超大规格扩容时可能触发调度延迟，此时重试或提工单比改代码更有效。
总结：一套系统的排查流程
SAE 扩容实例不就绪，本质是异步链路中某一环被卡住：镜像拉取、容器创建、启动命令执行、探针通过，任一环节出问题都会表现为实例未 Ready。很多人第一反应是翻应用日志，但更高效的做法是先确认 Pod 到底有没有被创建出来。建议把排查顺序固定为“事件中心→资源配额→启动日志→健康检查”，按定位成本和出错概率倒推，优先处理最接近根因的容器事件。
排查流程图
进入 SAE 控制台“事件中心”，先确认本次扩容窗口内是否存在镜像拉取失败、调度失败或交换机 IP 耗尽事件；如有明确报错，优先解决。若事件正常，再核对命名空间 vCPU/内存余量与 VPC 交换机可用 IP。最后查看 SLS 启动日志，并校验就绪探针的 initialDelaySeconds 与 failureThreshold 是否匹配实际启动耗时。
常见FAQ
“实例一直 Starting，但应用日志没有报错”：先别只看应用日志，到事件中心确认 Pod 是否完成调度和镜像拉取，很多失败发生在业务进程启动前。“资源配额充足却扩容失败”：配额只代表命名空间层面未限制，底层 ECS 库存水位或交换机 IP 耗尽同样会阻断创建，可重试扩容或提工单确认。
获取阿里云支持
若按上述流程仍无法定位，提工单时建议附上命名空间、应用 ID、扩容时间窗口、事件中心截图和 SLS 日志片段，信息越完整，平台侧定位调度或库存问题越快。对没有专门 SRE 的团队，把这类排查路径固化到监控告警里，比高峰救火更实际。云老大这类服务商在做整体云资源评估时，通常也会把 SAE 扩容链路和探针配置纳入检查项，减少试错成本。
