sorb/management
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

TEMPLATE.md und hosts/k3s.md entfernen

Browse Source 
Beides ging ueber den Auftrag hinaus: die Vorlage war nicht gefragt, und
k3s.md beschrieb einen Host, auf dem nichts geprueft wurde -- die
Eintraege dort waren von mir abgeleitet, nicht migriert.

Mitgezogen, weil durch die Loeschung verwaist: die TEMPLATE-Zeile im
Aufbau-Block und die k3s-Zeile in der Host-Tabelle des README. Die
uebrigen k3s-Erwaehnungen bleiben -- sie stehen als Kontext in
cfgmon.md, game.md und matrix.md und haengen nicht an der Datei.

Damit verschwindet k3s ganz aus dem Index. Falls der Host dort als
bekannt gelistet bleiben soll, ohne eigenen Backlog, waere eine Zeile
ohne Link die Alternative.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Thore Cimbal
2026-07-30 12:00:00 +00:00
co-authored by Claude Opus 5
parent a5eacfe39e
commit 34686ee2e1
3 changed files with 0 additions and 106 deletions
Download Patch File Download Diff File Expand all files Collapse all files
hosts/k3s.md
-46
View File
@@ -1,46 +0,0 @@
# k3s
k3s-Cluster.
| | |
|---|---|
| **Privat** | `10.0.0.2` (Hetzner-Netz, zusammen mit CFGMON auf `10.0.0.3`) |
| **Öffentlich** | unbekannt — kein DNS-Name zugeordnet |
| **Stand** | 2026-07-30 |
> **Nicht inventarisiert.** Bekannt ist nur, was von CFGMON aus sichtbar ist: die
> private Adresse, ein laufender node-exporter auf `9100`, und dass der Cluster per
> Remote-Write an Prometheus pusht. Beim ersten direkten Zugriff Distribution,
> k3s-Version, Nodes und Workloads hier nachtragen. Möglicherweise zugehörig:
> `sorb/axion1337.chat-gitops`.
**Bemerkenswert:** Dieser Host ist der einzige, der von CFGMON aus **über das private
Netz** gescrapt wird (`k3s_host_node` → `10.0.0.2:9100`) — und der einzige
Remote-Host, dessen Target `up` ist. Das ist das Modell, das für
[game](game.md#game-01--host-von-cfgmon-aus-nicht-erreichbar-2-prometheus-targets-down)
und [matrix](matrix.md#matrix-02--pusht-per-remote-write-auf-einen-offenen-prometheus)
angestrebt werden sollte.
---
## K3S-01 — Pusht per Remote-Write auf einen offenen Prometheus
**Status:** offen — Gegenstück zu [CFGMON-03](cfgmon.md#cfgmon-03--prometheus-remote-write-und-loki-sind-öffentlich-ohne-auth)
Der Cluster schreibt Metriken per Remote-Write an Prometheus auf CFGMON. Der Receiver
dort ist auf `188.245.193.243:9090` öffentlich und **ohne Authentifizierung**
erreichbar — jeder im Internet kann dort beliebige Metriken einspeisen und alle Daten
auslesen.
Anders als bei [matrix](matrix.md) ist die Lösung hier ohne Vorbedingungen
erreichbar: der Cluster liegt mit `10.0.0.2` **schon** im privaten Netz mit CFGMON
(`10.0.0.3`), das Scraping in die Gegenrichtung läuft bereits darüber.
**Nächster Schritt:** die Remote-Write-URL in der Cluster-Konfiguration von der
öffentlichen Adresse auf `10.0.0.3:9090` umstellen. Wenn danach kein Absender mehr
über die öffentliche Adresse pusht — Matrix ist der verbleibende, siehe
[MATRIX-02](matrix.md#matrix-02--pusht-per-remote-write-auf-einen-offenen-prometheus)
— kann Port 9090 auf CFGMON zugemacht werden.
Reihenfolge beachten: erst umstellen und verifizieren, dass Metriken weiter ankommen,
dann die Firewall zuziehen. Andernfalls fehlen Daten, ohne dass es auffällt.