1. Introduction and Goals

The Pandur cluster is the production Kubernetes cluster of Kaiserpfalz EDV-Service, running on Hetzner Cloud. It hosts the workloads of Kaiserpfalz EDV-Service and several related organizations (Paladins-Inn, Torg Codex).

This repository, cluster-gitops, is the single source of truth for the cluster: every add-on, operator, and application deployed onto Pandur is described here and reconciled onto the live cluster by Argo CD. Nothing is changed on the cluster by hand; every change starts as a commit to this repository.

The repository has three connected layers:

  1. pandur-cluster-bootstrap/ — the documented, mostly one-off infrastructure bootstrap (Cluster API/CAPH plus OpenTofu) that creates the Hetzner network and the Kubernetes nodes themselves.

  2. pandur/ — the workload-cluster GitOps layer. Argo CD Application resources reconcile Helm charts and raw manifests onto the running cluster.

  3. helm/ — reusable, organization-authored Helm charts used by application repositories outside this cluster’s own add-ons.

This documentation focuses on the second layer — the Pandur cluster itself, its building blocks, and how it is bootstrapped and operated — since this is what cluster-gitops actually builds and owns.

1. Requirements Overview

  • The cluster must run the shared add-ons (ingress, certificates, secrets, storage, database operators, observability) needed by all workloads hosted on it, so that individual application repositories do not need to re-implement infrastructure concerns.

  • All cluster configuration must be described declaratively in Git and reconciled automatically, so that the running state of the cluster can always be reproduced from, and compared against, this repository.

  • Users authenticate against the cluster and its administrative tools (Kubernetes API, Argo CD, Grafana, Headlamp, …​) with the same identity, provided by a single external OpenID Connect provider (Keycloak).

  • Stateful workloads (PostgreSQL via CloudNativePG, Keycloak’s own database, …​) must be backed up automatically to object storage.

  • The cluster is Hetzner-only infrastructure without public IPv4/IPv6 on the nodes themselves; all inbound traffic is terminated by a Hetzner Load Balancer in front of the ingress controller, and all outbound traffic is routed through a dedicated NAT gateway.

2. Quality Goals

Table 1. High level quality requirements
Requirement Description

Reliability

  • The cluster and the applications hosted on it have to be available 24/7; there is no accepted maintenance window ([CP-001 No Maintenance Window ]).

  • Stateful data has to be recoverable after node or volume loss.

Maintainability

Security

3. Stakeholders

Role/Name Contact Expectations

Cluster Owner / Operator

Kaiserpfalz EDV-Service (klenkes74)

Operate the cluster as a small team ("full army of myself, me, and I"); every operational task must be possible via Git commits and Argo CD, without manual kubectl apply.

Application teams (Paladins-Inn, Torg Codex, Kaiserpfalz EDV-Service repositories)

via auto-applications.yml

Rely on the shared add-ons (ingress, TLS, database operators, storage, secrets, observability) being available, versioned, and stable, without needing to operate them themselves.

End users of hosted applications

 — 

Expect the applications hosted on Pandur to be reachable 24/7 and to be able to log in with their existing organization account (Keycloak SSO).

Hetzner Cloud

Infrastructure provider

Provides the compute, network, load balancer, and block storage resources the cluster runs on.