feat(bootstrap): use an init container instead of a separate Job for new instances - #11319
feat(bootstrap): use an init container instead of a separate Job for new instances#11319leonardoce wants to merge 8 commits into
Conversation
|
❗ By default, the pull request is configured to backport to all release branches.
|
|
/test bp=pr-1025 l=kind |
|
@leonardoce, here's the link to the E2E on CNPG workflow run: https://github.com/cloudnative-pg/cloudnative-pg/actions/runs/31681054762 |
cb78fa2 to
4987ac8
Compare
|
/test bp=pr-1025 l=kind |
|
@leonardoce, here's the link to the E2E on CNPG workflow run: https://github.com/cloudnative-pg/cloudnative-pg/actions/runs/32012769354 |
4987ac8 to
0e06aee
Compare
632e3d9 to
51541be
Compare
51541be to
01825fc
Compare
|
/test |
|
@mnencia, here's the link to the E2E on CNPG workflow run: https://github.com/cloudnative-pg/cloudnative-pg/actions/runs/32969475705 |
|
Full E2E run on EDB fork https://github.com/EnterpriseDB/cloudnative-pg/actions/runs/33049566677 |
535f11c to
fa08f68
Compare
|
/test bp=pr-1025 |
|
@mnencia, here's the link to the E2E on CNPG workflow run: https://github.com/cloudnative-pg/cloudnative-pg/actions/runs/33049147476 |
…arate Job New primary and replica instances are now bootstrapped (initdb, recovery, pg_basebackup, join, and snapshot restore) directly on the instance Pod via an init container, instead of running a separate Kubernetes Job beforehand. This removes the extra Job resource previously created for every new instance, along with its own Pod, and the wait for that Job to complete before the actual instance Pod could start. Signed-off-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
A bootstrap init container has no Job-style backoff limit, so kubelet retries a failing one forever with no signal; surface it on first failure via Cluster status, leaving the Pod untouched so a later success clears it again. Assisted-by: Claude Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
… check Assisted-by: Claude Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
attachReplicaBootstrapInitContainer resumes a stalled replica's bootstrap but never told the Cluster: no Event, no PhaseCreatingReplica. Restore both, matching joinReplicaInstance and the Job-based recreateReplicaBootstrapJob it replaced. Assisted-by: Claude Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
NewInstance stamps the stored PodSpec annotation before AddBootstrapInitContainer runs, and the freshly-built target skips that call too, so the container can never appear on either side. The comment's premise, including a NewInstanceWithBootstrap citation that doesn't exist, was wrong. Assisted-by: Claude Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
fa08f68 to
8a29ae2
Compare
|
/test bp=pr-1025 |
|
@mnencia, here's the link to the E2E on CNPG workflow run: https://github.com/cloudnative-pg/cloudnative-pg/actions/runs/33057043908 |
CloudNativePG is moving the bootstrap of new instances from dedicated Jobs into the instance pod itself (cloudnative-pg/cloudnative-pg#11319): the restore that used to run in a recovery Job now happens in-process inside the instance pod before PostgreSQL starts. The sidecar shipped in that pod must therefore answer the same Restore RPC the operator sends over the plugin sockets, so the instance mode now registers the restore-job hooks and advertises the restore-job service capability. A cluster that only bootstraps from an object store, without continued archiving, previously received no sidecar at all in its instance pods; under the new flow that leaves the bootstrap without a plugin socket, both for the Restore RPC and for `wal-restore` during the recovery replay. The injection condition is widened to match what the plugin configuration already considers valid, so recovery-only clusters get the sidecar too. The sidecar is dropped once the instance's bootstrap completes (cluster.Status.CurrentPrimary set), which triggers one deterministic rollout to remove it, accepted rather than engineered around since it uses the same switchover/restart machinery as any other pod-spec change. Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com> Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com> Co-authored-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
New primary and replica instances are now bootstrapped (initdb, recovery, pg_basebackup, join, and snapshot restore) directly on the instance Pod via an init container, instead of running a separate Kubernetes Job beforehand. This removes the extra Job resource previously created for every new instance, along with its own Pod, and the wait for that Job to complete before the actual instance Pod could start.
A stuck bootstrap surfaces as PhaseUnrecoverable on the Cluster status, and a replica resuming a stalled bootstrap reports PhaseCreatingReplica with an Event.
Closes: #11228
Original PR description
New primary and replica instances are now bootstrapped (initdb, recovery,
pg_basebackup, join, and snapshot restore) directly on the instance Pod via
an init container, instead of running a separate Kubernetes Job beforehand.
This removes the extra Job resource previously created for every new
instance, along with its own Pod, and the wait for that Job to complete
before the actual instance Pod could start.
Important
This is an alternative approach for #11231 that is less invasive on the codebase.
It requires #11315 to be merged too.