chore(helm): PDBs, opt-in HPA, and pinned SPIRE reference chart

[PenguinzTech]

Availability + SPIFFE ops hardening for the charts. k8s/helm/squawk: PodDisruptionBudgets rendered for any Deployment at ≥2 replicas (gated pdb.enabled, minAvailable 1), opt-in HPA (off by default; enabled in values-prod.yml with per-service min/max + 70% CPU), replicas: omitted when autoscaling owns scaling. New k8s/helm/spire: thin wrapper pinning the official spiffe/helm-charts-hardened spire chart v0.29.0 (Chart.lock digest-pinned), trust domain penguintech.io, README covering install order, ClusterSPIFFEID registration, XFCC forward/strip, and flipping SPIFFE_ENABLED.

Validation: helm lint + helm template green on all values files and with autoscaling enabled.
Known gap (documented, out of scope here): squawk chart doesn't yet expose SPIFFE_* env as values — README gives interim kubectl set env step.

Stack note: bases on chore/dedup-reusable-code (top of the #53–#59 chain); auto-retargets toward v2.1.x as the stack merges bottom-up.

🤖 Generated with Claude Code

Summary by Sourcery

Add availability safeguards and autoscaling controls to the squawk Helm chart and introduce a pinned SPIRE reference chart for SPIFFE integration.

New Features:

• Introduce opt-in HorizontalPodAutoscalers for squawk stateless services, enabled only in production via chart values.
• Add a SPIRE Helm subchart that wraps and pins the upstream spiffe/helm-charts-hardened spire chart for SPIFFE-based mTLS identity.

Enhancements:

• Configure PodDisruptionBudgets for squawk Deployments with at least two replicas to improve resilience during node disruptions.
• Extend squawk chart values to support per-service autoscaling configuration while keeping non-production environments on fixed replicas.
• Document SPIRE installation, workload registration, XFCC handling, and SPIFFE feature enablement in a new spire README.

[sourcery-ai]

🧙 Sourcery has finished reviewing your pull request!

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've left some high level feedback:

• For autoscaled workloads, PDB rendering is still keyed off the static replicas values; consider basing the ge(..., 2) checks on the HPA minReplicas instead so disruption guarantees align with actual scaling behaviour.
• The global autoscaling.enabled flag controls all HPAs, but individual services (e.g. valkey, manager-scheduler) are excluded only by comments; if you expect more fine-grained control, you may want per-service autoscaling.enabled switches or explicit gating in hpa.yml to avoid accidental future inclusion.
• In values-prod.yml, you now have both top-level autoscaling.enabled and per-service autoscaling blocks; it might be worth clarifying in values (or enforcing via helm schema) that per-service autoscaling config is ignored unless the global flag is true to avoid misconfiguration.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- For autoscaled workloads, PDB rendering is still keyed off the static `replicas` values; consider basing the `ge(..., 2)` checks on the HPA `minReplicas` instead so disruption guarantees align with actual scaling behaviour.
- The global `autoscaling.enabled` flag controls all HPAs, but individual services (e.g. valkey, manager-scheduler) are excluded only by comments; if you expect more fine-grained control, you may want per-service `autoscaling.enabled` switches or explicit gating in `hpa.yml` to avoid accidental future inclusion.
- In `values-prod.yml`, you now have both top-level `autoscaling.enabled` and per-service `autoscaling` blocks; it might be worth clarifying in values (or enforcing via helm schema) that per-service autoscaling config is ignored unless the global flag is true to avoid misconfiguration.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}