R2-D2
Dashboard
Node Red
Restreaming
The Force
UpdatedNever
v1.0.0

Overview

Loading…
R2-D2
Dashboard
Node Red
Restreaming
The Force
UpdatedNever
v1.0.0
DDroidspeak / Docs
Operator handbook
Droidspeak
What is R2-D2?
Runtime architectureAuth — Keycloak migration plan
FleetRestreamingGalaxy MapThe RepublicTemple ArchivesSTANAG 4817The Force
Tech StackNext.js 15 + React 19Tailwind v4ZustandTanStack Table + DataViewhls.jsLow-latency playerreagraphoglreact-grid-layoutMonacoScalar API Referencefumadocs
Cluster InfraTrailBaseReductStoreRestreamer (datarhei/core)TBMQKeycloakLonghornkube-vipIngress (Caddy + nginx-ingress + Traefik)Netbird
Operator QA Runbook
Install — RKE2Install — Dokploy
Contributor guideRelease Notes
Cluster Infra

Ingress (Caddy + nginx-ingress + Traefik)

The edge routing model — *.office.ilab.zone via Caddy, port 80 via Traefik, in-cluster via nginx.

R2-D2's edge layer is three components doing different jobs. Get the mental model straight before touching any of them.

Layer-by-layer

flowchart LR
  Internet --> Caddy["Caddy (*.office.ilab.zone)"]
  Caddy -->|HTTPS, host header preserved| Nginx["nginx-ingress on 192.168.3.211–214:8080"]
  Internet --> Traefik["Traefik (port 80)"]
  Nginx --> Svc[Service VIPs via kube-vip]
  Traefik --> Svc
ComponentRoleNotes
CaddyPublic-facing reverse proxy for *.office.ilab.zone hostnamesTerminates TLS, forwards to nginx-ingress
nginx-ingressIn-cluster ingress controller for the dashboard + most servicesLives behind a fixed set of VIPs
TraefikHandles port-80 trafficDistinct from nginx — different ruleset, easy to confuse

The Caddy → nginx convention

*.office.ilab.zone Caddy always proxies to nginx-ingress at 192.168.3.211–214:8080. It never points at kube-vip LBs. This is a load-bearing convention: the kube-vip LBs are for L4 exposure; nginx is the L7 ingress; Caddy is the public edge. Mixing them produces ingress paths that look like they work but bypass the dashboard's host-routing rules.

When adding a new *.office.ilab.zone hostname:

  1. Add a Caddy site directive pointing to 192.168.3.211:8080 (or any of the four — nginx is replicated) with Host header preserved.
  2. Add an Ingress resource in the relevant namespace (nginx class).
  3. Do not also create a LoadBalancer Service for the same hostname.

Port 80 vs everything else

Port 80 traffic is Traefik, not nginx. Two ingress controllers exist because the port-80 ruleset historically lived in Traefik and detaching it has been deferred.

If you're adding HTTPS routing, you want nginx. If you're handling a port-80-specific case (HTTP-only legacy app, ACME HTTP-01 challenge), you want Traefik.

The kube-vip relationship

nginx-ingress sits behind LB VIPs allocated by kube-vip. The four IPs 192.168.3.211–214 are kube-vip-assigned; Caddy points at them directly rather than at a DNS name so it doesn't depend on cluster-DNS for edge routing.

Operator quick-reference

SymptomFirst check
*.office.ilab.zone returns 502Caddy → nginx path; check nginx pod logs first
HTTPS works, HTTP redirect loopsTraefik vs nginx confusion — confirm which controller owns the route
New Ingress resource not picked upingressClassName — must be the nginx class, not the Traefik class
LB IP not respondingkube-vip lease — see kube-vip

See also

  • kube-vip — the LB IPs that nginx binds to
  • Netbird — overlay VPN for cross-site reachability

kube-vip

LoadBalancer VIP allocation — IP reservations, lease tuning, and the .200 invariant.

Netbird

Overlay VPN — cross-site reachability and the daemon socket the dashboard probes through.

On this page

Layer-by-layerThe Caddy → nginx conventionPort 80 vs everything elseThe kube-vip relationshipOperator quick-referenceSee also