Infrastructure: sealed-secrets resource requests (ionos_common — all envs)

[groundnuty]

Closes #2678

Summary

Adds CPU/memory resource requests and limits to the sealed-secrets controller, which currently runs with no resource requests at all. Defining requests/limits makes the pod schedulable predictably and protects the node from a runaway controller.

Change

Single file: ionos_common/sealed-secrets/values.yaml — added a resources: block under the existing top-level sealed-secrets: (subchart) key:

  resources:
    requests:
      cpu: 10m
      memory: 32Mi
    limits:
      cpu: 100m
      memory: 64Mi

⚠️ Scope: ALL environments

This file lives in ionos_common/, which is shared across every environment (dev, dev2, sbx, prd) — it is not PRD-only. This change applies the controller resources everywhere. That is intended and desirable: the sealed-secrets controller is identical and tiny in every environment.

Sizing rationale

The controller's observed peak usage is ~23Mi memory / ~1m CPU. Requests (10m / 32Mi) sit comfortably above idle with headroom; limits (100m / 64Mi) leave ample burst room while staying small.

Verification (helm template)

Rendered the wrapper chart locally with helm template (subchart sealed-secrets 2.12.0 from the bitnami-labs chart). The bitnami-labs GitHub Pages helm repo index now returns 404, so the chart .tgz was pulled from the GitHub release asset and vendored into charts/ for the render only (not committed).

The resources block renders into the controller Deployment container spec:

# Source: sealed-secrets/charts/sealed-secrets/templates/deployment.yaml
kind: Deployment
...
          resources:
            limits:
              cpu: 100m
              memory: 64Mi
            requests:
              cpu: 10m
              memory: 32Mi

The subchart template gates on {{- if .Values.resources }} and emits resources: {{- toYaml .Values.resources | nindent 12 }}, so the value at sealed-secrets: → resources: reaches the rendered manifest. This addresses the failure mode of PR #2492 (values placed at a path the chart never read).

[groundnuty]

⚠️ Heads-up: this app's chart repo is 404'ing — ArgoCD can't currently sync sealed-secrets

Found while verifying this PR. The Helm chart this app pulls from, https://bitnami-labs.github.io/sealed-secrets, returns HTTP 404 (verified 2026-06-16).

This is not just a latent risk — the sealed-secrets ArgoCD app is already failing to reconcile:

• Sync status: Unknown (not Synced)
• ComparisonError: ... failed to fetch https://bitnami-labs.github.io/sealed-secrets/index.yaml : 404 Not Found
• Health still shows Healthy (the running controller pod is unaffected), but ArgoCD can no longer generate the manifest for this app.

Context: this is downstream of the 2025 Bitnami catalog upheaval — note our values already had to repoint the controller image to bitnamilegacy/sealed-secrets-controller (same root cause).

Consequence

• The running release keeps working (already deployed; SealedSecrets continue to decrypt).
• But anything that re-renders the chart will fail: an ArgoCD hard-refresh / cache loss, helm dependency build/update, a chart version bump, or a reinstall / disaster recovery.
• This also blocks this PR in practice. Even after merge, ArgoCD cannot apply the new resource requests until it can pull the chart again. The verification in this PR was done against a locally-vendored copy of the chart (version 2.12.0 from the GitHub release asset), not via ArgoCD's normal pull path.

Suggested follow-up (separate from this PR, likely its own issue)

• Vendor the sealed-secrets chart into the repo, or mirror it to an OCI registry we already control (GHCR / Harbor), and point the app at that — removing the dependency on the dead upstream URL.
• Until then, the sealed-secrets app stays unsyncable. Worth prioritising independently of resource right-sizing, since sealed-secrets decrypts every Secret in the cluster.