启动慢的应用被反复重启，或者已失去处理能力的实例仍在接流量，常常与探针职责混淆有关。探针不是统一的“活着吗”接口，而是平台做不同决策的依据。
启动阶段需要合理等待
初始化较慢时，应根据实际启动过程设计 startup probe，而不是无限放宽所有运行期检查。启动成功之后的故障检测目标不同，不能让初始化容忍度永久降低运行期敏感度。
存活与就绪分别驱动行为
存活检查失败可能触发重启，就绪失败会影响接收流量。共享数据库短暂故障时，重启全部应用可能扩大连接压力。检查中包含哪些依赖，应依据应用恢复行为决定。
探针接口保持轻量且可解释
不要执行写入业务或大查询，也不要返回包含秘密的诊断信息。对失败原因保留受控日志与指标，帮助区分端口、初始化、依赖和应用状态问题。
用受控故障验证平台动作
覆盖启动延迟、应用无响应和依赖中断，观察重启、摘流与恢复是否符合预期。验收还需检查多副本同时异常时的整体行为，而非只测试单个 Pod。
常见问题：配好探针就能保证零停机吗？
不能。容量、版本兼容、停止过程和依赖可用性同样影响发布与故障期间的业务表现。
技术参考：Kubernetes：应用探针。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
如果你的 .NET 应用还缺少可重复的部署、观察或恢复流程，可以通过容器化与自动化交付服务梳理现状，约定实施内容、演练场景与运维交接方式。