open5gs-upf: liveness and readiness probes by default

[martin-mat]

What type of PR is this?

feature

What this PR does / why we need it:

The UPF was the only 5G function deployed without probes. It has no SBI port, and its PFCP and GTP-U ports are UDP, so the chart offered custom probes only, empty by default. The pod counted as Ready the moment the container started, and a dead daemon was noticed only when the container exited. Details in #238.

This PR gives open5gs-upf the startupProbe, livenessProbe and readinessProbe values the other charts have, with liveness and readiness enabled by default:

• The default probes run a command in the container that checks that the PFCP socket is listening: ss -lun | grep -q ':<containerPorts.pfcp> '. They don't depend on the configuration file in use, so they work with the generated upf.yaml and with customOpen5gsConfig alike, and they need no metrics server. metrics.enabled keeps its meaning: the metrics server is configured only when it is on.
• A custom probe (customLivenessProbe and so on), when set, is used instead of the default one, so existing custom probes keep working.
• Two chart-testing value files, ci/generated-config-values.yaml and ci/custom-config-values.yaml (the generated configuration with the metrics block removed), install the chart both ways in CI.
• values.yaml says what the probe checks: that the UPF process is up and its PFCP socket is open. It is not an end-to-end check of UE sessions or GTP-U forwarding, and a daemon that hangs with the socket still open is not caught by it; customLivenessProbe is the place for a deeper check.

Tested on kind (gradiant/open5gs:2.7.5):

• Both chart-testing installs became Ready with no probe failures and no restarts; ss -lun in the container shows the PFCP socket on 8805, and the ConfigMap has no metrics block in either case (run 37536751573).
• The open5gs umbrella chart built from this branch, 5G core with chart defaults, passes the CNTi cert's liveness and readiness tests (run 37535114138).

Which issue(s) this PR fixes:

Fixes #238

Special notes for your reviewer:

• The probe values are those of the other Open5GS charts, with one difference: readinessProbe.timeoutSeconds is 5 instead of 1, since an exec probe has to start a process in the container.
• The order in the template is custom probe first, then the default one. In the other charts it is the other way round; here that order would have silently replaced custom probes that deployments already set.
• helm lint passes. Rendered and checked: defaults, customOpen5gsConfig without a metrics server, metrics.enabled=true (metrics server and Service), both probes disabled, and a custom liveness probe.
• Chart version bumped: open5gs-upf 2.3.4 to 2.3.5, inside the umbrella chart's ~2.3.2 range. The umbrella chart's own version is not bumped here.
• The 4G charts named in open5gs-upf: no liveness or readiness probe by default #238 (hss, mme, pcrf, sgwc, sgwu) are not changed.

Does this PR introduce a user-facing change?

Yes. A default installation now has liveness and readiness probes on the UPF. Both can be turned off with livenessProbe.enabled=false and readinessProbe.enabled=false. Nothing else changes: no new port is opened.

Does this PR introduce new external dependencies?

No.

Additional documentation:

🤖 Generated with Claude Code

[jpontongradiant]

Hi, thank you for your contribution!

Could we handle or document the customOpen5gsConfig case here? When customOpen5gsConfig is set, templates/configmap.yaml uses it instead of rendering resources/config/upf.yaml. If the default readiness/liveness probes remain enabled but the custom configuration does not contain upf.metrics.server, port 9090 will not be listening and the pod will remain permanently NotReady.

I suggest either:

• documenting that users providing customOpen5gsConfig must configure the metrics server themselves when using the default probes; or

• adding a validation/fallback so the default probes are not enabled unless the metrics endpoint is configured.

[martin-mat]

Thanks @jpontongradiant, good catch. With customOpen5gsConfig the rendered upf.yaml is replaced as a whole, so the metrics server this PR turns on for the probes isn't there, and the pod would stay NotReady.

Rather than making the probes conditional on the custom config, I'd make them independent of it. The UPF always listens for PFCP on UDP 8805, and the image has ss, so the default probes can check that socket from inside the container:

exec:
  command: ["sh", "-c", "ss -lun | grep -q ':{{ .Values.containerPorts.pfcp }} '"]

That works with the rendered config and with customOpen5gsConfig alike, and it probes what the SMF actually talks to rather than the metrics endpoint. The metrics server then stays off unless metrics.enabled is set, as before this PR, and containerPorts.pfcp is already the port a custom config has to agree with for the Service.

If you'd rather keep HTTP probes, I can instead render the defaults only when the custom config defines upf.metrics.server, and document it at customOpen5gsConfig. Either way I'll verify the probes on a kind cluster, with and without a custom config, before updating the PR. Which do you prefer?

[jpontongradiant]

Thanks, I agree with this approach. I prefer the socket-based probe because it keeps the default probes independent of both metrics.enabled and customOpen5gsConfig, while checking the PFCP socket.

Please add tests for both the generated configuration and a customOpen5gsConfig without the metrics server. It would also be useful to document that this probe validates that the local PFCP socket is listening, but does not provide an end-to-end UE or GTP-U health check.

Thank you!

[martin-mat]

Done, with the socket probe:

• The default probes are exec on ss -lun | grep -q ':<containerPorts.pfcp> ', so they depend neither on metrics.enabled nor on customOpen5gsConfig. The metrics server is back to being configured only by metrics.enabled.
• Tests: two chart-testing value files, ci/generated-config-values.yaml and ci/custom-config-values.yaml (the generated configuration with the metrics block removed). On kind both installs became Ready with no probe failures and no metrics block in the ConfigMap (run 37536751573).
• Documentation: values.yaml says the probe checks that the UPF process is up and its PFCP socket is open, not UE sessions or GTP-U forwarding end to end, and points to customLivenessProbe for a deeper check.

Rebased on main after #243; the chart version is now 2.3.5. The PR description is updated to match.

[jpontongradiant]

Thank you very much!