在kubernetes中选择TCP探测和HTTP探测的活跃性和就绪性
为了简单起见，我认为在kubernetes中最好只检查TCP端口的活跃度和就绪度，因为它不需要了解健康检查endpoint（HTTP路径），而只需要端口号。任何关于仅仅依赖TCP端口进行服务健康检查的缺点的指南都非常赞赏，请假设POD不是其他服务的代理，并且所有业务逻辑都在POD本身中。
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readity-startup-probes/
共有1个答案
根据我的经验，当您在同一个pod中的应用程序前面有一个反向代理边车（例如nginx）时，会选择HTTP而不是TCP。在这种情况下，nginx将始终接受TCP，即使应用程序还没有准备好。因此您需要HTTP。
否则：
- 如果这是直接在端口上侦听的app服务器
- 您知道它仅在满载时才开始侦听
- 您不希望
/healt内部有任何其他逻辑（如检查数据库连接）
如果以上都是真的--只需使用TCP即可。
提示您甚至不需要知道TCP的端口号，您可以使用命名端口:https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readity-startup-probes/#use-a-named-port
-
我可以找到文件，其中提到我如何添加我的自定义探针和改变探针参数，如初始延迟等，但不能找到默认的探针方法使用的K8S。
-
我正在使用Spring开发一个服务，并将其部署在OpenShift上。目前，我正在使用Spring Actuctor health endpoint作为Kubernetes的活跃度和就绪度探测器。 但是，我将在执行器健康endpoint中添加一个对另一个服务的调用，在这种情况下，我认为我需要为我的服务实现新的活跃度探测。如果我不这样做，那么第二个服务的失败将导致活跃度探测失败，Kubernetes
-
给出一个Python应用程序，它在无限循环中轮询Kafka主题，并在处理接收到的Kafka消息后将结果上传到s3 bucket。 null 并且活性探测只检查轮询循环是否尚未退出。 严格来说，在准备调查中检查这样的事情是不好的做法吗？
-
我使用的是标准的skydns RC/SVC YAMLS。 吊舱描述： （etcd） 我还将放入kube2sky容器中，ca.crt与服务器上的ca.crt匹配。
-
我正试图遵循此文档，以便在我的吊舱上启用准备状态和活跃度探测，以便在我的集群中进行健康检查，但它给了我一个错误，即拒绝连接到容器IP和端口。下面是我添加的准备和活力的部分。 我正在使用helm进行部署，我试图监视的端口是80。下面还给出了入口的服务文件。 https://docs.microsoft.com/en-us/azure/application-gateway/ingress-contr
-
当我试图为我的awx_web容器设置活跃度和就绪度prob时，我总是得到这个错误