Azure容器应用程序 - 尽管最少的复制品为1,服务停止了
我根据在Docker容器中运行的CRON时间表并将其推到Azure容器应用程序中的.NET Worker服务。时间表在应用程序本身内进行管理。
缩放设置为始终运行的1个复制品。
但是,我们发现,出于某种原因,应用程序启动,闲置等待时间表触发约20-30秒,停止2秒,开始和闲置,持续约20-30秒,然后不再运行〜5-6分钟。在空闲时间中,如果CRON计划在流程运行时加入,则该作业可能会开始。
有什么方法可以诊断为什么它可能会自动杀死应用程序?
我似乎找不到任何显示任何致命异常或沿这些行的日志,并且在其他环境(本地,Azure容器实例等)中运行不会复制行为。我的怀疑是这是自动缩放行为:Azure注意到该过程一次闲置20-30秒并杀死该复制品,只是为了在5分钟后再次旋转。但是,我似乎找不到任何证明这一理论的东西。
我知道其他资源类型可能更适合(容器实例,应用程序服务,功能),尽管现在我陷入了容器应用程序。
I've got a .NET worker service based on a cron schedule running in a Docker container and pushed up to Azure Container Apps. The schedule is managed within the application itself.
The scaling is set to have a minumum of 1 replica running at all times.
However, we've found that for some reason the application starts up, idles waiting for the schedule trigger for ~20-30 seconds, stops for 2 seconds, starts and idles for ~20-30 seconds again and then doesn't run again for ~5-6 minutes. During the idling time, the job might start if the cron schedule lines up while the process is running.
Is there any way to diagnose why it might be auto-killing the application?
I can't seem to find any logs that show any fatal exceptions or along those lines, and running in other environments (locally, Azure Container Instance etc.) doesn't replicate the behavior. My suspicion is that it's the auto-scaling behavior: Azure is noticing that the process is idle for 20-30 seconds at a time and killing that replica, only for it to spin up again 5 mins later. However, I can't seem to find anything to prove that theory.
I'm aware that other resource types might be better suited (Container Instances, App Service, Functions) though for now I'm stuck with Container Apps.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
基于这个问题找到了问题的原因:
每30秒
azure容器应用程序应用程序apps apps apps restss restarts每30秒重新启动 尽管没有暴露HTTP端口,但对此进行了健康检查。 Azure认为容器不健康,杀死并重新开始。关闭HTTP入口(以及健康检查)解决了此问题。
Found the cause of the issue based on this SO question:
Azure Container Apps Restarts every 30 seconds
Turns out, Azure was trying to do health checks on it despite no HTTP ports being exposed. Azure thinking the container is unhealthy, kills and restarts it. Turning off HTTP ingress (and therefore the health checks) solved this issue.