<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Kubernetes on René Zander | KI-Automatisierungsberater</title><link>https://renezander.com/de/tags/kubernetes/</link><description>Recent content in Kubernetes on René Zander | KI-Automatisierungsberater</description><generator>Hugo</generator><language>de</language><lastBuildDate>Thu, 23 Apr 2026 11:00:00 +0000</lastBuildDate><atom:link href="https://renezander.com/de/tags/kubernetes/index.xml" rel="self" type="application/rss+xml"/><item><title>Voice AI in Produktion: Vom RunPod-Pod zu Hosted Kubernetes</title><link>https://renezander.com/de/blog/voice-ai-production-kubernetes/</link><pubDate>Thu, 23 Apr 2026 11:00:00 +0000</pubDate><guid>https://renezander.com/de/blog/voice-ai-production-kubernetes/</guid><description>&lt;p>Dein TTS-Modell funktioniert in der Demo. Dasselbe Modell kollabiert in Produktion unter paralleler Last. Die Modell-Datei ist identisch. Die GPU ist dieselbe. Nur das Deployment hat sich geändert.&lt;/p>
&lt;p>Wenn dein TTS-Service auf einem einzelnen RunPod-Pod läuft, bist du schon an diese Grenze gestoßen. Du bearbeitest eine Anfrage pro GPU gleichzeitig. Ein Absturz kostet neunzig Sekunden Neuladezeit für das Modell. Failover ist nicht vorgesehen. Deine Marketing-Seite verspricht &amp;ldquo;Narration sofort generieren.&amp;rdquo; Deine Infrastruktur sagt &amp;ldquo;bitte hinten anstellen.&amp;rdquo;&lt;/p></description></item><item><title>Self-Hosted LLM auf Kubernetes: Produktives vLLM-Deployment</title><link>https://renezander.com/de/blog/self-hosted-llm-kubernetes/</link><pubDate>Sun, 05 Apr 2026 07:00:00 +0200</pubDate><guid>https://renezander.com/de/blog/self-hosted-llm-kubernetes/</guid><description>&lt;p>Die meisten Teams, die nach Self-Hosted-LLM-Kubernetes-Deployments fragen, sollten dafür gar kein Kubernetes fahren. Die ehrliche Antwort: vLLM auf einer einzelnen GPU-Box, eingepackt in systemd oder Docker Compose, deckt mehr Use Cases ab, als man gerne zugibt. Kubernetes verdient sich seinen Platz erst, wenn Sie es ohnehin betreiben — oder wenn Sie horizontale Skalierung, Multi-Tenancy-Isolation oder saubere Rolling Deploys über einen GPU-Node-Pool brauchen.&lt;/p>
&lt;p>Dieser Leitfaden setzt voraus, dass Sie sich für Kubernetes entschieden haben. Ich gehe die Referenzarchitektur durch, die ich beim LLM-Deployment nach k8s nutze, liefere vollständige Manifests für vLLM mit Llama 3.3 70B quantisiert und die operativen Stolpersteine, die jedes Team beim ersten Mal erwischen. Keine plattformspezifische Magie, keine Abstraktion hinter einem Managed Vendor. Nur die YAML, die Sie brauchen, und die Begründung hinter jedem Feld.&lt;/p></description></item><item><title>n8n-Self-Hosting-Leitfaden: Docker, Kubernetes und Bare Metal in Produktion</title><link>https://renezander.com/de/blog/n8n-self-hosting-guide/</link><pubDate>Tue, 31 Mar 2026 09:00:00 +0200</pubDate><guid>https://renezander.com/de/blog/n8n-self-hosting-guide/</guid><description>&lt;p>Ich fahre n8n selbst gehostet seit 2022 über drei verschiedene Topologien: ein Single-VPS-Docker-Compose-Setup, einen kleinen Kubernetes-Cluster mit Queue-Mode und eine Bare-systemd-Installation auf einer gehärteten Debian-Box. Jede hat ihren Platz, und die falsche Wahl kostet Wochenenden. Dieser n8n-Self-Hosting-Leitfaden ist die Version, die ich am Anfang gebraucht hätte — geschrieben für Teams, die produktive Stabilität wollen, nicht eine Demo.&lt;/p>
&lt;p>Kurzes Fazit vorweg: Docker Compose fahren, solange Sie physisch können. Kubernetes nur, wenn Sie es ohnehin für andere Services betreiben oder wirklich nördlich von 50.000 Executions pro Tag liegen. Der Bare-systemd-Pfad existiert für Leute wie mich, die minimalistische Stacks mögen und jedes bewegliche Teil verstehen wollen. Alle drei funktionieren. Der falsche Pfad fühlt sich wie ein zweiter Job an.&lt;/p></description></item></channel></rss>