如何让AKS中托管的ASP.NET Core Web API保持运行避免冷启动闲置问题

你观测到的是典型的ASP.NET Core应用冷启动+进程闲置资源回收现象：应用长期无请求时，要么AKS自动扩缩容机制把Pod副本数缩到0，要么ASP.NET Core运行时会卸载非核心JIT编译代码、释放闲置的连接池/内存资源，首次请求需要重新完成代码编译、依赖初始化、资源加载等操作，因此耗时大幅升高，后续请求因为资源已初始化就会回落至正常水平。

仅配置liveness探针无法覆盖所有场景，不能完全解决问题：

• 如果你的集群没有配置自动缩容到0，Pod一直处于运行状态，定期调用的liveness探针确实可以保持应用进程活跃，避免运行时回收闲置资源，缓解闲置后的首次请求延迟问题。
• 如果你配置了HPA/KEDA等自动扩缩容规则，允许无请求时副本数缩到0，那没有运行中的Pod时liveness探针根本不会触发，还是会出现Pod级别的冷启动。
• 额外注意：liveness探针要配置/health这类无业务依赖的轻量端点，如果配置了需要加载业务资源的接口，可能会在应用启动阶段因为探针返回失败，导致Pod被kubelet误杀。

• 禁用副本缩容到0，保留最小运行副本
  调整自动扩缩容配置，把HPA的minReplicas或者KEDA的minReplicaCount设置为≥1的数值，避免无请求时Pod被完全销毁，从根源上杜绝Pod级别的冷启动。
• 配置探针保持进程活跃
  同时配置livenessProbe和readinessProbe，把探针调用间隔设置为小于你观测到的20分钟闲置阈值，定期给应用发送轻量请求，避免运行时回收JIT编译结果、连接池等资源，参考配置如下：

  livenessProbe:
    httpGet:
      path: /health
      port: 80
    initialDelaySeconds: 10
    periodSeconds: 300 # 每5分钟调用一次，小于20分钟的闲置触发阈值
    failureThreshold: 3
  readinessProbe:
    httpGet:
      path: /health
      port: 80
    initialDelaySeconds: 5
    periodSeconds: 10
  

• 提前编译降低冷启动耗时
  发布应用时开启ReadyToRun编译，把高频调用的代码提前编译为目标平台本地机器码，就算出现冷启动也能大幅降低首次请求的JIT编译耗时，发布命令参考：

  dotnet publish -c Release -r linux-x64 /p:PublishReadyToRun=true
  

• 配置启动预热逻辑
  在readiness探针返回成功前，预先调用核心业务初始化接口，提前完成DI容器初始化、数据库连接池创建、配置加载等操作，确保流量接入时应用已经完全就绪。

内容的提问来源于stack exchange，提问作者user584018