TürkçeDemo
Menu

Installation

Topology requirements and unpublished boundaries

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

Content statusAwaiting validationDocumentation versionLatest

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 provides multiple replicas, HPA, PodDisruptionBudget, startup, readiness, and liveness probes, graceful termination, and topology-spread fields. These are platform mechanisms, not measured high-availability outcomes or a ready-made SLA.

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

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.