The startup probe the plugin attaches to the injected plugin-barman-cloud sidecar does not set periodSeconds, so the Kubernetes API server defaults it to 10s.
Because the sidecar is an initContainer, the main postgres container is not started until the sidecar is marked Started, i.e. until its startup probe first succeeds.
With a 10s period, that first success typically lands ~one full period (~10s) after the sidecar container is running, even though the probe itself (/manager healthcheck unix) returns in milliseconds.
/manager healthcheck unix is a purely local probe that opens a gRPC client over a Unix domain socket to check that the plugin's own gRPC server is up and responding.
This is usually very fast, so we can probably set lower a lower default for the startup probe periodSeconds.
Found via CNPG E2E tests:
In CNPG E2Es this adds roughly ~10s per instance to each cluster's startup ( ~+30s for a 3-instance cluster, and so on), on every plugin-backed cluster.
The startup probe the plugin attaches to the injected plugin-barman-cloud sidecar does not set
periodSeconds, so the Kubernetes API server defaults it to 10s.Because the sidecar is an
initContainer, the mainpostgrescontainer is not started until the sidecar is markedStarted, i.e. until its startup probe first succeeds.With a 10s period, that first success typically lands ~one full period (~10s) after the sidecar container is running, even though the probe itself (
/manager healthcheck unix) returns in milliseconds./manager healthcheck unixis a purely local probe that opens a gRPC client over a Unix domain socket to check that the plugin's own gRPC server is up and responding.This is usually very fast, so we can probably set lower a lower default for the startup probe
periodSeconds.Found via CNPG E2E tests:
In CNPG E2Es this adds roughly ~10s per instance to each cluster's startup (
~+30sfor a 3-instance cluster, and so on), on every plugin-backed cluster.