@GrillSgt: Ja, stimme dir total zu, das muss man sich gut überlegen. Es gibt nichts in der IT was für jeden Use-Case passt, selbst die beste Lösung hat Trade-Offs und es gilt zu schauen, was aktuell und für die zukünftige Entwicklung für einen Anwendungsfall die richtigste Lösung ist.
Kubernetes hat auf der einen Seite viel Hype hervorgerufen, was auf der anderen Seite auch Abwehrreaktionen und oft zu negativen Diskussionen geführt hat. Am Ende liegt es glaube ich auch viel daran, dass Kubernetes oft für den falschen Anwendungsfall benutzt wurde, oder die Komplexität unterschätzt wurde, was dann zu vermeidbaren Problemen führt. Oft reicht halt auch eine VM wo dann 3 Container darauf laufen. Die Vorteile von Kubernetes machen dann die Komplexität sicher nicht wett, ich würde dann auch stark davon abraten.
Ein Homelab/Homeserver ist für mich genau eine Grauzone. Irgendwann kommt man mit Docker an einen Punkt, wo irgendwann zuviele Container laufen. Wie deploye ich die idealerweise immer gleich? Wie heile ich Container wenn sie kaputt gehen? Wie update ich? Wie mache ich die Container erreichbar, idealerweise mit Service Discovery und vielleicht noch einer externen Domain? Sowas geht aus meiner Sicht in Kubernetes einfacher, als wenn ich alles zu Fuß in Docker und VMs mache, denn Kubernetes bietet einfach viele Tools, die mir helfen (
https://landscape.cncf.io/). Und ja, auch die gehören sorgfältig ausgewählt und müssen beherrscht werden und bieten die Gefahr auszuufern. Das ist dann aber eine bewusste Entscheidung. Beispiel: Ein
https://cert-manager.io/ besorgt mir mit kleinster Konfiguration für meine Domain automatisch SSL Zertifikate, für jeden Container der eine subdomain anfragt. Die Services sind nicht von außen erreichbar, cert-manager klärt das mit der cloudflare/hetzner API für mich. Das skaliert einfach super und spart mir viel Arbeit.
So etwas beobachte ich auch oft im professionellen Umfeld. Es wird mit Docker angefangen, irgendwann wird es komplexer und es entstehen Scripte oder anderweitige Logiken, die die Komplexität beherrschen sollen. Leute fangen an Kubernetes nachzubauen. Hier ist man aus meiner dann auf jeden Fall falsch unterwegs, denn auch das ist nachzuhalten.
caseOS hat bestimmt seinen Anwendungsfall für private Nutzer, aber auch hier wird ein UI gebaut, was dann für mich Services deployed, nachhält und auch irgendwo den state der deployten Applikationen speichern. Für viele User der bessere Weg, definitiv. Für mich nicht. Bei Kubernetes habe ich mehr Freiheiten und ehrlicherweise auch mehr Vertrauen.
Wie in meinem Beitrag geschrieben, soll das nur ein Anstoß sein für eine weitere Art wie man seine Services betreiben kann der definitiv nicht für jeden passt
------
@andy_m4: Dein Beitrag kam nachdem ich abgeschickt hatte.
Ich würde dich doch bitten meinen Beitrag nicht 2-mal aus dem Kontext zu reißen. Ich schreibe:
Datenbanken nicht in Kubernetes zu betreiben ist mittlerweile doch ziemlich outdated, das klappt bei uns seit einigen Jahren wunderbar.
Daraus zitierst du nur den ersten Teil
rStorms schrieb:
Datenbanken nicht in Kubernetes zu betreiben ist mittlerweile doch ziemlich outdated,
und sagst
"Ich würde sagen, ob outdated oder nicht ist überhaupt nicht relevant, sondern obs gut funktioniert."
obwohl ich schreibe "das klappt bei uns seit einigen Jahren wunderbar.". Damit meine ich große Datenbanken wie Cockroach, PostgreSQL, Milvus, MongoDB, Clickhouse, ...
Dann finde ich nicht wirklich wo ich sage, dass andere Lösungen outdated sind: "Und insbesondere wenn jemand anfängt mit "andere Lösungen sind outdated" zu argumentieren"?
Liest du das aus meinem Kommentar raus? Ich beziehe mich da doch nur auf die Meinung, dass Datenbanken nicht in Kubernetes betrieben werden sollten?