kubernetes - .NET Core/Kubernetes - SIGTERM，干净关闭

Question

我正在尝试使用 .NET Core 2.0 应用程序验证关闭是否在 Kubernetes 上干净地完成。

我有一个可以在两种“模式”下运行的应用程序——一种使用 ASP.NET Core，另一种作为一种工作进程。两者都使用控制台和 JSON-which-ends-up-in-Elasticsearch-via-Filebeat-sidecar-container 记录器输出，指示启动和关闭进度。

此外，当收到 SIGTERM 或 Ctrl-C 并开始关闭时，我有控制台输出直接写入标准输出。

在本地，该应用程序完美运行 - 我得到直接的控制台输出，然后记录器输出在 Ctrl+C 上流向标准输出(在 Windows 上)。

我的实验场景:

部署到 GCS k8s 集群的应用程序(使用 helm ，尽管我认为这没有什么区别)

使用 kubectl logs -f从特定容器流式传输日志

从 GCS 云控制台站点杀死 pod，或通过 helm delete 删除资源

Dockerfile 是 FROM microsoft/dotnet:2.1-aspnetcore-runtime并且有 ENTRYPOINT ["dotnet", "MyAppHere.dll"] ，所以不包含在 bash 中过程或任何东西

未指定 terminationGracePeriodSeconds所以猜测它默认为 30 秒

观察输出返回

结果:

API pod 日志流仅显示即时控制台输出“[SIGTERM] Stop signal received”，而不是其他有关关闭进程的控制台记录器输出

工作 pod 日志流显示更多信息 - 相同的控制台输出和一些关于关闭过程的控制台记录器输出

JSON 日志似乎没有选择任何关闭日志输出

我的结论:

我不知道 Kubernetes 是否允许该进程在终止之前完成，或者只是发出 SIGTERM 然后很快杀死事情。我认为它应该等待，但是，为什么没有完整的控制台记录器输出？

我不知道在进程最终终止之前的某个时刻，当 stdout 日志流式传输时控制台输出是否被切断？

我猜想 JSON 的东西不会通过 ES，因为在 sidecar 中运行的 filebeat 会终止，即使文件中有未完成的东西要发送

我想知道:

任何人都可以就上述第 1,2 点提出建议吗？

有什么想法可以让边车有一点额外的时间或余地来发送东西，比如 pod 容器终止命令、该容器的关闭延迟等？

Answer 1

SIGTERM确实表示终止。不太明显的部分是当 SIGTERM处理程序返回，一切都被认为已完成。

解决方法是不从 SIGTERM 返回处理程序，直到应用程序完成关闭。例如，使用 ManualResetEvent和 Wait()在处理程序中对其进行处理。