Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Readiness and liveness probes target the wrong port in the LIM Helm Chart #35

Open
mathieu-cap opened this issue Oct 11, 2024 · 0 comments
Labels
bug Something isn't working

Comments

@mathieu-cap
Copy link

mathieu-cap commented Oct 11, 2024

Current Behavior

In the 24.2.0-2 version of the LIM helm chart, the readiness and liveness probes fail to check the health of the lim container because they target the named port http instead of the one named https, which results in an error and prevents the container to be accessible. See below the Pod's events obtained with a kubectl describe command:

Name:             lim-0
Namespace:        <our DAST namespace>
Priority:         0
Service Account:  default
Node:             <our node>
Start Time:       Thu, 10 Oct 2024 15:20:23 +0200
Labels:           app.kubernetes.io/instance=lim
                  app.kubernetes.io/name=lim
                  apps.kubernetes.io/pod-index=0
                  controller-revision-hash=lim-6c6bb549f8
                  statefulset.kubernetes.io/pod-name=lim-0
Annotations:      cni.projectcalico.org/containerID: 6e39c1860f6544c18a04308d6b68e4bf353c8ae6a7d39bdd085eabaae323798a
                  cni.projectcalico.org/podIP: 10.2.5.218/32
                  cni.projectcalico.org/podIPs: 10.2.5.218/32
Status:           Running
IP:               10.2.5.218
IPs:
  IP:           10.2.5.218
Controlled By:  StatefulSet/lim
Containers:
  lim:
    Container ID:   containerd://9cd2021c3fb686db10046cf7a5c2ca81dfab3d26b984eaf51b859cc73f24d05a
    Image:          fortifydocker/lim:24.2.ubi.8
    Image ID:       docker.io/fortifydocker/lim@sha256:fae5607e5d97c0ea52029c6f2487e331cda77a9284358cc9994fa8e492879956
    Port:           1443/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Thu, 10 Oct 2024 15:20:40 +0200
    Ready:          False
    Restart Count:  0
    Limits:
      cpu:     500m
      memory:  1Gi
    Requests:
      cpu:      500m
      memory:   1Gi
    Liveness:   http-get http://:http/ delay=0s timeout=1s period=10s #success=1 #failure=3
    Readiness:  http-get http://:http/ delay=10s timeout=1s period=10s #success=1 #failure=3
[...]
Conditions:
  Type                        Status
  PodReadyToStartContainers   True
  Initialized                 True
  Ready                       False
  ContainersReady             False
  PodScheduled                True
[...]
Events:
  Type     Reason     Age                     From     Message
  ----     ------     ----                    ----     -------
  Warning  Unhealthy  6m16s (x8155 over 20h)  kubelet  Readiness probe errored: strconv.Atoi: parsing "http": invalid syntax
  Warning  Unhealthy  76s (x7231 over 20h)    kubelet  Liveness probe errored: strconv.Atoi: parsing "http": invalid syntax

But by modifying the chart's StatefulSet to target the https port defined as 1443 like so, it works:

[...]
livenessProbe:
  httpGet:
    path: /
    port: https
    scheme: HTTP
readinessProbe:
  initialDelaySeconds: 10
  httpGet:
    path: /
    port: https
    scheme: HTTP
[...]

It would be nice if you would update the StatefulSet to target the right port.

Expected Behavior

The readiness and liveness probes should target the 1443 port.

Steps To Reproduce

  1. Create a values.yml file defining the required data
  2. Install the helm chart with the created values file
  3. The lim-0 Pod will never be "ready"

Environment

Kubernetes: 1.29.3
LIM Helm Chart: 24.2.0-2

Anything else?

No response

@mathieu-cap mathieu-cap added the bug Something isn't working label Oct 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant