---
title: "Kubernetes platform — N1 IT Landscape"
---

N1 IT Landscape — The Blueprint · CF-Access internal

# Kubernetes platform

N1 IT Landscape · Owner: Arun Venkataraman · source of truth: markdown SSOT

# N1 IT Landscape — Kubernetes platform

> **CURRENT-STATE** as of **2026-06-09** · part of the **N1 IT Landscape** (start at **[Overview](/landscape/overview/)**). Owner: **Arun Venkataraman** (Principal Engineer).

_What runs inside the two EKS clusters — namespaces, the platform components that hold it together, and the live application workloads._

* * *

## 9\. KUBERNETES PLATFORM (what runs in the clusters)

Both clusters share an identical shape: system/infra in `kube-system`, GitOps in `argocd`, autoscaling in `keda`, secrets sync in `external-secrets`, the model gateway in `llmproxy`, inference in `ai-inference`, telemetry in `monitoring`, and **the N1 application in`staging` / `prod`**.

### 9.1 Namespaces (11 each)

`ai-inference`, `argocd`, `default`, `external-secrets`, `keda`, `kube-node-lease`, `kube-public`, `kube-system`, `llmproxy`, `monitoring`, and `staging` (staging) / `prod` (production).

### 9.2 Platform component versions (live)

Component | Staging | Production  
---|---|---  
Kubernetes | v1.35.4-eks | v1.35.4-eks  
**ArgoCD** | **v3.3.4** | **v3.3.0** (one point release behind)  
ArgoCD Image Updater | v1.0.2 | v1.0.2  
**KEDA** (autoscaler) | 2.18.1 | 2.18.1  
**External Secrets Operator** | v1.3.1 | v1.3.1  
**Karpenter** | 1.9 (sha256) | 1.9 (sha256)  
**pgbouncer** (conn pooling) | v1.25.1-p0 (+ exporter v0.11.1) | v1.25.1-p0  
**OTel collector** | 0.142.0 | 0.142.0  
**cloudflared** (ingress) | `latest` 🔒 unpinned | `latest` 🔒 unpinned  
Ory **Hydra / Kratos / Oathkeeper** | v26.2.0 | v26.2.0  
**Memgraph** / **Qdrant** | 3.8.1 / v1.17.0 | (prod via charts)  
cert-manager | **not installed** (no namespace) — intentional; TLS terminates at Cloudflare | same  
  
### 9.3 Cross-cutting platform behaviours (the "how it all holds together")

  * **Autoscaling — KEDA:** stream-driven. Most workers scale on **`redis-streams`** trigger (queue depth) — `phoenix-parser`, `phoenix-router`, `rosetta-grouper` scale 2→**50** ; `data-validation` 2→10; proxies/pgbouncer scale on `metrics-api`. 🔒 Production has **4 orphaned ScaledObjects** (`grouping-poller-service`, `grouping-service`, `parser-service`, `router-service`) failing because their Deployments were removed but the KEDA objects + ExternalSecrets remain.
  * **Secrets — External Secrets Operator (ESO):** a `ClusterSecretStore` per cluster (`n1-{staging,prod}-cluster-secret-store`) pulls from AWS Secrets Manager into ~25–26 `ExternalSecret` objects (one per service). Pods never hold AWS creds.
  * **Connection pooling — pgbouncer:** runs in the app namespace (2 replicas) in front of Aurora. Used instead of SQLAlchemy's in-app pooling; pooling is controlled outside the application.
  * **DB migrations:** run as **sidecars on pod startup** (Alembic for api-backend/billing, raw SQL for auth, Ory automigration for Kratos/Hydra, LiteLLM built-in). `db-migration-secrets` ExternalSecret present in both clusters.
  * **Ingress:** 🔒 **Cloudflare-tunnel-only.** `cloudflared` (2 replicas, `kube-system`) is the sole ingress. All Services are `ClusterIP`; the one ArgoCD `alb`-class Ingress has no address assigned and there is **no ALB controller** deployed.

### 9.4 Deployed application workloads (the live image = the running version)

**Production namespace`prod`** (deployed tags as of 2026-06-09):

Service | Deployed image tag | Replicas  
---|---|---  
api-backend | `V20260526` | 2  
api-websocket-proxy | `V20260527_1` | 2  
api-proxy / auth-proxy / billing-proxy | `latest` (shared Go image) | 2 each  
authentication-service | `V20260526` | 2  
billing-service (+ worker sidecar) | `V20260526` | 2  
Ory hydra / kratos / oathkeeper | v26.2.0 | 3 / 2 / 3  
phoenix-router | `V20260526` | 2  
phoenix-parser | `V20260526` | 2  
rosetta-grouper | `V20260526` | 2  
forge-sentinel | `V20260526` | 2  
forge-agents-api (forge-runner image) | `latest` | 1  
data-validation-service | `V20260129_1` (staging is on a newer build) | 2  
pdf-converter | `V20251206_1` (Dec 2025 build) | 2  
admin-dashboard | `V20260527_1` | 2  
pgbouncer / mineru | v1.25.1-p0 / `latest` | 2 / 1  
CronJobs | api-backend cleanup (hourly), billing meter-events (every min), billing nightly reconciliation (03:00) |   
  
**Staging namespace`staging`** additionally runs the **evals suite** (parser/router/grouper-evals), **automated-testing** , **helix-parser** , **rosetta-genetics-grouper** , **n1-api-slack-bot** , plus in-cluster **memgraph** \+ **qdrant** stateful stores. (Full staging table: see source inventory.)

* * *

## Network architecture

The full network picture has two dedicated chapters:

  * **[Network — infrastructure& VPC](/landscape/network/)** — VPCs, subnets, CIDRs, routes, peering, NAT/egress, security groups, ingress map.
  * **[Network — service-to-service map](/landscape/network-services/)** — which service calls which, on what ports, the Redis-stream topology, and the database port allow-lists.