Files
cluster-knaster/sites/knaster/proxmox.yaml
T
Robert RappandClaude Fable 5.1 75764aaf6a
ci / test (push) Failing after 22s
k3s-VM: feste Adresse 192.168.100.124 statt DHCP
Nach einem Netzausfall erhielt die VM .131; Agents, nex-admin und
kubeconfig zeigten auf .124, alle Knoten NotReady.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-10-20 16:13:15 +02:00

70 lines
5.6 KiB
YAML
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Proxmox-Zielbild für "knaster" (Eingabe für platform/proxmox/tofu und ansible).
# Stand 12.10.2026: echte Knoten pve44–pve61. PCI-Adressen, IDs und IOMMU-Gruppen per
# `pvesh get /nodes/<knoten>/hardware/pci` gelesen. Gäste vorerst per DHCP (D5 zurückgestellt).
cluster:
endpoint: https://192.168.100.210:8006/
storage_iso: local
bridge: vmbr0
gateway: 192.168.100.1
dns: 192.168.100.120
ssh_public_key_file: ~/.ssh/id_ed25519.pub # Schlüssel auf dem Steuerrechner ops
lxc_template: debian-13-standard_13.6-1_amd64.tar.zst
# Ubuntu-24.04-Cloud-Image-Template je Knoten (VMIDs sind clusterweit eindeutig)
templates: {pve44: 9044, pve46: 9046, pve48: 9048, pve52: 9052}
zfs_arc_max_mb: 2048 # ZFS-Lesecache der GPU-Knoten (tank trägt nur Replikate und kleine Gäste); Rolle pve-host
pci_mappings: # Proxmox Resource Mappings (Datacenter → Resource Mappings → PCI)
gpu-m4000-pve44: {node: pve44, path: "0000:01:00", id: "10de:13f1", subsystem_id: "10de:1153", iommu_group: 1}
gpu-p2000-pve44: {node: pve44, path: "0000:02:00", id: "10de:1c30", subsystem_id: "10de:11b3", iommu_group: 8}
gpu-m4000-pve46: {node: pve46, path: "0000:01:00", id: "10de:13f1", subsystem_id: "10de:1153", iommu_group: 1}
gpu-p2000-pve46: {node: pve46, path: "0000:02:00", id: "10de:1c30", subsystem_id: "10de:11b3", iommu_group: 8}
gpu-m4000-pve48: {node: pve48, path: "0000:01:00", id: "10de:13f1", subsystem_id: "10de:1153", iommu_group: 1}
gpu-p2000-pve48: {node: pve48, path: "0000:02:00", id: "10de:1c30", subsystem_id: "10de:11b3", iommu_group: 8}
gpu-m4000-pve52: {node: pve52, path: "0000:01:00", id: "10de:13f1", subsystem_id: "10de:1153", iommu_group: 1}
# Zuteilung je GPU-VM (15.10.): alle 8 Threads des Knotens und 20 von 32 GB. Der Rest des Knotens: Proxmox
# selbst ~3 GB, ZFS-ARC 2 GB (cluster.zfs_arc_max_mb), dazu ops (2 GB, pve46), infra (4 GB, pve44), k3s (3 GB, pve48).
# RAM der GPU-VMs ist durch PCI-Passthrough fest reserviert (kein Ballooning), CPU darf überbucht sein.
vms: # eine GPU-VM pro Knoten mit allen Karten des Knotens (D2)
gpu-pve44: {node: pve44, vmid: 244, cores: 8, memory_mb: 20480, disk_gb: 40, models_disk_gb: 60, storage: local-lvm, gpus: [gpu-m4000-pve44, gpu-p2000-pve44], ip: dhcp, driver_generation: legacy}
gpu-pve46: {node: pve46, vmid: 246, cores: 8, memory_mb: 20480, disk_gb: 40, models_disk_gb: 60, storage: local-lvm, gpus: [gpu-m4000-pve46, gpu-p2000-pve46], ip: dhcp, driver_generation: legacy}
gpu-pve48: {node: pve48, vmid: 248, cores: 8, memory_mb: 20480, disk_gb: 40, models_disk_gb: 60, storage: local-lvm, gpus: [gpu-m4000-pve48, gpu-p2000-pve48], ip: dhcp, driver_generation: legacy}
gpu-pve52: {node: pve52, vmid: 252, cores: 8, memory_mb: 20480, disk_gb: 40, models_disk_gb: 60, storage: local-lvm, gpus: [gpu-m4000-pve52], ip: dhcp, driver_generation: legacy}
containers: # Infrastruktur als LXC (ADR-0001), HA + ZFS-Replikation (ADR-0002)
infra: {node: pve44, vmid: 101, cores: 4, memory_mb: 4096, disk_gb: 60, storage: tank, ip: 192.168.100.188/24, ha: true, replicate_to: [pve52, pve48]}
# Dienst-VMs ohne GPU (D6): k3s-Steuerung, geklont vom Template des Knotens, auf tank mit HA.
# Feste Adresse (20.10.): nach einem Netzausfall bekam die VM per DHCP .131 statt .124, die Agents (/etc/hosts),
# nex-admin (NEX_ADMIN_K8S_URL, NEX_K3S_HOST) und die kubeconfig auf ops zeigten ins Leere – alle Knoten NotReady.
# DHCP-Reservierung am DC (.124, MAC bc:24:11:a5:d5:52) bleibt zusätzlich offen (Plan Task 0.2).
service_vms:
k3s: {node: pve48, vmid: 110, cores: 2, memory_mb: 3072, disk_gb: 20, storage: tank, ip: 192.168.100.124/24, pool: infra, ha: true, replicate_to: [pve52, pve44]}
replication_schedule: "*/15"
# Cluster-Grundkonfiguration (Phase 4, Rolle pve-cluster, Playbook playbooks/cluster.yml)
access:
admin_group: admins # Gruppe mit Administrator auf /; root@pam bleibt Notfallzugang
admin_users: [r.rapp] # persönliche Konten <name>@pve; Passwort und TOTP per scripts/pve-admin-user.sh
mail_to: ki@mygodel.de # Ziel der Proxmox-Benachrichtigungen (Backup, Fencing, Updates, Replikation)
# Verwaltung durch Personen statt durch ein Gerät (19.10., „Weg 1“): Jede Person kommt mit einem eigenen Schlüssel
# auf ops (Bastion) und arbeitet von dort (kubectl, Ansible, tofu). Öffentliche Schlüssel, kein Geheimnis.
# Ausrollen: playbooks/admins.yml auf ops. Übergabe und Entzug: docs/BETRIEB.md Abschnitt 15.
ops_ssh_keys:
- {name: r.rapp-laptop, key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHG5/rQMO4dtO8jOdAjQksFxZhdI7oSZAGNmFXVxQcoJ rrapp-laptop-2026-10-08"}
ops_ssh_keys_revoked: [] # ehemalige Schlüssel ({name, key}); playbooks/admins.yml entfernt sie von ops
firewall:
enable: true
# IPSET management: nur diese Quellen (plus alle Knoten) erreichen 8006, 22, 5900-5999, 3128 und
# 60000-60050 der Knoten. Corosync zwischen den Knoten erlaubt Proxmox von selbst.
# Achtung: Der Laptop läuft per DHCP (D5). ops und infra haben seit 14.10. feste Adressen (noch ohne
# Reservierung am DC). Wechselt die Laptop-Adresse, sperrt die Firewall diese Quelle aus. Rückweg: ssh über eine noch zugelassene Adresse (ops) oder Konsole.
management:
- {ip: 192.168.100.151, comment: Admin-Laptop WLAN per DHCP}
- {ip: 192.168.100.181, comment: Admin-Laptop USB-LAN im Dock per DHCP}
- {ip: 192.168.100.29, comment: appsrv08 LiteLLM mit PSE und n8n-Bruecke}
- {ip: 192.168.100.173, comment: ops CT 100 Ansible und tofu statisch}
- {ip: 192.168.100.188, comment: infra CT 101 pve-exporter statisch}
ping_from: 192.168.100.0/24