Proxmox und Container in VM's

[BKS-IT]

Hallo zusammen

Bin gerade auf Arbeit am Studium von Docker & Kubernetes und all dem ganzen Geraffel. Wollte mal kurz in die Runde Fragen wie es bei euch so aussieht? Respektive wie es euch so dabei geht bei der Thematik?
Für mich fühlt es sich gerade so an, als ob die ganze Welt nach Kubernetes schreit und wenn man das nicht macht, dann ist man verloren, Rückständig oder ein schlechter zurückgebliebener Admin.
Ich finde grundsätzlich Container eigentlich eine gute Sache, wenn es darum geht, sehr viele von diesen Dingern zu haben, um damit Resource zu schonen und Probleme parallel zu bearbeiten. Jedoch muss ich teilweise nur den Kopf schütteln, wenn ich manche DevOps-Captains schon für kleinste Projekte Kubernetes einsetzen.
LXC finde ich wirklich eine Super Sache jedoch finde ich Docker doch etwas Grenzwertig, da es gefühlt eine Milliarde Tools da rundherum gibt von irgendwoher und das meiste liegt in einem Git-Repo und wen man Glück hat, wird das noch gepflegt. Vom Kubernetes Universum möchte ich nun mal noch gar nicht sprechen, geschweige denn DB's im Stateful-Modus in Kubernetes zu betreiben
Bin ich einfach zu alt und frage mich da einfach zu viel oder kommt da aus dem Lager der Container-Leute (Hauptsächlich Docker & Kubernetes unheimlich Druck auf). Gut manche sagen der Hype ist wieder vorbei und auch der letzte sture Sysadmin muss das Beherrschen?
Wie geht es euch so als Admins bei den Themen so?

Grüsse
Andreas

 

[Falk R.]

Hi Andreas,

klar ist Kubernetes ein Hype wie KI. Bei großen Umgebungen ist Kubernetes super, beim kleinen Mittelständler ist es einfach drüber.
Application Container wie Docker sind schon die Zukunft für viele aber nicht alle Anwendungen, LXC ist toll fürs Homelab, aber in Hochverfügbarkeitsumgebungen nimmt man doch eher VMs.
Da wir noch ganz viele Leagacy Anwendungen haben, wird es noch sehr lange VMs und auch LXC geben. Die Zukunft wird mehr App Container wie Docker bringen, aber meine Meinung: Die Zukunft ist Hybrid.

 

[CoolTux]

Ich selbst verwende privat Kubernetes und habe 2/3 meiner Anwendungen darin am laufen. Habe ein k8s Vanilla und ein rke2 Cluster. Der rke2 ist nur zum testen und rumspielen.
Läuft alles in VMs unter Proxmox

Beruflich bin ich unteranderem Kubernetes Consultant

 

[waltar]

Grundsätzlich ist da ja auch ein anderer Grundgedanke der Wegwerfmentalität dahinter: Docker/Kubernetes Container Workflows sind eher auf einmaligen Start zur Erfüllung einer Aufgabe in großem Cluster als eingequeueter Job erfunden und danach gelöscht, was nicht heißt, daß es natürlich auch jene Container gibt, die dauerhaft eine Aufgabe erfüllen sollen. Werden deshalb idR auch nicht gesichert noch recovert, da sie meist generiert werden.
Bei VM's und LXC's ist es eher so, daß sie dauerhaft einen Dienst darstellen und auch immer wieder (per ha) so in letztem und immer weiter entwickelndem Stand restartet werden, was auch nicht heißt, daß man mit Proxmox und LXC's nicht auch "Einmal-Jobs" verarbeiten könnte.
Werden deshalb idR auch gesichert und bei jedweidigem Verlust recovert.
Man kann es also vom ursprünglich jeweils entwickeltem Ansatz nicht direkt vergleichen.

 

[HBerger]

Ich find z.b. docker richtig geil .... err nützlich.

ok, ich bin kein Admin, ich bin Entwickler (aber mehr klassich, nicht so sehr auf webapps getrimmt ) ...
und ich such grad Lösungen für mein Homelab ...

Wenn ich überlege wie man früher(ganz ganz früher) sachen verwaltet hat .... ein fetter server, alles nativ aufm OS.
Wenn man dann mal was umziehen musste auf nen anderen server oder den Server neu aufsetzen und die Daten ausm Backup füttern muss ....

Also das feature für mich von dem docker zeugs ist distribution.
du hasst simple scripts, die dir deine App hochziehen, sie sind meistens Speicherort neutral.
Runtime und Daten kann man gut trennen
also kannst du die super in ner versionsverwaltung pflegen .... (mit kompletten virtuellen maschinen nicht ganz so lustig)

Meine Welt ist dann komplexer, aber da werden auch ähnliche konzepte versucht .... conan, nixpkg .... wenn das so einfach und komfortabel wäre wie docker ....

 

[BKS-IT]

Danke euch allen für eure Gedanken, Sichtweisen und Einblicke, manchmal tut ein neuer Blickwinkel ganz gut;-)

 

[CoolTux]

Gerade als Entwickler empfinde ich Container als Traum. Du hast einen einzigen point of true (Git), egal ob Dockerfile (also Bau der Anwendung), oder für das Deployment später in Docker oder in Kubernetes.

In meinem Git werden mittels Action Workflows Containter auf Basis eines Dockerfiles gebaut und in eine Container Registry gepusht, danach wird in einem anderen Repositorie durch den Action Workflow vom bau der Anwendung die aktuelle Version in ein Chart.yaml geschrieben wodurch dann ein Action Workflow in genau diesem Repositorie angestoßen wird welches dafür sorgt das ein Helm Chart package gebaut und in meine Helm Chart Registry gepusht wird und der Workflow schreibt dann in einem dritten REpository in ein file rein welches das Applications Object für ArgoCD beschreibt so das automatisch und auch nicht automatisch die neue Version der Anwendung im Cluster ausgerollt wird. So funktionieren CI/CD Pipelines. Man kann den CI Teil auch mit Action Workflows machen und den CD Teil dann mit Jenkins und ArgoCD.

 

[bluesite]

ich hab aktuell 4 lxc mit Docker am Laufen die Daten aber auf nem zfs datastore liegen auf den alle Zugriff haben so kann ich recht einfach einen Docker Kontainer auf einen der anderen lxc umziehen falls es nötig ist, der Datastore ist per lxc.mount eingebunden auf allen und wird per zfs snapshot gesichert bzw die Daten da drin zwei mal am Tag auf eine extra HDD

 

[Johannes S]

Naja, ich finde die Hauptvorteile von Docker und Kubernetes sind folgende:

• Da alle vorherigen Sachen nicht einfach übernommen werden können, ist man dazu gezwungen mal seine ganzen Altlasten zu überdenken und los zu werden. Das geht (da bin ich ganz bei Falk) natürlich nicht von heute auf morgen, aber es geht wenigstens schon mal los. Darum freue ich mich auch darauf, dass bei uns auf der Arbeit das Thema gerade Fahrt aufnimmt. Rein technisch müssten wir das nicht, aber man kann damit gut alte Zöpfe los werden.
• Der einzelne Server / die VM wird ersetzbar, da die Anwendung selbst flüchtig ist und auf einen Container liegt und jederzeit neu ausgerollt werden kann, während die Daten auf einen externen Netzspeicher/datenbank o.ä. liegen. Ich kann also jederzeit die Anwendung oder sogar den ganzen Server wegschmeißen und neu einrichten ohne großen Aufwand. Man kommt also endlich weg von den ganzen Elend um "Change-" und "Patchmanagment", was in der Praxis ja eher Patchverhinderungsmanagment ist: Neue Versionen (inklusive des Betriebssystems!) lassen sich automatisiert ausrollen und bei Problemen auch wieder zurückrollen. Mehr Automatisierung, weniger Wartungsaufwand, bessere Security (durch aktuelle Patchstände)->Profit

Zumindestens in der Theorie, bisher habe ich keine praktische Erfahrung mit Kubernetes außer ein paar Tutorials durchzuklicken

Aber jemand mit praktischer Erfahrung hat dazu einiges gebloggt:
https://blog.koehntopp.info/2023/08/28/der-admin-beruf.html
https://blog.koehntopp.info/2019/04/25/what-has-kubernetes-ever-done-for-us.html
https://blog.koehntopp.info/2024/09/30/cloud-cost-vs-on-premises-cost.html
https://blog.koehntopp.info/2017/06/03/something-kubernetes-containers.html

Ich würde jetzt nicht unbedingt bei allen so pauschal mitgehen und habe auch ein wenig den Eindruck, dass der Autor die Sachen ein wenig zu sehr aus seiner "Blase" betrachtet (der Mann war lange bei booking.com beschäftigt, also eine Firma die Kostensteigerungen durch eine Cloud-Migration sehr gut und leicht an die Kunden weitergeben kann, das können kleinere Unternehmen mit schwächerer Marktposition oder unterfinanzierte Behörden ja nun nicht unbedingt), aber bei vielen seiner grundsätzlichen Überlegungen gehe ich schon mit.

 

[Johannes S]

https://blog.koehntopp.info/2024/09/30/cloud-cost-vs-on-premises-cost.html

Zu seinen Argument mit der cloud gibt es natürlich auch die Gegenargumentation, etwa wenn Vorteile der cloud wie Skalierbarkeit nicht relevant oder nutzbar sind. Ein Beispiel dafür hat er selbst geliefert für das Homelearning der Schulen in Baden-Würtemberg unter Pandemiebedingungen:
https://blog.koehntopp.info/2021/01/12/600000-user-in-baden-wurttemberg.html
Einer der beteiligten Admins hat dazu auch mal einen Vortrag gehalten: https://media.ccc.de/v/meetup-2021-01-114-moodle-fr-bw-in-72-stunden

Und mit leicht klickbaitigen Titel aber allgemeiner und auf grundsätzlicherer Ebene von einen anderen Profi (slink laut https://archive.gulas.ch/gpn22/talk/KLRSDL/, war unter anderen Gründer mehrerer Internet-Service-Provider)::
https://media.ccc.de/v/gpn22-270-why-the-cloud-is-evil
slink war es dabei wichtig, dass seine Kritik an der Cloud sich NICHT gegen die Technik per se richtet (also Kubernetes und co), sofern diese unter Opensource verfügbare Standardlösungen sind, sondern eben die Migration zu AWS/Azure/Google und co. Also dass, was nach Einschätzung von Koehntopp für die meisten Unternehmen der bessere Deal ist.

Sprich: Ob mit oder ohne Cloud-Migration: An Containern (also den Cloud-Techniken!) wird man nicht mehr vorbeikommen, wegen der von Falk erwähnten Altlasten, wird es aber sehr lange noch hybrid bleiben. Der Anteil der Nicht-Container wird zunehmend geringer werden bis nur noch die paar Sachen überbleiben, wo die Vorteile von Containern nicht greifen.

 

[waltar]

"Zum Glück" greifen bei mir die Vorteile von Containern meistens noch nicht ..., also derzeit immer noch bare metal oder vm als Lösungen für die diversesten "Probleme" und Container als Tests

 

[BKS-IT]

Naja, ich finde die Hauptvorteile von Docker und Kubernetes sind folgende:

• Da alle vorherigen Sachen nicht einfach übernommen werden können, ist man dazu gezwungen mal seine ganzen Altlasten zu überdenken und los zu werden. Das geht (da bin ich ganz bei Falk) natürlich nicht von heute auf morgen, aber es geht wenigstens schon mal los. Darum freue ich mich auch darauf, dass bei uns auf der Arbeit das Thema gerade Fahrt aufnimmt. Rein technisch müssten wir das nicht, aber man kann damit gut alte Zöpfe los werden.
• Der einzelne Server / die VM wird ersetzbar, da die Anwendung selbst flüchtig ist und auf einen Container liegt und jederzeit neu ausgerollt werden kann, während die Daten auf einen externen Netzspeicher/datenbank o.ä. liegen. Ich kann also jederzeit die Anwendung oder sogar den ganzen Server wegschmeißen und neu einrichten ohne großen Aufwand. Man kommt also endlich weg von den ganzen Elend um "Change-" und "Patchmanagment", was in der Praxis ja eher Patchverhinderungsmanagment ist: Neue Versionen (inklusive des Betriebssystems!) lassen sich automatisiert ausrollen und bei Problemen auch wieder zurückrollen. Mehr Automatisierung, weniger Wartungsaufwand, bessere Security (durch aktuelle Patchstände)->Profit

Zumindestens in der Theorie, bisher habe ich keine praktische Erfahrung mit Kubernetes außer ein paar Tutorials durchzuklicken

Aber jemand mit praktischer Erfahrung hat dazu einiges gebloggt:
https://blog.koehntopp.info/2023/08/28/der-admin-beruf.html
https://blog.koehntopp.info/2019/04/25/what-has-kubernetes-ever-done-for-us.html
https://blog.koehntopp.info/2024/09/30/cloud-cost-vs-on-premises-cost.html
https://blog.koehntopp.info/2017/06/03/something-kubernetes-containers.html

Ich würde jetzt nicht unbedingt bei allen so pauschal mitgehen und habe auch ein wenig den Eindruck, dass der Autor die Sachen ein wenig zu sehr aus seiner "Blase" betrachtet (der Mann war lange bei booking.com beschäftigt, also eine Firma die Kostensteigerungen durch eine Cloud-Migration sehr gut und leicht an die Kunden weitergeben kann, das können kleinere Unternehmen mit schwächerer Marktposition oder unterfinanzierte Behörden ja nun nicht unbedingt), aber bei vielen seiner grundsätzlichen Überlegungen gehe ich schon mit.

Sorry aber alleine für diesen Satz gehört der Autor gesteinigt: Der Beruf des “Admins” ist - hoffentlich - eine aussterbende Tätigkeit. (Quelle: https://blog.koehntopp.info/2023/08/28/der-admin-beruf.html) -- es gibt nämlich sehr sehr gute Gründe wieso Entwickler (Applikationsentwickler) die Finger von der Systemtechnik lassen sollten oder vom klassischen System Engineering auf OS Ebene (OS Entwickler mal ausgenommen). War bis jetzt bei sehr vielen Firmen bei denen ich angstellt war und da hat das Management auch pingelig genau darauf bestanden und ja auch seit der DevOps Ära.

 

[Johannes S]

Sorry aber alleine für diesen Satz gehört der Autor gesteinigt: Der Beruf des “Admins” ist - hoffentlich - eine aussterbende Tätigkeit. (Quelle: https://blog.koehntopp.info/2023/08/28/der-admin-beruf.html) -- es gibt nämlich sehr sehr gute Gründe wieso Entwickler (Applikationsentwickler) die Finger von der Systemtechnik lassen sollten oder vom klassischen System Engineering auf OS Ebene (OS Entwickler mal ausgenommen).

Die Frage ist halt, was man unter "Admin" versteht, das klassische Berufsbild, wo man alle Server händisch ( von Hardwareaustausch bis Software- und Systempatches) und die Rechner der Enduser per Turmschuhadministration pflegt, ist ( egal was man davon hält) halt wirklich auf den Rückzug durch den Cloudtrend. Ich sehe das nicht so absolut wie der Autor, dass das per se eine gute Sache ist. Aber dass das Vorteile hat ( auch wenn man den Kram lieber selbst hostet statt bei AWS und Co) lässt sich doch kaum leugnen?

Das dafür mit Devops und Systemarchitektur neue Tätigkeitsfelder kommen, wo man gerade nicht Entwickler mit ihren Hang zur Festureitis haben will, ist ja davon unberührt.

Ear bis jetzt bei sehr vielen Firmen bei denen ich angstellt war und da hat das Management auch pingelig genau darauf bestanden und ja auch seit der DevOps Ära.

Zu Recht, das hat aber mit dem Punkt des Autoren nichts zu tun.

 

[CoolTux]

Sorry aber alleine für diesen Satz gehört der Autor gesteinigt: Der Beruf des “Admins” ist - hoffentlich - eine aussterbende Tätigkeit. (Quelle: https://blog.koehntopp.info/2023/08/28/der-admin-beruf.html) -- es gibt nämlich sehr sehr gute Gründe wieso Entwickler (Applikationsentwickler) die Finger von der Systemtechnik lassen sollten oder vom klassischen System Engineering auf OS Ebene (OS Entwickler mal ausgenommen). War bis jetzt bei sehr vielen Firmen bei denen ich angstellt war und da hat das Management auch pingelig genau darauf bestanden und ja auch seit der DevOps Ära.

Irgendwie verstehe ich glaube nicht so ganz was Du uns/mir damit sagen möchtest.
Gerade wenn ich Kubernetes verwende ist doch der Entwickler von der Systemarchitektur komplett entkoppelt. Der bekommt sein Repo und seine Pipeline und fertig. Er alleine ist für seine Anwendung verantwortlich.
Ein "Admin" gibt ihm höchstens noch ein Namespace und eine storageclass für persistente Daten. Alles andere macht der Entwickler und/oder noch ein Anwendungsbetreuer (bauen eines Helm Charts oder der Kustomizes).

 

[BKS-IT]

Irgendwie verstehe ich glaube nicht so ganz was Du uns/mir damit sagen möchtest.
Gerade wenn ich Kubernetes verwende ist doch der Entwickler von der Systemarchitektur komplett entkoppelt. Der bekommt sein Repo und seine Pipeline und fertig. Er alleine ist für seine Anwendung verantwortlich.
Ein "Admin" gibt ihm höchstens noch ein Namespace und eine storageclass für persistente Daten. Alles andere macht der Entwickler und/oder noch ein Anwendungsbetreuer (bauen eines Helm Charts oder der Kustomizes).

Nun viele Entwickler sind gleichzeitig Kubernetes Admin und Anwendungsentwickler, klar wenn man eine Trennung macht, wie du dann kommt das gut.
Ich sehe jedoch seit meiner Lernphase bei dem Thema, dass das gemischt wird und was ich nicht für gut halte. Repo und Pipeline ist ja grundsätzlich eine feine Sache ist jedoch nichts neues da es CI/CD schon lange gab, bevor Docker und Kubernetes aufgekommen sind.

 

[Johannes S]

Nun viele Entwickler sind gleichzeitig Kubernetes Admin und Anwendungsentwickler, klar wenn man eine Trennung macht, wie du dann kommt das gut.
Ich sehe jedoch seit meiner Lernphase bei dem Thema, dass das gemischt wird und was ich nicht für gut halte. Repo und Pipeline ist ja grundsätzlich eine feine Sache ist jedoch nichts neues da es CI/CD schon lange gab, bevor Docker und Kubernetes aufgekommen sind.

Naja, so langsam kriege ich das Gefühl, dass du eigentlich nur deine Meinung bestätigt haben wolltest, anstatt die Perspektive nachzuvollziehen, warum man den Trend zur Containerisierung als gar nicht mal so verkehrt betrachtet

In den von dir nicht sehr wohlwollend aufgenommenden Artikel wird ja auch auf das Argument "ist doch nichts neues" eingegangen, ja "irgendwie" gab es das auch schon davor, aber jede Firma musste das quasi für sich erst neu entwickeln und einrichten, passendes Personal finden etcpp.

Kubernetes und docker/Podman als Standardlösungen machen es also leichter Leute zu finden und man hat bereits ein Ökosystem, was man mitnutzen kann. Klar ist das nicht für jeden Usecase optimal, aber das macht halt nichts, solange es "gut genug" ist.

Wo ich beim Autoren nicht mitgehe, ist dass aufgrund der Dimensionen der heutigen Hardware es sich für die meisten Firmen nicht mehr lohnt, sich selbst teure Serverhardware anzuschaffen und zu betreiben. Das mag für ein Startup sicher zutreffen und sicher auch noch für die meisten mittelständischen Firmen bis zu einer bestimmten Größenordnung. Ich wage trotzdem zu behaupten, dass die Anschaffungs- und Betriebskosten eines kleineren HyperV-/ProxmoxVE-Clusters (der ja auch durch einen Dienstleister aufgesetzt und betrieben werden kann, den die meisten Mittelständler eh für IT-Kram haben) deutlich unter dem für eine Cloud-Lösung ist. Nur mit der Frage "Kubernetes gut/schlecht" hat das halt nichts zu tun, dieses Rechnung müsste man genauso mit Tomcat-Application-Servern für irgendeine Fachanwendung oder einer auf einer Windows ServerVM laufenden Branchensoftware aufmachen.