Exodus HA on Azure Kubernetes Service

This is a candidate deployment profile. The licensed Professional and Enterprise HA images, replica admission, fault recovery, and upgrades must pass the release qualification before this profile is offered to customers. A successful Helm render does not qualify an image. No live AKS environment has been tested for this change; local Kubernetes cannot qualify Azure Disk attachment or Azure load-balancer behavior.

Standard supports the basic migration product. HA requires Professional or Enterprise and an eligible license with the signed HA entitlement. A trial can carry that entitlement. Replicas do not consume additional endpoint licenses. Do not share a node-bound license token among unrelated pod identities or remove the runtime's admission checks to bring up the StatefulSet. Offline HA is not supported by this profile.

Topology and availability

The production overlay now uses five validators, each with its own identity and persistent state. The initial customer profile routes traffic to ordinal zero; the other members retain consensus quorum. Recovery stops or fences the old primary and restarts that same ordinal with its retained UUID, keys, license custody and volume on a compatible replacement host. It does not transfer an interrupted migration to a different logical node.

Blossom requires floor(2N/3) + 1 validators:

The AKS overlay requires a separate schedulable worker node for every validator. This placement is necessary for its one-node failure target. It does not establish physical host independence in a local container cluster. Five validators spread across three zones cannot retain quorum after losing every possible zone; do not describe this topology as zone-failure tolerant.

minAvailable: 4 protects voluntary eviction of the five-member deployment. The chart rejects a production PDB below quorum, percentages, a disabled PDB, and maxUnavailable. A PDB does not prevent involuntary failures, StatefulSet updates, or unsafe simultaneous operations. Replace one pod at a time and verify quorum, application readiness, and catch-up before continuing. Do not change membership by editing replicaCount alone.

Azure prerequisites

Use an existing AKS cluster. This chart does not create an Azure subscription, cluster, node pool, database, or certificates.

1. Check that five worker nodes are schedulable and meet the measured workload's

capacity requirements. Example resource requests are starting values, not a capacity guarantee. Retain the zone and hostname spread constraints from the base overlay. A spare schedulable host with compatible Azure Disk placement must be available for replacement after a host failure; required host anti-affinity prevents placing two validators on one worker.

1. Inspect kubectl get storageclass managed-csi-premium -o yaml. Require the

disk.csi.azure.com provisioner and WaitForFirstConsumer. Confirm the actual disk SKU, zone support, retention policy, per-node attachment limits, and cost. Azure billing allocation can exceed the requested PVC size. Every ordinal gets a distinct ReadWriteOnce PVC; never mount one state directory into two Eden processes. Back up the volumes before updating.

1. Provide customer-managed PostgreSQL and ClickHouse and their credentials.

Use the PostgreSQL server DNS name with postgresTls.mode: verify-full. System roots are used by default; supply postgresTls.caSecret for a private CA. Keep PostgreSQL private and verify backup/restore against the same CA.

1. Configure the AKS managed identity's required network permissions. Choose

five unused IPv4 addresses in the actual internal load-balancer subnet, not the Kubernetes Service CIDR. Set a different address for each ordinal in annotationsByOrdinal; the common internal-LB annotation applies to all. Per-ordinal values override common values without changing other ordinals. A different subnet also requires the appropriate Azure subnet permissions and common azure-load-balancer-internal-subnet annotation.

1. Restrict UDP 7446 to the required peers and reachable private networks.

Blossom TCP 7445 and cache-sync TCP ports stay private. Populate the exact stable relay addresses in the pre-provisioned production HA configuration. Keep pod discovery available before readiness; the chart's headless Service deliberately publishes not-ready addresses.

1. Provision the existing application, licensing, Blossom identity,

and per-ordinal configuration Secrets described in the README and examples included in your release chart. Follow the customer Helm installation guide first. The PostgreSQL password and license material belong in Secrets, never values files committed to Git. Generate the five unique highAvailability.retainedNodeUuids once and retain their ordinal order. Keep deployment and cryptographic identities on replacement pods; Pod UID is not a retained node identity. Cache-sync Secrets are needed only if that optional subsystem is enabled; the active-passive overlay disables it.

1. Provide TLS termination and authentication at the customer ingress/proxy.

The Eden ClusterIP Service's port 443 forwards HTTP; its name and port do not enable transport encryption. Do not expose it as public HTTPS directly.

Microsoft documents internal load-balancer annotations and private address selection, Azure Disk CSI storage and binding behavior, and PostgreSQL TLS verification.

Download, render and review

Use the release-matched package from the customer Helm repository. The commands below use its unpacked eden-install/vendor/eden directory.

Use the base HA, AKS and active-passive overlays, in that order, and keep your customer-specific values in a private deployment configuration. In that file, replace all example addresses, endpoints, UUIDs, Secret names, and the zero image digest. Select the published, qualified Professional or Enterprise HA digest; a *-single image is not interchangeable with the external HA profile. The chart does not pull or license an image during rendering.

helm lint eden-install/vendor/eden \
  -f eden-install/vendor/eden/examples/production-ha-values.yaml \
  -f eden-install/vendor/eden/examples/aks-ha-values.yaml \
  -f eden-install/vendor/eden/examples/production-active-passive-values.yaml \
  -f /private/path/eden-aks.yaml

helm template eden eden-install/vendor/eden --namespace eden \
  -f eden-install/vendor/eden/examples/production-ha-values.yaml \
  -f eden-install/vendor/eden/examples/aks-ha-values.yaml \
  -f eden-install/vendor/eden/examples/production-active-passive-values.yaml \
  -f /private/path/eden-aks.yaml > /private/path/eden-rendered.yaml

Review five pod-pinned UDP Services, distinct private IP annotations, one StatefulSet, five separate PVC allocations, read-only Secret mounts, verified PostgreSQL TLS, and a PDB requiring four healthy pods. The hostname anti-affinity matches nameOverride: eden-gateway; update that selector if changing the application name. Verify retained ordinal UUIDs, OnDelete StatefulSet updates and the customer Service selector for ordinal zero.

Deployment acceptance and updates

After the exact image and licensed HA path are qualified, deploy the reviewed configuration using the normal Helm upgrade procedure. An atomic Helm operation does not make database schema changes reversible. Confirm schema compatibility and restore procedures before attempting rollback. With OnDelete, a Helm upgrade updates the template without restarting every pod automatically. Stop or fence one old ordinal before replacing it, preserve its identity and PVC, and verify readiness and quorum before proceeding. Never start two processes with the primary's retained state or identity.

Record the image digest and license/deployment identities before and after the update. Verify all five pods and shared PostgreSQL initialization, each node's registration, licensing readiness, Redis migration writes and recovery, per-ordinal storage persistence, relay connectivity, and quorum health. Replace one pod, confirm its state and identity survive, then verify migration progress and request handling while one validator is unavailable. Confirm the license service tracks renewal/replacement without consuming a second endpoint seat.

Crash-interrupted live-write migrations remain fenced with operation_restart_required=true. Restore source routing, preserve the old attempt, reconcile or clean the target through an authorized procedure, then start a fresh attempt. Retained-identity recovery does not automatically resume that work. Downtime depends on your fencing, disk attachment, scheduling, startup and traffic configuration; no fixed recovery time is promised.

The release evidence must separately identify native application tests, local Kubernetes lifecycle tests, and live Azure checks. Azure Disk detach/reattach, internal UDP load-balancer routing and health probes, network policy, and node replacement remain required Azure checks when an AKS environment is available.