Lernpfad: OKD lokal und auf Hetzner/vCloud

2.1 Lernpfad-Varianten

2.2 Architekturüberblick

Lernumgebung
├─ Lokal
│  ├─ CRC/OpenShift Local mit OKD-Preset
│  ├─ Single Node OKD in einer VM
│  └─ UPI-Lab mit Bootstrap + Control Plane + Worker
│
├─ Hetzner
│  ├─ Root-Server/SNO: 1 dedizierter Server, DNS, öffentliche IP, optional Backup
│  ├─ Root-Server/Multi-Node: mehrere dedizierte Server, externer LB, DNS
│  └─ Cloud-VMs/UPI: Server, private Network, Load Balancer, Firewall, Volumes
│
└─ vCloud/vSphere
   ├─ vCenter, ESXi, Datastore, VM-Netzwerk
   ├─ Installer-Provisioned Infrastructure, falls kompatibel
   └─ User-Provisioned Infrastructure, falls Provider-Einschränkungen bestehen

2.3 Entscheidungsmatrix

• Du willst heute anfangen: CRC mit OKD-Preset.
• Du willst Installationsmechanik lernen: lokales SNO oder UPI-Lab.
• Du willst remote und günstig lernen: Hetzner Root-Server mit SNO.
• Du willst Multi-Node und Infrastruktur-Automation üben: Hetzner Cloud/Root-Server mit Terraform + UPI, aber als Lab behandeln.
• Du hast echte VMware/vCloud-Ressourcen: vSphere-Pfad prüfen und mit OKD-vSphere-Dokumentation arbeiten.

3.1 Minimaler Start

Wenn du nur schnell anfangen willst:

mkdir -p okd-learning/{docs,local/crc,apps,hetzner,vcloud-vsphere,scripts}
cd okd-learning
git init

4.1 Fachliche Voraussetzungen

Du solltest vor OKD mindestens diese Themen kennen:

• Linux Shell, systemd, SSH, Journald
• Container-Grundlagen: Images, Container, Registry, Tags
• Kubernetes-Grundlagen: Pod, Deployment, Service, Ingress, ConfigMap, Secret, PVC
• Netzwerk-Grundlagen: DNS, TLS, Load Balancing, Firewall, Subnetze
• Git und YAML
• Terraform/Ansible-Grundlagen, falls du Hetzner/vCloud automatisieren willst

4.2 Lokale Hardware

Für CRC reicht ein aktueller Laptop/Desktop mit Virtualisierung. Plane realistisch:

4.3 Tools

Installiere lokal:

# Pflichtwerkzeuge
podman --version
oc version
openshift-install version
crc version

# Nützlich für Labs
dig +short example.com
jq --version
yq --version
terraform version
ansible --version

4.4 Accounts und externe Ressourcen

Für Hetzner/vCloud:

• Hetzner Cloud Account und API-Token, falls du Cloud-VMs/Load Balancer automatisierst.
• Domain oder Subdomain, die du kontrollierst, z. B. okd.example.com.
• Zugriff auf DNS-Zone.
• SSH-Key für Admin-Zugriff.
• Optional: vSphere/vCloud-Zugang mit Berechtigungen für VMs, Netzwerke, Datastores und Templates.

5.1 Kubernetes-Minimum

Übe in einem beliebigen lokalen Kubernetes, z. B. kind/minikube/k3d:

kubectl create namespace demo
kubectl -n demo create deployment nginx --image=nginx:alpine
kubectl -n demo expose deployment nginx --port=80
kubectl -n demo get all
kubectl -n demo logs deploy/nginx
kubectl -n demo delete namespace demo

Verstehe:

• Warum ein Deployment Pods erzeugt.
• Was ein Service intern auflöst.
• Wie ConfigMaps/Secrets in Pods landen.
• Warum PVCs StorageClasses brauchen.
• Warum Ingress/Route den externen Zugriff kapselt.

5.2 Linux- und Netzwerk-Übungen

Erstelle ein Mini-Lab:

# DNS prüfen
dig api.okd.example.com
dig '*.apps.okd.example.com'

# Ports prüfen
nc -vz api.okd.example.com 6443
nc -vz console-openshift-console.apps.okd.example.com 443

# Zertifikat prüfen
openssl s_client -connect console-openshift-console.apps.okd.example.com:443 -servername console-openshift-console.apps.okd.example.com </dev/null

5.3 Erfolgskriterium

Du kannst erklären:

• Unterschied zwischen ClusterIP, NodePort, LoadBalancer und Route.
• Warum DNS für OKD-Installationen kritisch ist.
• Warum Control Plane, Worker, Ingress und Registry getrennte Rollen haben.

6.1 Begriffe

6.2 Erste oc-Befehle

oc login https://api.<cluster>.<domain>:6443
oc whoami
oc get clusterversion
oc get co
oc get nodes -o wide
oc get projects

oc new-project demo
oc new-app nginx:alpine --name=web
oc expose service/web
oc get route web
oc logs deploy/web
oc delete project demo

6.3 Wichtige Cluster-Objekte

oc get clusterversion
oc get clusteroperators
oc get infrastructure cluster -o yaml
oc get ingresscontroller -n openshift-ingress-operator
oc get authentication cluster -o yaml
oc get console cluster -o yaml

6.4 Lernaufgabe

Deploye eine Beispiel-App mit Route:

oc new-project hello-okd
oc create deployment hello --image=quay.io/openshift/origin-hello-openshift:latest
oc expose deployment hello --port=8080
oc expose svc hello
oc get route hello

Dokumentiere in apps/hello-route/_intern/sources/_intern\sources\README.md:

• Welche Ressourcen erzeugt wurden.
• Welche URL die Route hat.
• Wie du Logs, Rollout und Events prüfst.

7.1 Warum CRC?

CRC/OpenShift Local ist der einfachste Weg, OpenShift/OKD lokal zu starten. Mit dem OKD-Preset bekommst du einen minimalen Single-Node-Cluster für Lern- und Entwicklungszwecke.

7.2 Installation und Start

Die genauen Download-Links und Versionsstände ändern sich. Prüfe vor jedem Setup die aktuelle CRC-Dokumentation.

# Beispielablauf
crc config set preset okd
crc setup
crc start

eval $(crc oc-env)
oc login -u kubeadmin -p "$(crc console --credentials | awk '/kubeadmin/ {print $NF; exit}')" https://api.crc.testing:6443
oc get nodes
oc get co

Alternative Login-Infos:

crc console --credentials
crc console

7.3 Täglicher Workflow

crc status
crc stop
crc start
crc delete

7.4 CRC-Übungen

oc new-project route-demo
oc create deployment web --image=nginxinc/nginx-unprivileged:alpine
oc expose deployment web --port=8080
oc expose svc web
oc get route web

oc new-project config-demo
oc create configmap app-config --from-literal=APP_MODE=dev
oc create secret generic app-secret --from-literal=PASSWORD='change-me'
oc get configmap,secret

oc new-project storage-demo
oc get storageclass
cat <<'YAML' | oc apply -f -
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
YAML
oc get pvc

7.5 Erfolgskriterium

Du kannst:

• CRC starten und sauber zurücksetzen.
• Mit oc einloggen.
• Ein Projekt erstellen.
• Eine App deployen und per Route erreichen.
• ClusterOperator-Status prüfen.

8.1 Single Node OKD lokal

Single Node OKD ist ideal, wenn du Installationsschritte lernen willst, ohne mehrere Control-Plane- und Worker-Nodes zu betreiben.

Konzept:

Admin-PC
  ├─ openshift-install
  ├─ oc
  ├─ install-config.yaml
  └─ ISO/Ignition-Erzeugung

SNO-VM oder SNO-Server
  ├─ OKD Control Plane
  ├─ Worker-Workloads
  ├─ Router/Ingress
  └─ Registry/Monitoring

Wichtige DNS-Namen:

api.<cluster>.<baseDomain>        -> SNO-IP oder API-LB
api-int.<cluster>.<baseDomain>    -> SNO-IP oder interner API-LB
*.apps.<cluster>.<baseDomain>     -> SNO-IP oder Ingress-LB

8.2 UPI-Lab lokal

UPI bedeutet: Du stellst Infrastruktur selbst bereit. Der Installer erzeugt Assets; du kümmerst dich um VMs, DNS, Load Balancer, FCOS/SCOS-Boot und Netzwerk.

                 +----------------------+
                 | Admin/Provisioner    |
                 | oc, installer, httpd |
                 +----------+-----------+
                            |
                            v
+-------------+     +------------------+      +----------------+
| Bootstrap   | --> | Control Plane 1  | <--> | Control Plane 2|
+-------------+     +------------------+      +----------------+
                            |
                            v
                    +------------------+
                    | Control Plane 3  |
                    +------------------+
                            |
                            v
+----------------+  +----------------+  +----------------+
| Worker 1       |  | Worker 2       |  | Worker 3       |
+----------------+  +----------------+  +----------------+

8.3 Lokale Dienste

Du brauchst typischerweise:

• DNS, z. B. dnsmasq, Bind oder echtes externes DNS.
• HTTP-Server für Ignition-Dateien.
• Load Balancer, z. B. HAProxy.
• DHCP oder statische IPs.
• Virtualisierung: libvirt/KVM, VMware Workstation, Proxmox oder vSphere.

8.4 Beispiel HAProxy-Konzept

frontend okd_api
  bind *:6443
  default_backend okd_api_backend

frontend okd_mcs
  bind *:22623
  default_backend okd_mcs_backend

frontend okd_http
  bind *:80
  default_backend okd_http_backend

frontend okd_https
  bind *:443
  default_backend okd_https_backend

8.5 Erfolgskriterium

Du kannst erklären:

• Warum Bootstrap nach der Installation entfernt wird.
• Warum api, api-int und *.apps korrekt auflösbar sein müssen.
• Welche Ports API, Machine Config Server und Ingress benötigen.
• Wie du openshift-install wait-for bootstrap-complete und wait-for install-complete verwendest.

9.1 Hetzner Cloud: was realistisch ist

Hetzner Cloud bietet Cloud-Server, private Networks, Firewalls, Load Balancer, Volumes, Primary IPs und API/Terraform-Integration. Für Kubernetes-Standardcluster ist das sehr beliebt. Für OKD musst du aber sorgfältiger planen, weil OKD keinen „Hetzner IPI“-Installationspfad wie manche großen Cloud-Provider bietet.

Empfehlung für Lernzwecke:

1. Starte mit CRC lokal.
2. Baue danach SNO auf einem Hetzner Root-Server oder lokal.
3. Nutze Hetzner Cloud nur für ein bewusstes UPI-Lab, wenn du DNS, Bootstrapping, Load Balancing und Storage gut verstehst.

Achtung: Hetzner Cloud-Server unterstützen keine Nested Virtualization. Das ist relevant, wenn du innerhalb eines Cloud-Servers nochmals VMs für ein lokales UPI-Lab betreiben willst. OKD-Nodes direkt als Hetzner-Cloud-VMs sind etwas anderes; dafür brauchst du keine Nested Virtualization, aber du musst das OS-/Bootstrapping sauber lösen.

9.2 Hetzner Root-Server

Root-Server sind für OKD-Labs oft einfacher, weil du dedizierte Hardware und mehr Kontrolle hast.

Mögliche Varianten:

9.3 Hetzner Cloud UPI: Zielbild

Internet
  |
  v
Hetzner Load Balancer
  ├─ 6443 -> Control Plane Nodes
  ├─ 22623 -> Control Plane Nodes, Installationsphase
  ├─ 80   -> Worker/Router Nodes
  └─ 443  -> Worker/Router Nodes

Private Hetzner Network
  ├─ bootstrap-0
  ├─ master-0
  ├─ master-1
  ├─ master-2
  ├─ worker-0
  └─ worker-1

Prüfe bei Hetzner immer:

• Private Network und Location/Network-Zone.
• Load-Balancer-Ziele und Health Checks.
• Firewall-Regeln für API, Ingress, SSH und interne Cluster-Kommunikation.
• DNS-Zone für api, api-int und *.apps.
• Storage: OKD braucht zuverlässigen Storage; für etcd sind Latenz und I/O entscheidend.

9.4 vCloud/vSphere

Wenn „vCloud“ bei dir VMware/vSphere bedeutet, prüfe:

• vCenter-Version und ESXi-Kompatibilität.
• Datastore-Kapazität und Performance.
• VM-Netzwerk, DHCP/statische IPs, DNS.
• API-/Ingress-Load-Balancing.
• Rechte für VM-Erstellung, Cloning, Disks, Tags, Folders.
• Ob IPI möglich ist oder du UPI nutzen musst.

vSphere ist im OKD-Installationspfad dokumentiert. Wenn du eine Provider-vCloud hast, kann es Einschränkungen geben, etwa keine ausreichenden Rechte für IPI. Dann ist UPI oft realistischer.

9.5 Entscheidung für dein Lab

Empfohlene Reihenfolge:

1. CRC lokal: Bedienung lernen.
2. SNO lokal oder Hetzner Root-Server: Installation verstehen.
3. UPI lokal: Multi-Node-Mechanik verstehen.
4. Hetzner/vCloud: Architektur automatisieren.
5. Day-2-Betrieb: Monitoring, Updates, GitOps, Backup.

10.1 Minimal: SNO auf Hetzner Root-Server

Domain: okd.example.com
Cluster: lab

api.lab.okd.example.com      -> Server-IP
api-int.lab.okd.example.com  -> Server-IP
*.apps.lab.okd.example.com   -> Server-IP

Vorteile:

• Einfaches DNS.
• Nur ein Server.
• Gute Lernumgebung für OpenShift-Funktionen.

Nachteile:

• Keine Hochverfügbarkeit.
• Updates/Fehler riskanter.
• Nicht repräsentativ für Multi-Node-Produktionsbetrieb.

10.2 Fortgeschritten: UPI auf Hetzner Cloud

Komponenten:

• 1 Bootstrap-Server, temporär.
• 3 Control-Plane-Server.
• 2–3 Worker-Server.
• 1 Hetzner Load Balancer oder eigener HAProxy.
• 1 privates Network.
• Firewalls und DNS.

Beispiel-Ports:

10.3 Terraform-Struktur

# providers.tf
terraform {
  required_providers {
    hcloud = {
      source  = "hetznercloud/hcloud"
      version = ">= 1.45.0"
    }
  }
}

provider "hcloud" {
  token = var.hcloud_token
}

# variables.tf
variable "hcloud_token" {
  type      = string
  sensitive = true
}

variable "cluster_name" {
  type    = string
  default = "okd-lab"
}

Ziel: Nicht blind kopieren, sondern verstehen, welche Ressourcen OKD wirklich braucht.

10.4 DNS-Zonen-Template

api.lab.okd.example.com.       300 IN A <api-lb-ip>
api-int.lab.okd.example.com.   300 IN A <api-lb-ip-or-internal-ip>
*.apps.lab.okd.example.com.    300 IN A <ingress-lb-ip>

10.5 Firewalls

Minimum für externe Zugriffe:

• 6443/tcp nur von Admin-IP oder öffentlich, wenn bewusst.
• 80/tcp, 443/tcp öffentlich für Apps.
• 22/tcp nur Admin-IP oder Bastion.
• Interne Cluster-Ports nur im privaten Netz.

10.6 Storage-Strategie

Für Lernumgebungen:

• Lokaler Storage Operator oder einfache dynamische Provisionierung testen.
• PVCs mit nichtkritischen Daten üben.
• Keine produktiven Daten ohne Backup und getestetes Restore.

Für produktionsähnliche Labs:

• Storage-Latenz messen.
• Backup/Restore testen.
• etcd-Snapshots regelmäßig sichern.
• Registry-Storage sauber planen.

11.1 Vorbereitungscheck

# Tools
oc version
openshift-install version
terraform version
ansible --version

# DNS
dig +short api.lab.okd.example.com
dig +short api-int.lab.okd.example.com
dig +short test.apps.lab.okd.example.com

# Netzwerk
nc -vz api.lab.okd.example.com 6443
nc -vz api.lab.okd.example.com 22623
nc -vz test.apps.lab.okd.example.com 443

11.2 Installationsphasen

11.3 Beispiel-Runbook

# 1. Arbeitsverzeichnis
mkdir -p ~/okd-install/lab
cd ~/okd-install/lab

# 2. Install-Konfiguration vorbereiten
cp ~/templates/install-config.yaml ./install-config.yaml
vi install-config.yaml

# 3. Assets erzeugen
openshift-install create manifests --dir .
openshift-install create ignition-configs --dir .

# 4. Infrastruktur bereitstellen
cd ~/okd-learning/hetzner/terraform
terraform init
terraform plan
terraform apply

# 5. Bootstrap überwachen
cd ~/okd-install/lab
openshift-install wait-for bootstrap-complete --dir . --log-level=info

# 6. Bootstrap entfernen
# Terraform/Ansible: bootstrap target aus LB entfernen und Server löschen.

# 7. Installation abschließen
openshift-install wait-for install-complete --dir . --log-level=info

# 8. Cluster prüfen
export KUBECONFIG=~/okd-install/lab/auth/kubeconfig
oc get nodes
oc get co
oc get clusterversion

11.4 Postinstall-Basics

# Console-Route
oc get route console -n openshift-console

# ClusterOperatoren
oc get co

# Nodes
oc adm top nodes
oc describe node <node>

# Registry prüfen
oc get configs.imageregistry.operator.openshift.io cluster -o yaml

# Ingress prüfen
oc get ingresscontroller -n openshift-ingress-operator

12.1 Monitoring

Prüfe regelmäßig:

oc get co
oc get clusterversion
oc get nodes
oc adm top nodes
oc get pods -A --field-selector=status.phase!=Running,status.phase!=Succeeded

Dokumentiere:

• Welche Operatoren kritisch sind.
• Wie du Alerts im Web UI findest.
• Wie du Logs für einen Namespace sammelst.

12.2 Updates

Lernziele:

• ClusterVersion verstehen.
• Update-Kanäle lesen.
• Vor Update etcd-Snapshot sichern.
• Nach Update Operatoren prüfen.

oc get clusterversion
oc adm upgrade

12.3 GitOps

Baue ein Demo-Setup:

Git Repository
  ├─ namespaces/
  ├─ apps/
  ├─ rbac/
  ├─ networkpolicies/
  └─ overlays/
      ├─ local
      ├─ hetzner
      └─ prod-like

Übung:

• Argo CD oder OpenShift GitOps installieren.
• Eine App deklarativ aus Git deployen.
• Drift erzeugen und automatisch korrigieren lassen.

12.4 Zertifikate

Lernziele:

• Unterschied zwischen API-Zertifikat, Ingress-Zertifikat und App-Zertifikat.
• Default-Ingress-Zertifikat ersetzen.
• ACME/cert-manager für Apps planen.

12.5 Logging

Aufgabe:

• Logs einer App sammeln.
• Events analysieren.
• Node-Journals bei Fehlern lesen.
• oc adm must-gather ausführen und Ergebnis archivieren.

oc adm must-gather

13.1 Sicherheits-Baseline

• Nutze persönliche Admin-Accounts, nicht dauerhaft kubeadmin.
• SSH nur über Bastion oder Admin-IP.
• API-Port nicht unnötig weltweit öffnen.
• Namespaces/Projects mit RBAC trennen.
• Keine privilegierten Pods ohne Begründung.
• NetworkPolicies für App-Namespaces testen.
• Secrets nicht in Git speichern.
• Pull Secrets und API-Token rotieren.

13.2 RBAC-Übung

oc new-project team-a
oc create serviceaccount deployer-bot -n team-a
oc adm policy add-role-to-user edit -z deployer-bot -n team-a
oc adm policy who-can create pods -n team-a

13.3 NetworkPolicy-Übung

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: team-a
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

13.4 Backup

Mindestens üben:

• etcd-Snapshot erstellen.
• Installationsverzeichnis sichern: auth/, metadata.json, terraform.tfstate, DNS-Notizen.
• App-Manifeste in Git halten.
• PVC-Daten separat sichern.

13.5 Kostenkontrolle

Für Hetzner:

• Server nach Übung löschen.
• Load Balancer, Volumes, Snapshots und Primary IPs nicht vergessen.
• Terraform State pflegen.
• Tags/Labels für Kostenstellen verwenden.
• Lab-Cluster nicht unkontrolliert 24/7 laufen lassen.

Projekt 1: Hello OKD

Ziel: Route und Deployment verstehen.

Ergebnis:

• Namespace hello-okd
• Deployment
• Service
• Route
• README mit Screenshots/Kommandos

Projekt 2: Stateful App

Ziel: PVC, Secret und Rollout verstehen.

Baue:

• PostgreSQL mit PVC
• App mit Datenbank-Secret
• Backup/Restore eines Test-Dumps

Projekt 3: S2I/BuildConfig

Ziel: OpenShift Build-Funktionen verstehen.

Baue:

• Git-Repo mit kleiner Node.js/Python-App
• BuildConfig
• ImageStream
• DeploymentConfig oder Deployment
• Route

Projekt 4: GitOps Demo

Ziel: Deklarativer Betrieb.

Baue:

• App-Manifeste in Git
• Argo CD/OpenShift GitOps Application
• Overlay für local und hetzner

Projekt 5: Hetzner Architektur-Dokument

Ziel: Du kannst ein OKD-Lab erklären.

Dokumentiere:

• DNS-Plan
• Firewall-Regeln
• LB-Port-Mapping
• Servergrößen
• Kostenannahmen
• Risiken und Rollback

15.1 CRC-Checkliste

• CRC installiert.
• OKD-Preset gesetzt.
• Cluster startet.
• oc login funktioniert.
• Console erreichbar.
• Beispiel-App per Route erreichbar.
• Reset dokumentiert.

15.2 SNO-Checkliste

• Domain/Subdomain vorhanden.
• api, api-int, *.apps zeigen auf richtige IP.
• Installer und oc passend zur OKD-Version.
• ISO/Ignition erzeugt.
• Server/VM bootet korrekt.
• wait-for install-complete erfolgreich.
• Console erreichbar.
• Storage/Registry geprüft.

15.3 UPI-Checkliste

• Infrastruktur-Plan dokumentiert.
• Bootstrap, Master, Worker definiert.
• DNS vollständig.
• Load Balancer mit 6443, 22623, 80, 443.
• Interne Firewall-Regeln geprüft.
• Ignition-Dateien bereitgestellt.
• Bootstrap abgeschlossen und entfernt.
• Worker joined.
• ClusterOperatoren healthy.

15.4 Hetzner-Checkliste

• Hetzner API-Token sicher gespeichert.
• Terraform State gesichert.
• Private Network erstellt.
• Load Balancer in passender Network-Zone.
• Firewalls restriktiv.
• DNS TTL bewusst gewählt.
• Kostenkontrolle dokumentiert.
• Destroy-Runbook getestet.

15.5 vSphere/vCloud-Checkliste

• vCenter-Version kompatibel.
• Datastore ausreichend schnell und groß.
• VM-Folder/Resource Pool definiert.
• Netzwerk und DNS bereit.
• Rechte für IPI oder UPI geklärt.
• Template/Image-Workflow getestet.
• Load Balancer vorhanden.

16.1 DNS-Probleme

Symptome:

• Installer wartet auf API.
• Console nicht erreichbar.
• Routes lösen nicht auf.

Prüfung:

dig api.lab.okd.example.com
dig api-int.lab.okd.example.com
dig foo.apps.lab.okd.example.com

16.2 Bootstrap hängt

Prüfung:

openshift-install wait-for bootstrap-complete --dir . --log-level=debug
ssh core@<bootstrap-ip>
journalctl -b -f

Typische Ursachen:

• Falsche DNS-Auflösung.
• Load Balancer leitet nicht auf Control Plane.
• Machine Config Server Port 22623 blockiert.
• Ignition-Dateien nicht erreichbar.
• Zeit/NTP fehlerhaft.

16.3 ClusterOperator degraded

oc get co
oc describe co <operator>
oc get pods -n <operator-namespace>
oc logs -n <operator-namespace> <pod>

16.4 Routes funktionieren nicht

oc get ingresscontroller -n openshift-ingress-operator
oc get pods -n openshift-ingress
oc get route -A
curl -vk https://<route-host>

Typische Ursachen:

• Wildcard-DNS falsch.
• LB-Port 80/443 zeigt nicht auf Router/Worker.
• Router-Pods nicht running.
• Zertifikat/Host falsch.

16.5 Storage-Probleme

oc get sc
oc get pv,pvc -A
oc describe pvc <name> -n <namespace>

Typische Ursachen:

• Keine Default StorageClass.
• Provisioner fehlt.
• Volume-Zone passt nicht zum Node.
• Rechte/SCC verhindern Mount.

17.1 Portfolio-Ergebnis

Am Ende sollte dein Repository enthalten:

• docs/architektur.md
• docs/installation-runbook.md
• local/crc/commands.md
• hetzner/architecture.md
• hetzner/dns/zone-template.md
• apps/hello-route/
• apps/postgresql-pvc/
• security/rbac/
• observability/alerts.md