Networking Pitfalls

k3s ClusterIP Broken From Inside Pods

WRONG: Using 10.43.0.1:443 (Kubernetes API) from inside pods RIGHT: Use service DNS names (e.g., admin-ui.ge-system.svc.cluster.local) IMPACT: Connection refused. The default ClusterIP for the Kubernetes API is broken on this single-node k3s cluster. SCOPE: Affects any pod trying to reach the k8s API directly.

DNS From Executor Pods Is Unreliable

ISSUE: Executor pods intermittently fail to resolve admin-ui.ge-system.svc.cluster.local ERROR: "Could not resolve host" WORKAROUND: Host cron runs scripts/k8s-health-dump.sh → writes to admin-ui/public/k8s-health.json IMPACT: Agent sessions that curl the discussion API may fail. Discussion participation is unreliable. ROOT CAUSE: Unknown — may be CoreDNS cache or k3s single-node DNS behavior.

Redis Port Confusion

WRONG: Assuming Redis is on default port 6379 RIGHT: GE Redis is on port defined in config/ports.yaml (currently 6381) HISTORY: Port 6379 was used by PME (PromoCat) Docker containers. PME containers stopped 2026-02-15. GE Redis runs as a k8s StatefulSet in ge-system namespace on 6381. ADDITIONAL: Redis at 6381 is only reachable from INSIDE the k8s cluster (ClusterIP service, headless). Not accessible from the host directly. AUTHORITY: config/ports.yaml is the ONLY source of truth for port assignments.

Traefik Ingress

ISSUE: Traefik runs as 2 replicas in ge-ingress namespace EXTERNAL IP: 192.168.1.85 (LoadBalancer service) TLS: Let's Encrypt via cert-manager GOTCHA: ACME challenge requires port 80 open — don't block it in firewall rules DOMAINS: office.growing-europe.com, wiki.growing-europe.com, grafana.growing-europe.com, gitlab.growing-europe.com, www.growing-europe.com

Internal Service DNS Reference

DNS	Service	Port
redis.ge-system.svc.cluster.local	Redis	from config/ports.yaml
vault.ge-system.svc.cluster.local	Vault	8200
admin-ui.ge-system.svc.cluster.local	Admin UI	80
wiki.ge-wiki.svc.cluster.local	Wiki	80
loki.ge-monitoring.svc.cluster.local	Loki	3100

hostNetwork: true — NEVER USE

ISSUE: Using hostNetwork: true in pod specs causes port conflicts during rolling updates IMPACT: Two pods try to bind the same host port — one fails, deployment hangs RIGHT: Use ClusterIP services and service DNS. Never hostNetwork.