Infrastructure case study / 2024 to present

CONSTEL·
LATION

Constellation runs identity, mail, documents, support, automation, robotics registries, and private services on seven RKE2 virtual machines across two Proxmox hosts.

EdgeDNS · TLS · Ingress

Control 01RKE2 · etcd

Control 02RKE2 · etcd

Storage 01Longhorn

Storage 02Longhorn

Physical substrateProxmox · ZFS · shared host I/O

Three general workload nodes are omitted here. All seven RKE2 nodes run as virtual machines across two physical hosts.

Physical constraintSeven RKE2 VMs on two Proxmox hosts

Workload scopeBusiness, robotics, and private services

State boundaryReplicated volumes plus managed PostgreSQL

Change boundaryValidate, plan, apply, then verify readiness

01 / The engineering problem

Many products.
One coherent platform.

Problem

Kubernetes redundancy cannot remove failures shared by two physical hosts. Business systems, robotics tooling, and private services also change at different rates while depending on the same identity, networking, storage, databases, and certificates.

Architecture response

I organized the repository by ownership and failure boundary. Shared infrastructure, upstream applications, supported API integrations, and product provisioning change independently; deployment inputs are pinned; protected claims are checked before apply; and readiness is verified afterward.

02 / Platform model

Ownership is part
of the architecture.

Each layer has a different reason to change. Keeping those reasons separate makes upgrades and failures easier to reason about.

Provisioning

Identity, roles, metadata

Idempotent product-level setup through supported interfaces.

Integrations

Replaceable connections

Services communicate through APIs and webhooks without patching upstream images.

Applications

Upstream products + direct dependencies

Mail, documents, support, automation, robotics, registries, and internal tools.

Infrastructure

Shared cluster primitives

Namespaces, storage, certificates, ingress, DNS helpers, databases, and policy.

03 / Platform in practice

The shared systems beneath every workload.

This is the context a service inherits before its own Helm chart or application configuration begins.

01Physical + compute

Redundancy has a physical limit

Control and storage roles are separate inside Kubernetes, but their virtual disks still share each host's ZFS pool. Replica count alone therefore cannot remove host-level I/O as a failure boundary.

02Edge + identity

One entry boundary

kube-vip, Traefik, certificate automation, DNS helpers, and shared identity establish how users and external traffic reach applications.

03Stateful services

Storage and data

Longhorn supplies replicated volumes; CloudNativePG and Valkey provide shared database and cache patterns without embedding those concerns into every product definition.

04Operations

Guarded change

Pinned charts, rendered-manifest validation, explicit planning, readiness verification, retention policy, and break-glass deletion procedures define how the platform changes safely.

04 / Operational guardrails

Safety mechanisms
with honest limits.

Deployments render and validate pinned inputs before apply, then verify release state, workload readiness, protected claims, and direct service health

Local snapshots are documented as rollback points, not disaster recovery; encrypted off-cluster backup remains an explicit outstanding requirement

Admission policy blocks deletion of protected namespaces and storage resources. Material deletion requires a documented break-glass sequence; retained volumes provide a second defence.

Business platform

Identity, mail, documents, support, workflow automation, knowledge, and collaboration.

Robotics platform

Team services, image and package registries, and infrastructure supporting robot development.

Private services

Media, game servers, files, password management, and the shared systems beneath them.

CONSTEL·LATION