Add Support for startupProbes to Chart

[hybby]

Overview

Introduced in Kubernetes 1.16, startupProbes provides support for applications that might require an additional startup time on their first initialization.

This issue is a feature request to add support for startupProbes to this chart:

• deployment.yaml: https://github.com/sonatype/helm3-charts/blob/main/charts/nexus-repository-manager/templates/deployment.yaml#L84-L103
• values.yaml: https://github.com/sonatype/helm3-charts/blob/main/charts/nexus-repository-manager/values.yaml#L60-L71

I believe this to be of use to the free version of Nexus Repository Manager, as most setups will be using a local OrientDB database. When an upgraded application is deployed, it's feasible that database migrations or index rebuilds may take place before the application fully starts up, which will take more time than accounted for in the default livenessProbe or readinessProbe settings (though I'm happy to be corrected here).

Use Case

We recently upgraded our Nexus Repository chart version from 30.1.0 to 39.0.0.

We observed on pod startup that certain operations against the local OrientDB database were occurring (database migrations? index rebuilds?). The default livenessProbe and readinessProbe configurations were not sufficient to allow these operations to complete, and Kubernetes killed the pod before the operations could complete, causing issues with the database being shut down uncleanly.

We run on EKS, with our component database being around 16GB, stored on an AWS EFS (NFS) volume using the default OrientDB databases in Nexus. Our blob store is around ~3m objects, stored in S3. So, we suspect that these database operations may have taken longer in our setup.

It would be nice to have the ability to specify that the first startup of Nexus could take up to as long as the migrations require to complete, after which the standard livenessProbe and readinessProbe settings kick in. The startupProbe would only impact worst-case startup scenarios and would not slow normal startup at all.

At the moment, to get around our issue, at time of upgrade we will need to provide a large initialDelaySeconds temporarily to the livenessProbe and readinessProbe settings and revert them afterwards.

References

• kubernetes.io - Protect slow starting containers with startup probes
• blog.colinbreck.com - Kubernetes Startup Probes: Getting Your Feet Under You