yeke.io · docs · enterprise
High Availability (HA)
Run YEKE core with multiple replicas. The console and API remain available during rolling updates; an individual cluster may briefly disconnect while its agent reconnects. PostgreSQL and an Enterprise license are required.
Overview
Two replicas, one Service, one Ingress.
An HA installation runs two core replicas with RollingUpdate. One serves requests while the other updates. A single-replica SQLite installation uses Recreate because of the file lock, so upgrades require a brief interruption.
Prerequisite: PostgreSQL
One license flag turns on both.
The ha-postgres Enterprise entitlement covers both PostgreSQL and multi-replica deployment. HA requires PostgreSQL because multiple core processes cannot share the same SQLite file.
Requirements
Prepare these four requirements before deployment.
- A PostgreSQL connection.
YEKE_DB_URL, pointed at your organization's own PostgreSQL — see the PostgreSQL connection page. - A snapshot key from a Secret, required. In PostgreSQL mode core does not
generate the key — the SQLite-mode fallback ("core generates it and writes it to the data
directory") does not exist here. The key must be supplied externally through
YEKE_SNAPSHOT_KEY. - A headless Service. Replicas reach each other through a mechanism where a replica that does not own a given tunnel proxies an incoming request internally to the replica that does; that proxying needs to address pods directly.
- A license that enables
ha-postgres. A signed license block mounted as a file (YEKE_LICENSE_PATH).
Differences from single-node
Compare single-replica and HA settings.
| Single-node | HA | |
|---|---|---|
strategy | Recreate | RollingUpdate (maxUnavailable: 0, maxSurge: 1) |
replicas | 1 | 2 |
| Persistent data directory | PVC | none — persistence lives in PostgreSQL |
YEKE_DB_URL | unset (SQLite) | Required from a Secret |
YEKE_SNAPSHOT_KEY | optional (core can generate it) | Required from a Secret |
| License | not required | ha-postgres feature required |
readOnlyRootFilesystem | no | yes — in PostgreSQL mode core writes nothing to the filesystem |
Installation
Two files from the single-node install (01-pvc.yaml, the
single-node 02-core-deployment.yaml) are deliberately left out.
# 1) namespace (same as single-node)
kubectl apply -f deploy/kubernetes/00-namespace.yaml
# 2) PostgreSQL connection + snapshot key — BOTH REQUIRED
kubectl -n yeke-system create secret generic yeke-core-secrets \
--from-literal=YEKE_DB_URL="postgres://<user>:<password>@<pg-host>:5432/<db>" \
--from-literal=YEKE_SNAPSHOT_KEY="$(openssl rand -hex 32)"
# 3) signed license block that enables ha-postgres
kubectl -n yeke-system create secret generic yeke-license \
--from-file=license.block=/path/to/license.block
# 4) fill in the version and host placeholders
sed -i '' 's/<YEKE_VERSION>/0.51.2/' deploy/kubernetes/ha/02-core-deployment.yaml
# YEKE_PUBLIC_URL / YEKE_ALLOWED_ORIGINS (ha/02-core-deployment.yaml)
# and host (06-ingress.yaml) — the SAME step as the single-node install
# 5) apply: the base Service + Ingress + the HA directory
kubectl apply -f deploy/kubernetes/03-core-service.yaml \
-f deploy/kubernetes/06-ingress.yaml \
-f deploy/kubernetes/ha/The namespace, Service and Ingress files are the SAME between single-node and
HA; the Service selects by the app: yeke-core label, which applies whether
there's one replica or two. Only the two files under ha/ (deployment + headless
service) replace the single-node pair (01-pvc.yaml +
02-core-deployment.yaml); the two sets are never applied together.
What happens during an upgrade
Two different surfaces, two different behaviors.
- The HTTP/SPA surface. At least one replica always serves requests throughout the
RollingUpdate; the UI and API stay reachable during an upgrade. - The agent tunnel. Each cluster's tunnel is bound to a single replica (the owner). When the owning replica is upgraded, the agent connection drops and re-establishes within a short window; requests to that cluster may fail transiently during that window.
Limits
What's sold is the YEKE layer, not the database underneath it.
- PostgreSQL's own high availability is your organization's job. Clustering, replication, failover and backups — the same boundary as the PostgreSQL connection page.
- Docker-compose installs are out of scope for HA. Running two replicas on one machine does not give you real availability; HA only makes sense on a Kubernetes deploy.
- Nothing works without a license. Without
ha-postgres, the PostgreSQL driver itself does not start — see the license gate.
Archiving deleted records is also PostgreSQL-mode
The same PostgreSQL connection HA depends on is also the prerequisite for long retention and archiving.