tom-tr
tom-tr

Reputation: 23

Readiness-Probe another Service on boot-up of Pod

On my Kubernetes Setup, i have 2 Services - A and B.
Service B is dependent on Service A being fully started through. I would now like to set a TCP Readiness-Probe in Pods of Service B, so they test if any Pod of Service A is fully operating.

the ReadinessProbe section of the deployment in Service B looks like:

readinessProbe:
  tcpSocket:
    host: serviceA.mynamespace.svc.cluster.local
    port: 1101 # same port of Service A Readiness Check

I can apply these changes, but the Readiness Probe fails with:

Readiness probe failed: dial tcp: lookup serviceB.mynamespace.svc.cluster.local: no such host

I use the same hostname on other places (e.g. i pass it as ENV to the container) and it works and gets resolved.

Does anyone have an idea to get the readiness working for another service or to do some other kind of dependency-checking between services? Thanks :)

Upvotes: 2

Views: 2869

Answers (2)

Meng-Yuan Huang
Meng-Yuan Huang

Reputation: 2333

In addition to Nick_Kh's answer, another workaround is to use probe by command, which is executed in a container.

To perform a probe, the kubelet executes the command cat /tmp/healthy in the target container. If the command succeeds, it returns 0, and the kubelet considers the container to be alive and healthy.

An example:

readinessProbe:
  exec:
    command:
     - sh
     - -c
     - wget -T2 -O- http://service

Upvotes: 1

Nick_Kh
Nick_Kh

Reputation: 5253

Due to the fact that Readiness and Liveness probes are fully managed by kubelet node agent and kubelet inherits DNS discovery service from the particular Node configuration, you are not able to resolve K8s internal nameserver DNS records:

For a probe, the kubelet makes the probe connection at the node, not in the pod, which means that you can not use a service name in the host parameter since the kubelet is unable to resolve it.

You can consider scenario when your source Pod A consumes Node IP Address by propagating hostNetwork: true parameter, thus kubelet can reach and success Readiness probe from within Pod B, as described in the official k8s documentation:

tcpSocket:
  host: Node Hostname or IP address where Pod A residing
  port: 1101

However, I've found Stack thread, where you can get more efficient solution how to achieve the same result through Init Containers.

Upvotes: 4

Related Questions