When the service.port value is changed from its default, the Pod’s liveness and readiness probes start failing. As a result, the Pods stay unready and can be restarted repeatedly.
Impact

• Users cannot expose the Service on a different external port without breaking health checks.
• Deployments fail to become Ready, blocking rollouts.

Steps to Reproduce

1. Install/upgrade the chart with a custom service.port, for example:

   • --set service.port=80

2. Wait for the Deployment to roll out.

3. Observe that liveness/readiness probes fail and Pods remain unready.

Expected Behavior

• It should be possible to change the Service’s externally exposed port (service.port) without affecting the container’s internal listen port and the health probes.
• Probes should continue to target the application’s actual listen port (e.g., 8288 by default), independent of Service exposure.

Actual Behavior

• Changing service.port also changes the containerPort and the probe target port.
• The application continues listening on its default internal port, but probes are sent to the new port, resulting in connection failures (e.g., “connection refused”).

Root Cause

• The chart currently couples the Service’s external port (service.port) with the container’s internal port and the probes. This conflates two concerns:

  • Service exposure (service.port) — how the Service is exposed inside the cluster
  • Application listen port — where the containerized app actually listens

• When service.port is changed without also reconfiguring the application to listen on that port, the probes and containerPort no longer match the app’s listening socket.

Proposed Fix

• Decouple the Service’s external port from the container’s listen port and the probe port.