--- title: "Django Hurricane: Deine Django-Anwendung auf Kubernetes-Kurs" description: "Mit Django Hurricane entwickelst du skalierbare Anwendungen, die perfekt zu Kubernetes passen. Erfahre, wie du deine Workflows optimierst und die volle Power moderner Container-Orchestrierung für dich nutzt." canonical_url: "https://www.blueshoe.de/blog/django-hurricane-kubernetes/" --- Mit Django Hurricane entwickelst du skalierbare Anwendungen, die perfekt zu Kubernetes passen. Erfahre, wie du deine Workflows optimierst und die volle Power moderner Container-Orchestrierung für dich nutzt. Wer [Django](https://www.djangoproject.com/) liebt, weiß seine Stärken zu schätzen: schnelle Entwicklung, ein robustes ORM und eine riesige Community. Doch wenn es um den Einsatz in modernen, cloud-nativen Umgebungen wie Kubernetes geht, stößt das traditionelle Django-Setup an seine Grenzen. Hier kommt Django Hurricane ins Spiel – ein Projekt, das deine Django-Anwendung fit für die Orchestrierung macht. ![Django Hurricane](/img/blog/django-hurricane.png) - Kubernetes Basics - Das Projekt [Django Hurricane](https://django-hurricane.io/) - [Kubernetes Probes](https://kubernetes.io/de/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/) - [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/de/docs/tasks/run-application/horizontal-pod-autoscale/) - Optional [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine?hl=de) Solltest du Fragen haben, oder dir etwas unklar sein, kannst du die Kommentarfunktion unter dem Artikel nutzen. [Django Hurricane](https://django-hurricane.io/) integriert Konzepte wie Liveness- und Readiness-Probes direkt in den Django-Management-Kontext. Das bedeutet, Kubernetes kann jederzeit den Zustand deiner Anwendung verstehen und intelligent darauf reagieren – zum Beispiel, indem es Traffic erst dann an einen neuen Pod sendet, wenn dieser wirklich bereit ist. Doch das ist nur der Anfang. Die letzten Updates (Version 1.5.0 und 1.6.0) haben eine Reihe mächtiger neuer Funktionen mitgebracht, die das Entwicklerleben noch einfacher machen. Schauen wir uns die Highlights genauer an. ## Neue Superkräfte: Monitoring, Ressourcen-Kontrolle und feines Tuning Die jüngsten Versionen von Hurricane haben sich darauf konzentriert, dir mehr Kontrolle und bessere Einblicke in deine Anwendung zu geben – genau das, was man in einer dynamischen Kubernetes-Umgebung braucht. ## Besseres Monitoring und Logging mit structlog & Prometheus (v1.5.0) Gute Observability ist das A und O für stabile Systeme. Hurricane macht hier einen großen Schritt nach vorne. ### Prometheus-Metriken out-of-the-box Mit dem Start des Servers via `$ python manage.py serve` wird standardmäßig ein Metrik-Endpunkt unter `/metrics` auf dem *internen Port* bereitgestellt. Diese Metriken sind im Prometheus-Format und können von deinem Monitoring-System einfach ausgelesen werden. Das ist die Grundlage für Alarme und Dashboards. Falls du das nicht benötigst, kannst du es einfach mit der Option `--no-metrics` deaktivieren. 📈 ### Strukturiertes Logging Sobald du `structlog` zu deinem Projekt hinzufügst, integriert sich Hurricane automatisch. Strukturiertes Logging ist ein Game-Changer, weil Logs nicht mehr nur Textwüsten, sondern maschinenlesbare Daten sind. Das erleichtert die Analyse und Fehlersuche ungemein. Tipp: Für Nutzer der *Google Kubernetes Engine (GKE)* empfiehlt sich zusätzlich `structlog-gcp`, um die Logs perfekt für das Google Cloud Logging aufzubereiten. ## Intelligentes Ressourcenmanagement (v1.5.0) In einer Container-Welt sind Ressourcen wie Speicher kostbar und müssen gut verwaltet werden. ### Speicherlimit setzen Speicherlimit setzen: Mit `--max-memory` kannst du eine Obergrenze für den Arbeitsspeicher festlegen (z. B. `--max-memory 512M`). Überschreitet deine Anwendung dieses Limit, wird sie kontrolliert neu gestartet. Das verhindert unkontrollierte Abstürze durch "Out of Memory"-Fehler und überlässt Kubernetes die Steuerung über den Neustart des Pods. ### Worker-Threads anpassen Die Option `--workers` gibt dir die Kontrolle über die Anzahl der Threads im `ThreadPoolExecutor`. Damit kannst du die Performance für I/O-intensive Aufgaben gezielt optimieren. --- ## Mehr Flexibilität und Kontrolle (v1.6.0) Version 1.6.0 legt den Fokus auf Konfiguration und die Handhabung spezieller Anwendungsfälle. ### Umgang mit großen Datenmengen Deine App verarbeitet große Datei-Uploads oder riesige JSON-Payloads? Mit `--max-body-size` und `--max-buffer-size` kannst du das Verhalten des zugrundeliegenden Tornado-Servers präzise steuern. Damit verhinderst du Pufferüberläufe und sorgst auch bei hohem Datenaufkommen für Stabilität. ### Konfiguration auf deine Art Flexibilität ist Trumpf. Hurricane lässt sich nun über drei Wege konfigurieren: **klassische CLI-Argumente**, Einträge in den **Django Settings** oder – und das ist besonders für Kubernetes-Deployments ideal - über **Umgebungsvariablen**. Dies folgt dem bewährten ["12-Factor App"-Prinzip](https://12factor.net/) und ermöglicht saubere, umgebungsspezifische Konfigurationen ohne Code-Änderungen. --- ## Deep Dive: API-Skalierung mit HPA und Prometheus-Metriken Eine der größten Stärken von Kubernetes ist die Fähigkeit zur automatischen Skalierung. Aber die Standardskalierung nach CPU- oder Speicherauslastung ist für I/O-intensive Anwendungen wie Django-APIs oft nicht ideal. Eine API kann unter Volllast stehen (z.B. durch viele langsame Datenbankabfragen), ohne dass die CPU-Last signifikant ansteigt. Eine viel bessere Metrik ist der *request backlog* – also die Anzahl der Anfragen, die gerade aktiv von einem Pod bearbeitet werden. Wenn diese Zahl steigt, bedeutet das, dass die Anwendung an ihre Belastungsgrenze kommt und wir mehr Instanzen benötigen. Im Folgenden zeige ich dir, wie man genau das mit Django Hurricane auf der Google Kubernetes Engine (GKE) umsetzt. ### Schritt 1: Die richtige Metrik identifizieren Django Hurricane stellt über seinen Prometheus-Endpunkt `/metrics` eine Vielzahl von Messwerten bereit. Für unseren Anwendungsfall ist eine Metrik wie `request_queue_length` ideal. Sie zeigt uns die Anzahl der gleichzeitig verarbeiteten Anfragen pro Pod. Unser Ziel ist es, zu sagen: "Wenn im Durchschnitt mehr als 5 Anfragen pro Pod aktiv sind, starte einen neuen Pod." ![GKE Metrics](/img/blogs/gke-hpa-1.png) ### Schritt 2: Prometheus-Metriken in GKE sammeln Der einfachste Weg, Prometheus-Metriken in GKE zu nutzen, ist der [Google Cloud Managed Service for Prometheus](https://cloud.google.com/stackdriver/docs/managed-prometheus). Wenn dieser in deinem Cluster aktiviert ist, musst du Kubernetes nur noch sagen, wo es die Metriken deiner Anwendung finden kann. Wir weisen Kubernetes an, den *Port 8081* (den internen Port von Django Hurricane) nach Metriken abzusuchen. Hier ein Beispiel für ein Deployment-Manifest: ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: my-django-api spec: replicas: 2 selector: matchLabels: app: my-django-api template: metadata: labels: app: my-django-api spec: containers: - args: - python /app/manage.py serve --req-queue-len 100 --command "collectstatic --no-input" --port 8080 --static --max-memory 950 name: django-hurricane image: your-django-app-image:latest ports: - containerPort: 8080 name: http protocol: TCP - containerPort: 8081 name: metrics protocol: TCP ``` Dann brauchen wir noch ein `PodMonitoring`: ```yaml apiVersion: monitoring.googleapis.com/v1 kind: PodMonitoring metadata: name: my-django-api spec: endpoints: - interval: 5s # Interval um den Metrics-Endpunkt abzufragen metricRelabeling: - action: keep regex: request_queue_.+ # Wir exportieren nur diese eine Metrik sourceLabels: - __name__ port: metrics # Das ist der Name des Ports (siehe oben am Deployment) selector: matchLabels: name: my-django-api # Der Pod Selector targetLabels: metadata: - pod - container ``` Damit landen die Daten auch schon in der Google Cloud Console. ### Schritt 3: Den Horizontal Pod Autoscaler (HPA) anlegen Jetzt kommt der spannendste Teil. Wir definieren einen [Horizontal Pod Autoscaler (HPA)](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/), der die Metrik aus dem Managed Prometheus Service ausliest und darauf reagiert. Die von Google Cloud Managed Prometheus gesammelten Metriken erhalten ein spezielles Präfix. Unsere Metrik `request_queue_length` wird in Google Cloud Monitoring als `prometheus.googleapis.com|request_queue_length|gauge` verfügbar sein. Das HPA-Manifest sieht dann so aus: ```yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: my-django-api-hpa spec: # Beschreibung des Scaling-Verhaltens behavior: scaleDown: policies: - periodSeconds: 15 type: Percent value: 100 selectPolicy: Max stabilizationWindowSeconds: 300 scaleUp: policies: - periodSeconds: 15 type: Pods value: 4 - periodSeconds: 15 type: Percent value: 100 selectPolicy: Max stabilizationWindowSeconds: 0 # Ziel-Deployment, das skaliert werden soll scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: my-django-api # Skalierungsgrenzen minReplicas: 2 maxReplicas: 20 # Metriken, die zur Skalierung verwendet werden metrics: - type: Pods # Wir messen einen Wert pro Pod pods: metric: # Der vollständige Name der Metrik in Google Cloud Monitoring name: "prometheus.googleapis.com|request_queue_length|gauge" target: type: AverageValue # Wir zielen auf einen Durchschnittswert averageValue: "5" # Skaliere hoch, wenn der Durchschnitt über 5 liegt ``` **Was passiert hier genau?** 1. Django Hurricane liefert's: Jeder Pod deiner Django-Anwendung stellt unter `:8081/metrics` die Anzahl der aktiven Anfragen bereit. 2. Prometheus sammelt's: Der Managed Prometheus Collector in GKE sieht die Annotationen, liest die Metriken regelmäßig aus und speichert sie. 3. HPA beobachtet's: Der HPA fragt kontinuierlich den Wert für `prometheus.googleapis.com|request_queue_length|gauge` ab. 4. HPA reagiert: Er berechnet den Durchschnittswert über alle laufenden Pods. Liegt dieser Wert über unserem Ziel von 5, weist der HPA das Deployment an, die Anzahl der Replicas zu erhöhen (bis zum Maximum von 20). Fällt der Wert wieder, werden Pods elegant heruntergefahren (bis zum Minimum von 2). Mit diesem Setup schaffst du eine hocheffiziente und reaktionsschnelle API, die sich perfekt an die tatsächliche Last anpasst – und das alles mit Bordmitteln von Django Hurricane, Kubernetes und GKE. ## Fazit: Django und Kubernetes – Ein echtes Dream-Team Django Hurricane schließt die Lücke zwischen der Entwicklungsfreundlichkeit von Django und den betrieblichen Anforderungen von Kubernetes. Die neuen Features für Monitoring, Ressourcenmanagement und flexible Konfiguration machen es zu einem unverzichtbaren Werkzeug für alle, die skalierbare und robuste Webanwendungen in der Cloud betreiben wollen. Wenn du deine Django-Projekte auf das nächste Level heben möchtest, gib [Django Hurricane](/produkte/django-hurricane/) eine Chance. Deine Anwendung – und dein DevOps-Team – werden es dir danken. ## Sitemap See the full [sitemap](/sitemap.md) for all pages.