2. Architecture Constraints

Table 1. Technical Constraints
ID	Description
CT-001	Infrastructure Provider
CT-001	The cluster runs exclusively on Hetzner Cloud (servers, private network, load balancer, block storage) and Hetzner Robot / hidrive (CIFS backup target). No multi-cloud abstraction is used.
CT-002	Kubernetes via Cluster API
CT-002	Nodes are created and managed with Cluster API and the Hetzner provider (CAPH), driven from a temporary local `kind` management cluster. CAPH owns network, subnet, control-plane load balancer, placement groups and the machines themselves.
CT-003	No public node IPs
CT-003	Control-plane and worker nodes intentionally have neither public IPv4 nor IPv6. All outbound traffic is routed through a dedicated NAT gateway created by OpenTofu; all inbound traffic terminates at the Hetzner Load Balancer in front of Traefik.
CT-004	GitOps single source of truth
CT-004	The state of the cluster is entirely described by this Git repository. Argo CD reconciles it with `prune` and `selfHeal` enabled; manual changes on the cluster are expected to be reverted automatically.
CT-005	OpenID Connect only
CT-005	The cluster holds no local user database. Authentication for the Kubernetes API (`oidc-issuer-url`), Argo CD, Grafana and Headlamp is delegated to the organization’s Keycloak realm `k8s`.
CT-006	Ingress Controller
CT-006	Traefik is the cluster’s ingress controller (`ingressClassName: traefik`). It is the only supported ingress class; Helm charts that default to `nginx`-style annotations must be adapted.
CT-007	Secrets via External Secrets Operator
CT-007	Runtime secrets are never stored in Git. They are pulled at runtime by the External Secrets Operator from a Bitwarden Secrets Manager `ClusterSecretStore` and materialized as native Kubernetes `Secret` objects.

Table 2. Organisational Constraints
ID	Description
CO-001	Small Team
CO-001	The cluster is operated by a very small team. All operational tasks must be automatable via GitOps so that day-to-day operation does not require deep, tribal knowledge of manual procedures.
CO-002	Shared Infrastructure
CO-002	The cluster hosts workloads for Kaiserpfalz EDV-Service and related organizations (Paladins-Inn, Torg Codex) via `auto-applications.yml`. Shared add-ons (ingress, storage, database operators, secrets, observability) must remain generic enough to serve all tenants.

Table 3. Political Constraints
ID	Description
CP-001	No Maintenance Window
CP-001	Hosted applications are used around the world and around the clock (e.g. Torg Eternity’s Torganized Play). There is no accepted time window during which the cluster or its ingress may be unavailable for planned maintenance.
CP-002	Data Protection / GDPR
CP-002	Since users and their data are processed within the EU (Hetzner, Germany), the cluster’s data handling (backups, secrets, logging) must be compatible with GDPR requirements.