Architecture

Multi-cluster Kubernetes infrastructure designed for isolation, reliability, and operational simplicity.

Table of contents

1. Cluster Topology
   1. Shared Cluster
   2. Environment Clusters
2. Per-Client Isolation
3. GitOps Deployment Model
4. Network Architecture
   1. DNS and Routing
   2. Service Mesh
   3. External Access
5. Infrastructure Platform

---

Cluster Topology

Canton NaaS runs on a hub-and-spoke architecture across multiple Google Kubernetes Engine (GKE) clusters in European regions.

graph TB
    subgraph shared["Shared Cluster (Hub)"]
        argocd[ArgoCD<br/>GitOps Engine]
        keycloak[Keycloak<br/>Identity Provider]
        grafana[Grafana<br/>Dashboards]
        prometheus[Prometheus<br/>Central Metrics]
        ingress[NGINX Ingress<br/>Load Balancer]
    end

    subgraph devnet["Devnet Cluster"]
        dev_clients["Client Namespaces<br/>(Development)"]
        dev_agent[Prometheus Agent]
    end

    subgraph testnet["Testnet Cluster"]
        test_clients["Client Namespaces<br/>(Pre-Production)"]
        test_agent[Prometheus Agent]
    end

    subgraph mainnet["Mainnet Cluster"]
        main_clients["Client Namespaces<br/>(Production)"]
        main_agent[Prometheus Agent]
    end

    argocd -->|manages| devnet
    argocd -->|manages| testnet
    argocd -->|manages| mainnet

    dev_agent -->|remote write| prometheus
    test_agent -->|remote write| prometheus
    main_agent -->|remote write| prometheus

    prometheus --> grafana

Shared Cluster

The hub cluster runs centralized platform services:

• ArgoCD — GitOps deployment engine that manages all clusters from a single control plane
• Keycloak — OIDC identity provider with per-client authentication realms
• Prometheus — central metrics store that aggregates data from all environment clusters
• Grafana — visualization dashboards accessible to operators and clients
• NGINX Ingress — external load balancer and TLS termination point

Environment Clusters

Each environment cluster (Devnet, Testnet, Mainnet) runs client workloads in isolated namespaces. The clusters share identical infrastructure configurations, ensuring that what works in Devnet behaves the same in Mainnet.

---

Per-Client Isolation

Every client receives a dedicated Kubernetes namespace containing all resources needed to operate their Canton nodes. No resources are shared between clients.

graph TB
    subgraph ns["Client Namespace"]
        direction TB
        validator[Splice Validator<br/>Node]
        participant[Splice Participant<br/>Node]
        postgres[(PostgreSQL<br/>Database)]
        
        subgraph security["Security Layer"]
            gateway[Istio Gateway<br/>+ VirtualServices]
            tls[TLS Certificate<br/>Let's Encrypt]
            secrets[Secret Store<br/>GCP Secret Manager]
        end

        subgraph monitoring["Monitoring"]
            podmon[Pod Monitoring<br/>Metrics Scraping]
            ipwl[IP Whitelist<br/>Authorization Policy]
        end

        validator --> postgres
        participant --> postgres
        gateway --> validator
        gateway --> participant
        secrets --> validator
        secrets --> participant
    end

Each namespace includes:

Component	Purpose
Splice Validator	Canton consensus node with wallet and transfer capabilities
Splice Participant	Ledger API node exposing gRPC and JSON APIs
PostgreSQL	Dedicated database instance on premium SSD storage
Istio Gateway	Per-client ingress with TLS termination and routing rules
TLS Certificate	Automated Let’s Encrypt certificate for client endpoints
Secret Store	Isolated GCP Secret Manager integration via External Secrets Operator
Pod Monitoring	Prometheus metrics scraping with namespace-scoped access
Authorization Policy	IP-based access control for sensitive endpoints

---

GitOps Deployment Model

All infrastructure is defined as code and managed through Git:

graph LR
    git[Git Repository] -->|push| argocd[ArgoCD]
    argocd -->|sync| k8s[Kubernetes Clusters]
    k8s -->|status| argocd
    argocd -->|drift detection| argocd

1. Every change goes through Git — infrastructure modifications are proposed as pull requests, reviewed, and merged
2. ArgoCD reconciles automatically — desired state in Git is continuously compared to the actual cluster state
3. Self-healing — if a resource drifts from its declared state, ArgoCD restores it automatically
4. Rollback — reverting a change is as simple as reverting a Git commit
5. Full audit trail — Git history provides a complete log of who changed what and when

---

Network Architecture

DNS and Routing

Each client receives dedicated DNS entries following the pattern:

<service>.<client>.<environment>.naas.noders.services

For example:

• validator.acme-01.mainnet.naas.noders.services
• participant.acme-01.mainnet.naas.noders.services

Service Mesh

Istio service mesh handles all internal communication:

• Mutual TLS (mTLS) — all pod-to-pod traffic is encrypted and authenticated
• Traffic management — fine-grained routing rules per client
• Authorization policies — network-level access control between services

External Access

Client-facing endpoints are exposed through:

• NGINX Ingress Controller with external load balancer
• TLS termination with automatically renewed certificates
• Per-client Istio VirtualService routing

---

Infrastructure Platform

Aspect	Technology
Cloud Provider	Google Cloud Platform (GCP)
Kubernetes	Google Kubernetes Engine (GKE)
Regions	Europe (multi-region)
Storage	Premium SSD persistent volumes
Key Management	GCP Cloud KMS
Secrets	GCP Secret Manager
DNS	Cloudflare
Certificates	Let’s Encrypt via cert-manager
Service Mesh	Istio
GitOps	ArgoCD
Monitoring	Prometheus + Grafana