Kubernetes活动探针日志记录恢复 [英] Kubernetes liveness probe logging recovery
问题描述
我正在尝试学习kubernetes时测试活动性探针. 我已经建立了一个迷你库并配置了带有活动探针的吊舱.
I am trying to test a liveness probe while learning kubernetes. I have set up a minikube and configured a pod with a liveness probe.
测试脚本(例如通过docker exec)似乎可以根据需要报告成功和失败.
Testing the script (E.g. via docker exec) it seems to report success and failure as required.
该探针会导致失败事件，我可以通过 kubectl describe podname 查看该事件 但它不会报告从故障中恢复.
The probe leads to failures events which I can view via kubectl describe podname but it does not report recovery from failures.
此答案说，默认情况下未报告活动性探测成功.
This answer says that liveness probe successes are not reported by default.
我一直在尝试通过运行以下变体来提高日志级别，但没有成功:
I have been trying to increase the log level with no success by running variations like:
minikube start --extra-config=apiserver.v=4
minikube start --extra-config=kubectl.v=4
minikube start --v=4
为kubelet配置日志记录级别的正确方法是什么?
可以在不重新启动Pod或minikube的情况下对其进行修改吗?
can it be modified without restarting the pod or minikube?
如果失败导致Pod重新启动，将报告一个事件. 对于kubernetes本身，我知道使用它来决定是否重新启动Pod就足够了.
An event will be reported if a failure causes the pod to be restarted. For kubernetes itself I understand that using it to decide whether to restart the pod is sufficient.
为什么不记录事件以从不需要重启的故障中恢复? 我希望探针可以在健康监控系统中工作.
Why aren't events recorded for recovery from a failure which does not require a restart? This is how I would expect probes to work in a health monitoring system.
如果在普罗米修斯或类似方法中使用相同的探针，恢复情况将如何可见? 对于昂贵的探针，我不希望它多次运行. (授权的一个探针可以将输出缓存到文件中，从而使第二个探针更便宜)
How would recovery be visible if the same probe was used in prometheus or similar? For an expensive probe I would not want it to be run multiple times. (granted one probe could cache the output to a file making the second probe cheaper)
推荐答案
我一直在尝试提高日志级别，但没有成功 运行类似的变体
I have been trying to increase the log level with no success by running variations like:
minikube start --extra-config=apiserver.v=4
minikube start --extra-config=kubectl.v=4
minikube start --v=4
@Bruce，您提到的所有选项都无法使用，因为它们已与Kubernetes集群的其他组件一起被删除，并且在您提到的答案中明确指出:
@Bruce, none of the options mentioned by you will work as they are releted with other components of Kubernetes cluster and in the answer you referred to it was clearly said:
成功探测的输出不会记录在任何地方，除非您 Kubelet 的日志级别至少为--v = 4， 在这种情况下，它将位于 Kubelet的日志 .
The output of successful probes isn't recorded anywhere unless your Kubelet has a log level of at least --v=4, in which case it'll be in the Kubelet's logs.
因此，您需要专门针对 kubelet .在官方文档中，您可以看到它可以以特定的标志开始，包括一个标志，它更改了日志的默认详细级别:
So you need to set -v=4 specifically for kubelet. In the official docs you can see that it can be started with specific flags including the one, changing default verbosity level of it's logs:
-v, --v Level
number for the log level verbosity
Kubelet 作为每个节点上的系统服务运行，因此您可以通过简单地发出以下命令来检查其状态:
Kubelet runs as a system service on each node so you can check it's status by simply issuing:
systemctl status kubelet.service
，如果要查看它的日志，请发出命令:
and if you want to see it's logs issue the command:
journalctl -xeu kubelet.service
尝试:
minikube start --extra-config=kubelet.v=4
但是，我不确定100％ Minikube 是否能够传递此参数，因此您需要自己进行验证.如果它不起作用，您仍然应该能够将其添加到kubelet配置文件中，并指定启动它的参数(提交更改后不要忘记重新启动kubelet.service，您只需要运行systemctl restart kubelet.service )
however I'm not 100% sure if Minikube is able to pass this parameter so you'll need to verify it on your own. If it doesn't work you should still be able to add it in kubelet configuration file, specifying parameters with which it is started (don't forget to restart your kubelet.service after submitting the changes, you simply need to run systemctl restart kubelet.service)
让我知道是否有帮助，如果有一些不完全清楚的地方，请随时询问其他问题.
Let me know if it helps and don't hesitate to ask additional questions if something is not completely clear.
这篇关于Kubernetes活动探针日志记录恢复的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
