Architecture Overview

Satusky is a self-hosted Kubernetes platform running across two Malaysian sites: Kuala Lumpur as primary and Kota Kinabalu as secondary / disaster-recovery region.

Current platform shape

Layer	Current state
User interface	Control panel and 1ctl.
API	Go/Fiber backend with PostgreSQL metadata.
Workloads	Kubernetes Deployments, Services, ConfigMaps, Secrets, PVCs, routes, HPA/VPA/PDB where configured.
Nodes	Talos Linux machines on prosumer hardware.
Networking	Cilium, Cloudflare, kgateway in migration, and ingress-nginx still carrying major production traffic.
Storage	Rook-Ceph for block/file/object storage; CloudNativePG for Postgres on cluster-01.
Observability	Backend status APIs, Kubernetes state, Loki/log paths, metrics endpoints, and platform reliability result packs.

Control-plane model

1ctl / control panel
        |
Satusky API + PostgreSQL
        |
Kubernetes clusters
        |
Pods, Services, PVCs, routes, autoscaling resources

The API is the source of desired state. Kubernetes is the execution substrate.

Current infrastructure limits

• Cluster-01 in Kuala Lumpur is the primary production cluster.
• Cluster-02 in Kota Kinabalu exists for DR work but is below the stateful failover design floor.
• Cluster-02 Ceph has one monitor and one OSD, so it has no quorum or replication fault tolerance.
• CNPG is not installed on cluster-02.
• DR for stateful workloads is backup/restore oriented today, not live cross-cluster database replication.
• ingress-nginx still carries customer and internal hostnames while kgateway migration continues.

Tenant state

The platform currently serves one production tenant, Futurify Labs, alongside internal Satusky workloads. Tenant isolation exists through Kubernetes namespace and policy boundaries, with quota/admission hardening still part of the operational hardening path.