Legend — Terminology & Layers¶
This page defines the vocabulary used throughout the documentation. The platform is described as a stack of six layers, from the physical hardware at the bottom to the end-user application services at the top. Every component named elsewhere in these docs belongs to exactly one of these layers.
flowchart TB
L6["6 · Application Services<br/>Core Service · Assistant Service · KMS · Frontend"]
L5["5 · Application Dependency Apps<br/>Hatchet · Weaviate · Zitadel · Foundry · Qdrant · OpenSearch · Redis"]
L4["4 · Platform Apps<br/>GitLab · ArgoCD · Vault · ESO · Reloader · cert-manager · CNPG"]
L3["3 · RKE2 — Kubernetes Cluster<br/>control plane + CPU/GPU workers"]
L2["2 · Virtual Servers (VMs + server roles)<br/>BIND · HAProxy · AppHAProxy · NTP · PKI · Ceph · Harbor"]
L1["1 · Hardware<br/>physical bare-metal servers (with / without GPU)"]
L6 --> L5 --> L4 --> L3 --> L2 --> L1Rule of thumb: each layer runs on the one below it. Hardware hosts Virtual Servers; Virtual Servers host the RKE2 cluster; RKE2 runs the Platform Apps; Platform Apps deliver and secure the Application Dependency Apps and Application Services.
1 · Hardware¶
Definition: the physical, bare-metal servers that everything else runs on. Two classes:
| Class | Description | Examples in this environment |
|---|---|---|
| Compute (no GPU) | General-purpose servers that host virtual machines and distributed storage | HPE DL385 Gen11 — kvm1-3, worker4-7 |
| GPU compute | Servers with GPUs, used as bare-metal Kubernetes workers for AI/ML workloads | HPE DL380a Gen12 — gpu1-7 (8× NVIDIA H200 NVL each) |
2 · Virtual Server¶
Definition: a VM (virtual machine) running on the hardware, together with the server role(s) installed on it. These provide the foundational infrastructure services the platform depends on — they are not Kubernetes workloads.
| Role | What it does | Where |
|---|---|---|
| BIND | DNS — resolves all cluster hostnames | infra1/2 |
| HAProxy | Load balancer for the Kubernetes API and control-plane traffic | infra1/2 |
| AppHAProxy | Load balancer / entry point for application ingress traffic | infra tier |
| NTP | Time synchronisation across all nodes | infra1/2 |
| PKI | Internal certificate authority (Step-CA) for TLS | infra1/2 |
| Ceph | Distributed storage — block (RBD), filesystem (CephFS), object (S3/RGW) | kvm1-3, worker4-7 |
| Harbor | Private container image registry | harbor1/2 |
Other Virtual Servers in this environment: bastion1/2 (jump hosts), gitlab1, reposerver1
(RPM mirror), daytona1 (dev environments), vascan1, logserver1. See the full list in
Resource Inventory → Supporting VMs.
3 · RKE2 — the Kubernetes Cluster¶
Definition: RKE2 is the Kubernetes distribution that forms the container-orchestration layer. It runs on the Virtual Servers (control plane + CPU workers) and on the GPU hardware (bare-metal GPU workers). Everything in layers 4–6 is a Kubernetes workload running inside RKE2.
| Term | Meaning |
|---|---|
| Control plane | The 3 master nodes running the Kubernetes API + etcd |
| CPU worker | Worker node (VM) that runs general workloads |
| GPU worker | Bare-metal worker node with GPUs for AI/ML workloads |
| Namespace | Logical partition inside the cluster (e.g. ask, hatchet, argocd) |
4 · Platform Apps¶
Definition: the platform tooling deployed into the Kubernetes cluster that delivers, secures, and operates everything above it. These are shared across all application services and are deployed once per environment.
| App | Role |
|---|---|
| GitLab | Git source + Helm chart registry — the source of truth ArgoCD deploys from |
| ArgoCD | GitOps engine — reconciles the cluster to match Git |
| Vault | Secrets management — the source of truth for all tokens, passwords, keys |
| ESO (External Secrets Operator) | Syncs secrets from Vault into native Kubernetes Secrets |
| Reloader | Restarts workloads automatically when their config/secret changes |
| cert-manager | Issues TLS certificates from the internal CA |
| CNPG (CloudNativePG) | Operator that manages the HA PostgreSQL database clusters |
See Platform Deployment → Base-Layer Service Guides.
5 · Application Dependency Apps¶
Definition: supporting applications that the Application Services depend on to function. They are not the product themselves, but the product cannot run without them. Deployed per application group.
| App | Role | Used by |
|---|---|---|
| Hatchet | Durable workflow / async task engine | core-service, KMS |
| Weaviate | Vector database for semantic (RAG) search | KMS |
| Zitadel | Identity provider (IdP) bundled with core-service | all services (auth) |
| Foundry | Internal LLM model-serving endpoint + routing | assistant-service, KMS |
| Qdrant | Vector database | assistant-service |
| OpenSearch | Lexical (BM25) search index | KMS |
| Redis | In-memory cache / queue | assistant-service |
6 · Application Service¶
Definition: the ASK product services themselves — the end-user-facing applications this whole platform exists to run.
| Service | Role |
|---|---|
| Core Service | IAM / org / catalog — bundles Zitadel; everything authenticates through it |
| Assistant Service | Agent / chat service (API + intelligence + tooling + workers) |
| KMS (Knowledge Management Service) | Document ingestion + RAG (vector + lexical search) |
| Frontend | The ASK web UI — the browser entry point |
See Application Services.
Quick reference¶
| Layer | One-line definition | Examples |
|---|---|---|
| Hardware | Physical bare-metal servers (with/without GPU) | HPE DL385 Gen11, HPE DL380a Gen12 (GPU) |
| Virtual Server | VMs + infra server roles | BIND, HAProxy, AppHAProxy, NTP, PKI, Ceph, Harbor |
| RKE2 | The Kubernetes cluster | control plane, CPU/GPU workers |
| Platform Apps | Shared platform tooling in K8s | GitLab, ArgoCD, Vault, ESO, Reloader, cert-manager, CNPG |
| Application Dependency Apps | Apps the services depend on | Hatchet, Weaviate, Zitadel, Foundry, Qdrant, OpenSearch, Redis |
| Application Service | The ASK product services | Core Service, Assistant Service, KMS, Frontend |