I'm seeing liveness and readiness probe report as "http://:http/$HEALTH_CHECK_ENDPOINT"

[Gowiem]

Describe the bug
I'm seeing liveness and readiness probes report as "http://:http/$HEALTH_CHECK_ENDPOINT". This seems incorrect according to my helm chart's configuration.

To Reproduce
Steps to reproduce the behavior:

1. Add a liveness probe
2. View your prod via the Lens app.
3. The configuration looks incorrect.

Expected behavior
I would expect to see it either report just the /$HEALTH_CHECK_ENDPOINT or the full hostname / IP of the pod and then the /$HEALTH_CHECK_ENDPOINT

Screenshots

Environment (please complete the following information):

• Lens Version: 3.5.2
• OS: OSX
• Installation method (e.g. snap or AppImage in Linux): Installation through downloading release.

Logs:
Here is my liveness and readiness probe from kc get pod $POD_NAME -o yaml

    livenessProbe:
      failureThreshold: 3
      httpGet:
        path: /health-check
        port: http
        scheme: HTTP
      initialDelaySeconds: 60
      periodSeconds: 60
      successThreshold: 1
      timeoutSeconds: 1
    readinessProbe:
      failureThreshold: 3
      httpGet:
        path: /health-check
        port: http
        scheme: HTTP
      initialDelaySeconds: 60
      periodSeconds: 60
      successThreshold: 1
      timeoutSeconds: 1

Kubeconfig:

apiVersion: v1
clusters:
- cluster:
    certificate-authority: /Users/gowiem/.minikube/ca.crt
    server: https://192.168.64.2:8443
  name: minikube
- cluster:
    certificate-authority-data: SECRET
    server: SECRET
  name: arn:aws:eks:us-east-1:$SECRET_ARN
contexts:
- context:
    cluster: minikube
    user: minikube
  name: minikube
- context:
    cluster: arn:aws:eks:us-east-1:$SECRET_ARN
    user: arn:aws:eks:us-east-1:$SECRET_ARN
  name: arn:aws:eks:us-east-1:$SECRET_ARN
current-context: arn:aws:eks:us-east-1:$SECRET_ARN
kind: Config
preferences: {}
users:
- name: minikube
  user:
    client-certificate: /Users/gowiem/.minikube/profiles/minikube/client.crt
    client-key: /Users/gowiem/.minikube/profiles/minikube/client.key
- name: arn:aws:eks:us-east-1:$SECRET_ARN
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      args:
      - --region
      - us-east-1
      - eks
      - get-token
      - --cluster-name
      - $CLUSTER_NAME
      command: aws
      env:
      - name: AWS_PROFILE
        value: $PROFILE_NAME

[Nokel81]

Is this still a problem with 4.1.4?

[Gowiem]

@Nokel81 yeah, I'm still seeing this on 4.1.4 --

[Nokel81]

Okay so to start port is supposed to a number, that is why you see :http. But I agree that the hostname or IP could be useful here too (if it isn't specified in the httpGet field.

[Nokel81]

Though shouldn't it be pod's node's IP?

[Nokel81]

I have found:

• https://kubernetes.io/docs/concepts/services-networking/service/#type--nodeport shows that httpGet.port can be an IANA_SVC_NAME, and when it does it reffers to a port defined in the same containers ports field
• https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#use-a-named-port
• https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.21/#containerport-v1-core

So we should indeed update this, and it seems that the IP that we should default to (if the one in the ports entry is missing) is the external IP of the container.

[Nokel81]

@Gowiem Sorry for another question. I assume you have ports field defined? If that isn't defined does Kubernetes error out or fall back to some default port?

[Gowiem]

@Nokel81 Not sure on the second question, but yes a lot of my charts look like the following:

# deployment.yml 
... 
ports:
- name: http
  containerPort: {{ .Values.env.PORT }}
  protocol: TCP
...

# service.yaml
ports:
- name: http
  port: {{ .Values.service.port }}
  targetPort: http
  protocol: TCP