Infrastructure prerequisites¶
What the client makes available before the installation of the TRADEVAL platform can start. The version handed to the client is a Word document generated from this same source; this page is its readable counterpart.
The deployment relies on Kubernetes, on Talos Linux v1.13 nodes, with a clustered data layer installed on dedicated virtual machines, outside the cluster.
Target capacity¶
The sizing described here supports 1,000 concurrent users in read workloads.
It derives from a load campaign on 2026-08-08: the configuration held 900 concurrent users at 177 requests per second for a 1.02 % failure rate. The 1,000 tier comes from the CPU and memory margin added to the measured sizing, not from extrapolating a breaking point.
Deployment model¶
The Kubernetes cluster¶
Seven virtual machines: three control-plane nodes carrying the API and the cluster state, three compute nodes carrying the applications and the Longhorn replicated storage, and one jump server for administration.
The data layer¶
Thirteen virtual machines, outside the cluster. The lifecycle of a database is not that of a pod: a Talos upgrade, a node drain or a memory eviction are normal events for a stateless service, and incidents for a database.
Every service is deployed as a cluster, never as a single machine. An isolated machine would carry the unavailability of the whole platform on its own.
Public exposure¶
No inbound port is open on the cluster from the Internet. An internal component,
cloudflared, opens an outbound encrypted connection to the Cloudflare network, which
handles TLS termination, application filtering and DDoS protection upstream.
Only three addresses are public: the hub, the user portal and the authentication page. The internal portal appears nowhere on the Internet.
The consequence matters to the network team: what has to be allowed is not an inbound flow towards the cluster, but an outbound flow from the cluster.
Resources to make available¶
Virtualisation capacity¶
| Resource | Quantity |
|---|---|
| Physical cores | 48 |
| Memory | 384 GiB |
| NVMe storage | 8 TB |
| Network | 2 x 10 GbE interfaces |
| Hypervisor | VMware ESXi 8.0 or later |
| Physical servers | 3, recommended |
The twenty machines total 84 vCPUs against 48 physical cores, a ratio of 1.75. This CPU overcommit is deliberate: the twenty machines do not peak at the same instant. Memory, on the other hand, is not overcommitted.
Virtual machines¶
Digitek Consulting creates and configures these twenty machines. The table details their consumption, whose total determines the capacity requested above.
| Role | Qty | vCPU | Memory | Disks |
|---|---|---|---|---|
| Kubernetes control-plane node | 3 | 4 | 16 GiB | 100 GB NVMe (system) |
| Kubernetes worker node | 3 | 8 | 32 GiB | 100 GB NVMe (system) + 250 GB NVMe (replicated storage) |
| Jump server | 1 | 2 | 8 GiB | 100 GB |
| PostgreSQL node | 3 | 4 | 16 GiB | 500 GB NVMe |
| etcd node | 3 | 2 | 8 GiB | 100 GB NVMe |
| Kafka broker | 3 | 4 | 16 GiB | 200 GB NVMe |
| MinIO node | 4 | 4 | 16 GiB | 500 GB NVMe |
| Total | 20 | 84 | 336 GiB | about 5.9 TB |
A second disk is mandatory on every worker
The 250 GB disk dedicated to replicated storage must be a separate virtual disk from the system disk, not a partition of it. The cluster storage layer cannot start otherwise.
Two replicas of the same component, such as two PostgreSQL nodes, must never share physical storage: clustering would then protect nothing.
Network addressing¶
| Item | Role | To provide |
|---|---|---|
| Virtual machine addresses | individual addressing of the twenty machines | 20 fixed IP addresses |
| PostgreSQL access point | stable address of the primary node, which follows failover | 1 fixed IP address |
| Control-plane access point | cluster administration | 1 fixed IP address |
| Cluster virtual address | single entry point of the platform | 1 fixed IP address |
| Virtual address range | publication of the platform services | 10 contiguous addresses minimum, including the previous one |
| Container subnet | cluster-internal network | 1 unused private /16 range on the network |
| Service subnet | cluster-internal network | 1 unused private /12 range on the network |
The last two ranges are internal to the cluster but must not overlap any existing network, otherwise some destinations become unreachable from the platform.
Domain name and mail¶
A dedicated domain name, delegated to the Cloudflare DNS provider before the start, and the matching zone identifier. The Cloudflare account serves two purposes: automatic TLS certificate issuance and establishing the publication tunnel.
The account also provides an API token, scoped to that single zone, carrying exactly two permissions, no more and no less: edit the zone's DNS records, and read the zone. That token is used only for certificate issuance. Validation goes through DNS rather than the web, since only DNS validation covers every subdomain without publicly exposing each internal service.
An SMTP relay reachable from the cluster, with its sender address, port and credentials. Without this relay the platform works, but emits no notification, and that defect produces no visible error.
Network flows¶
Every flow below has to be allowed. The first three are only detectable once the installation has started: validating them beforehand avoids interrupting the intervention window. "The six cluster nodes" means the three control-plane nodes and the three workers, excluding the jump server.
| From | To | Port | Role |
|---|---|---|---|
| The six cluster nodes and the operator workstation | Public DNS resolvers | 53 | Name resolution. To validate before the start |
| The six cluster nodes and the operator workstation | Image registries and the platform repository | 443 | Component download. To validate before the start |
The cluster (cloudflared) |
Cloudflare network | 7844 UDP and TCP | Publication tunnel. Without this outbound flow, the public platform does not start. To validate before the start |
| Operator workstation | Control-plane nodes | 50000 | Talos administration |
| Operator workstation | Cluster virtual address | 6443 | Kubernetes administration |
| The six cluster nodes | Data layer PostgreSQL, Kafka, MinIO | 5432, 9092, 9000 | Access to the data layer |
| Data layer machines, between themselves | Data layer machines | 5432, 2379 and 2380, 9092, 9000 | PostgreSQL replication, etcd arbitration, Kafka and MinIO replication. Internal flows required for high availability |
| The six cluster nodes | Mail relay | 25 or 587 | Platform notifications and monitoring alerts |
| The twenty machines | NTP time server | 123 | Clock synchronisation. Clock drift makes the clusters lose quorum and invalidates certificates |
| The client's internal workstations | Cluster virtual address | 443 | Access to the internal portals from the internal network |
The destinations of the 443 flow are named, since a rule per category is not actionable by a
network team: github.com, factory.talos.dev, charts.longhorn.io,
charts.external-secrets.io, grafana.github.io, prometheus-community.github.io, the
platform image registry and the public registries of the upstream images.
factory.talos.dev
This destination carries the node installation image, with the iSCSI extension without which replicated storage does not start. It also serves every version upgrade: the flow remains necessary after the installation.
Access to provide¶
Access to the VMware web interface lets Digitek Consulting create and configure the twenty virtual machines, without client involvement at every step.
Division of responsibilities¶
Backup, monitoring and restoration of the twenty virtual machines are handled by Digitek Consulting, as are their creation and operation. The client does not have to administer the cluster or the data layer.
One dependency remains on that side: a backup that never leaves the server protects nothing. The client therefore makes available a backup space located outside the virtualisation host, to which Digitek Consulting exports the backups.
Checklist before starting¶
- [ ] Virtualisation capacity available: 48 cores, 384 GiB, 8 TB NVMe
- [ ] VMware ESXi 8.0 or later hypervisor, two 10 GbE interfaces
- [ ] Three physical servers, or a deliberate decision to provide only one
- [ ] Twenty fixed IP addresses reserved
- [ ] PostgreSQL and control-plane access points reserved, one fixed IP address each
- [ ] Cluster virtual address and range of ten contiguous addresses reserved
- [ ] Two internal private ranges chosen, not overlapping the existing network
- [ ] Domain name delegated to Cloudflare, zone identifier and API token communicated
- [ ] Flows in the table above allowed, with outbound 53, 443 and 7844 tested
- [ ] SMTP relay reachable, with sender address and credentials
- [ ] NTP time server reachable from the twenty machines
- [ ] VMware web interface access opened to Digitek Consulting
- [ ] Backup space outside the virtualisation host available
- [ ] A separate second virtual disk provisioned on each of the three workers