neuraltrust-platform,
with one value selecting the topology:
Infrastructure dependencies
The chart can run every datastore in-cluster for evaluation. Recommended for production is managed PostgreSQL and Redis (deploy: false plus a host you
provide) with ClickHouse left in-cluster. The in-cluster default exists so a
proof of concept can helm install without provisioning those services first.
Redis is not optional and it is not only a cache: TrustGate uses it for rate
limiting and semantic caching on the request path. Redis OSS is sufficient —
there is no Enterprise-only feature in use. The chart’s in-cluster Redis runs a
plain
redis-server.
Ports between components
In-cluster hops are plain Services; there is no service mesh requirement.
What has to cross a network boundary depends on the model, and each model page
carries its own rules: Hybrid needs
outbound HTTPS to NeuralTrust plus one inbound source IP,
External needs neither, and
Central needs the same outbound
set as Hybrid but against your own domain, with the central cluster accepting it.
Capacity
Kubernetes schedules a pod only onto a node with enough unreserved capacity to cover the pod’s resource requests. Cluster size is therefore set by the chart’s default requests rather than by traffic: the node counts below are the smallest pools on which every component of a new installation can be scheduled. Treat them as the minimum of an autoscaling node pool, and let the cluster add nodes as load grows.
Each count allows for the cluster’s own components — the node’s system
reservation, DaemonSets, and kube-system — and keeps total requests at or below
85 % of allocatable capacity. The remaining 15 % absorbs the extra pod a rolling
upgrade creates. With one node fewer, the installation cannot be scheduled.
Where a single node would be enough, the table specifies two, so that the two
replicas of the request path run on different nodes.
The GPU column assumes the
GPU Firewall configuration,
including CUDA MPS sharing with four clients per GPU.
What the chart requests
These totals sum the requests of every replica and sidecar in the default render, with the request path at two replicas and PostgreSQL and Redis running in the cluster. Values are rounded up to whole vCPU and GiB.
Using managed PostgreSQL and Redis lowers memory requests by 2 GiB. The totals
exclude the node’s system reservation, DaemonSets, kube-system, and your ingress
controller or Gateway; the node counts above already allow for them.
Requests describe what the scheduler reserves, not the throughput an
installation sustains. Measure under your own traffic before tuning.
To adapt capacity to your workload, scale out the gateway and TrustGuard
replicas that carry the most traffic, or enable horizontal pod autoscaling once
the cluster exposes metrics. Run only the Firewall detectors you use, and pin
workloads to a dedicated node pool when they must be isolated from other tenants
of the cluster.
Datastore sizing floors
Not required
Deployments sometimes budget for these because older material mentioned them, or because comparable products need them. Platform v2 does not:
If you are working from documentation or a diagram that shows Kafka, AISPM,
Agent Guardians, or a control-plane Scheduler, it describes the retired v1
platform, not this one.