Installation

Topology requirements and unpublished boundaries

Evaluate high availability as a shared data and platform design rather than a single application setting.

How should this content be used?Evidence required for publicationDocumentation versionLatest

Repeatable commands and dated operational evidence are incomplete; do not use this page as production instruction.

Required design areas

Shared PostgreSQL, common storage, session/topology, ingress, rollout, and platform components must be designed together.

Building blocks present in the chart

The source Helm chart defaults to three replicas, an HPA range of 3–10, a minAvailable 2 PodDisruptionBudget, a 60-second termination grace period, a preStop delay, and hostname and zone topology-spread fields. Out-of-chart prerequisites such as at least three schedulable worker nodes and Metrics Server must also be provided. These are platform mechanisms, not measured high-availability outcomes or a ready-made SLA.

Probe and traffic behavior

The startup probe should measure migration and startup completion, readiness should measure database and active-storage access, and liveness should measure only whether the process can make progress. A dependency outage should remove the pod from traffic through readiness rather than trigger a restart loop, and the liveness threshold must remain distinct from temporary PostgreSQL or S3 failure.

Data and platform prerequisites

Every application replica must access the same PostgreSQL correctness state and the same artifact content. Use S3-compatible shared storage or a genuinely shared RWX filesystem; do not treat node-local volumes as shared storage for multiple replicas.

  • PostgreSQL failover, connection timeout, and pool reconnection behavior
  • Effect of storage endpoint or mount outage on readiness and package requests
  • Ingress removing unready pods from traffic and handling long uploads or downloads
  • Joint behavior of node or zone spread, capacity, HPA metrics, and disruption budget
  • Preservation of long-running task lease and retry behavior after replica loss
  • Preservation of per-pod logs on the shared RWX support-log claim and their aggregation in the Support bundle

Distributed job ownership

Cleanup, storage transfer, scan evaluation, OSV, and partition-retention work uses durable PostgreSQL state with owner-checked leases; every replica may redispatch recoverable work, but the same lease must not execute on two workers. A replica-loss test must jointly verify lease expiry or renewal, resume cursor, duplicate side effects, and terminal audit or operation evidence.

Failover acceptance plan

Measure the target topology with controlled failure scenarios before treating it as production-ready. Each test must record starting load, injected failure, user impact, recovery time, data integrity, and operational evidence.

  1. Loss of one application pod and worker node
  2. Ingress-controller outage or DNS and TLS renewal disruption
  3. PostgreSQL primary failover and temporary connection loss
  4. S3 endpoint or RWX mount latency or unavailability
  5. Replica loss during OSV, scan, cleanup, and storage-transfer tasks

Unpublished evidence

No ready-made capacity profile, node count, failover acceptance result, RTO/RPO, or SLA is published.

Evidence required for publication

This page can move to verified only after publishing a repeatable load profile for a specific release and topology, dated failover results, data-consistency checks, measured recovery times, capacity boundaries, and approved operational ownership.

Code, chart, and live-application validation — August 3, 2026

At current source commit 943c2c6, PostgreSQL-backed Spring Session, owner-checked HA job lease heartbeats, reclaimable task and scan leases, and shared-storage readiness were verified in code; the relevant targeted suite passed 31 of 31 tests. Helm lint succeeded, and rendered manifests included an HPA range of 3–10, a minAvailable 2 PDB, RWX claims, hostname and zone spreading, a 60-second termination grace period, and separate startup, readiness, and liveness probes. In the live environment, those health endpoints reported UP and the Support surface was reachable. No cluster topology access or controlled pod, node, PostgreSQL, storage, or ingress fault was available; task-lease handoff, data consistency, and recovery time were not measured. The Awaiting validation status is therefore retained.