## What this PR does
Bumps the vendored `etcd-operator` chart from `v0.4.2` to `v0.4.3` and
wires the new backup machinery through the cozystack `Etcd` app API.
Upstream v0.4.3 ships two new CRDs — `EtcdBackup` (one-shot snapshot)
and `EtcdBackupSchedule` (periodic snapshots) — along with the
`EtcdCluster.spec.bootstrap` restore field, a new `OPERATOR_IMAGE` env
on the operator deployment, and a replacement of the deprecated
`gcr.io/kubebuilder/kube-rbac-proxy` image. The chart portion of this PR
is a clean re-vendor via `make update` — no local patches.
On top of the bump, `packages/extra/etcd` exposes a new optional
`backup.*` values block. When `backup.enabled=true`, the chart renders
an `EtcdBackupSchedule` referencing the platform `EtcdCluster/etcd` and
a `Secret/etcd-s3-creds` with the S3 credentials expected by the
backup-agent. The values field names (`destinationPath`, `endpointURL`,
`s3AccessKey`, `s3SecretKey`, `schedule`) mirror the existing `postgres`
backup pattern for consistency. The chart `fail`s at template render if
any of the four required S3 fields are empty or if `destinationPath` is
malformed (missing `s3://` prefix, `//` segments, no bucket).
Test coverage: 15 `helm-unittest` cases across
`tests/backup-secret_test.yaml` and
`tests/etcd-backup-schedule_test.yaml` (wired into `make test`, picked
up by `hack/helm-unit-tests.sh`), plus three bats cases in
`hack/e2e-apps/etcd.bats` covering the baseline `Etcd` app, the `backup:
{}` default-off path, and the full `backup.enabled=true` case that
verifies the `EtcdBackupSchedule` materializes and the operator
generates the downstream `CronJob`.
`packages/core/platform/sources/etcd-operator.yaml` now sets
`upgradeCRDs: CreateReplace` on the etcd-operator component, so Flux
applies the new CRDs on upgrade of the chart instead of silently
skipping them.
Depends on #2427.
### Scope deferred to follow-ups
- The one-shot `EtcdBackup` CRD is vendored but not exposed through this
chart — users can still hand-apply the CRD directly.
- `EtcdCluster.spec.bootstrap` (restore from an existing snapshot) is
likewise vendored but not exposed. Both gaps are called out in
`packages/extra/etcd/README.md`.
### Release note
```release-note
feat(etcd): update etcd-operator to v0.4.3 and expose S3 backup schedules on the Etcd app. Set `backup.enabled=true` along with `backup.s3AccessKey`, `backup.s3SecretKey`, `backup.destinationPath`, and `backup.endpointURL` to schedule periodic snapshots.
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Scheduled S3 backups for etcd clusters (configurable cron, generated
S3 credentials) and restore/init from S3 or PVC via new backup
resources.
* **Tests**
* New end-to-end tests for etcd lifecycle and backup scenarios; added
Helm unit tests for backup templates and validations.
* **Documentation**
* Backup configuration guide and parameter reference added.
* **Chores**
* Operator chart version bump; RBAC, webhooks, and deployment wiring
updated; added chart test target.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Etcd-cluster
Backups
When backup.enabled is set to true, the chart renders an EtcdBackupSchedule (etcd.aenix.io/v1alpha1) and an S3 credentials Secret. The etcd-operator v0.4.3+ reconciles the schedule into a CronJob that periodically snapshots the cluster to S3.
Enabling backup requires the following fields to be explicitly set (defaults are empty strings so that missing values fail fast at template render time): backup.s3AccessKey, backup.s3SecretKey, backup.destinationPath (must start with s3:// and have no // segments), and backup.endpointURL. S3 credentials passed through plain values end up in the HelmRelease manifest — for production deployments prefer an external secret management tool (ESO, Sealed Secrets, etc.) over committing the keys to Git.
Restore (EtcdCluster.spec.bootstrap) and the one-shot EtcdBackup custom resource shipped upstream in v0.4.3 are not yet exposed through this chart. Restoring from a snapshot or taking an ad-hoc backup currently requires hand-applying the corresponding custom resource manifest.
Parameters
Common parameters
| Name | Description | Type | Value |
|---|---|---|---|
size |
Persistent Volume size. | quantity |
4Gi |
storageClass |
StorageClass used to store the data. | string |
"" |
replicas |
Number of etcd replicas. | int |
3 |
resources |
Resource configuration for etcd. | object |
{} |
resources.cpu |
Number of CPU cores allocated. | quantity |
1000m |
resources.memory |
Amount of memory allocated. | quantity |
512Mi |
Backup parameters
| Name | Description | Type | Value |
|---|---|---|---|
backup |
Backup configuration. | object |
{} |
backup.enabled |
Enable scheduled S3 backups. | bool |
false |
backup.schedule |
Cron schedule for automated backups. | string |
0 2 * * * |
backup.destinationPath |
Destination path for backups (e.g. s3://bucket/path/). | string |
"" |
backup.endpointURL |
S3 endpoint URL for uploads. | string |
"" |
backup.region |
S3 region. | string |
"" |
backup.forcePathStyle |
Use path-style S3 URLs (required for MinIO and most S3-compatible providers). | bool |
true |
backup.s3AccessKey |
Access key for S3 authentication. | string |
"" |
backup.s3SecretKey |
Secret key for S3 authentication. | string |
"" |
backup.successfulJobsHistoryLimit |
Number of successful backup jobs to retain. | int |
3 |
backup.failedJobsHistoryLimit |
Number of failed backup jobs to retain. | int |
1 |