Proxied pods are configured with wrong port/endpoints in ReadynessProbe

[Retna-Gjensidige]

Describe the bug When running B2K in a namespace with 3 services and 3 pods, the first pod is successfully proxied but the other 2 fails. The 2 failed pods are using the livenessProbe settings of the succesfull pod in their readynessProbe. The problem is that the each of the 3 pods have their own port and endpoint for health checks. Coupled with the following bug the ports for pod 2 and 3 is set to the same as pod 1.

To Reproduce We have an Ingess with 3 backend path. Each path is routed to a different service in the namespace. Each service is routing to its pod and the respective pods have different ports exposed. Each pod has a livenessProbe but not readynessProbe. e.g. pod 1:

livenessProbe:
  httpGet:
    path: /healthz
    port: http
ports:
  - containerPort: 3000
    name: http
    protocol: TCP

pod 2:

livenessProbe:
  httpGet:
    path: /
    port: api-port
ports:
  - containerPort: 1337
    name: api-port
    protocol: TCP

pod 3:

livenessProbe:
  httpGet:
    path: /server
    port: 2609
ports:
  - containerPort: 2609
    name: http-port
    protocol: TCP

Proxied pod 2 and 3 have their readynessProbe set to the values of proxied pod 1 which caused a timeout/crash loop until B2K gives up and cleans up.

Environment Details Client used (VS Code/Visual Studio): VS Code AKS cluster: v1.19.6

Additional context We are using ArgoCD to manage deployments and are able to see in "real-time" which resources are being created by B2K in the namespace.

[lolodi]

Hi @Retna-Gjensidige! Thanks for reporting this issue! We'll investigate it and get back here once we have some news.