Kubernetes Ingress mit Rate-Limits, CORS und Basic Auth pro Service

• Welchen Ingress-Controller soll ich nehmen?

  ingress-nginx ist die bewährte Wahl und kann Body-Größe und Buffering. Envoy Gateway bietet feinere Rate-Limits, Circuit Breaker und Header-Regeln und bündelt alle Services hinter einem Load Balancer. Beide lassen sich parallel betreiben.

• Wie wechsle ich einen Service auf einen anderen Controller?

  Über „Switch class…“ im Netzwerk-Block. Vorher zeigt ein Plan pro Host, ob Clusterward den Record umzieht oder neu anlegt oder ob Sie ihn selbst ändern, und was mit dem Zertifikat passiert. Dann rollt Clusterward den Service mit beiden Controllern aus, jeder mit seiner eigenen Klasse, zieht die Records in registrierten Zonen um und schließt den Wechsel eine Stunde, nachdem alle Hosts auf die neue Adresse zeigen. Bis dahin lässt er sich abbrechen; zeigt schon ein Host auf die neue Adresse, läuft der Rückweg wieder als Cutover.

• Was passiert bei Hosts hinter dem Cloudflare-Proxy?

  Liegt der Host in einer registrierten Cloudflare-Zone, liest Clusterward den Record über die Cloudflare-API, zieht ihn selbst um und erkennt so auch hinter dem Proxy, wann der Umzug erledigt ist. Manuell bleibt nur ein Host hinter dem Proxy in einer Zone, die nicht registriert ist: Sie stellen den Record um und schließen den Wechsel per Klick ab. Hosts ohne eigenes Zertifikat bekommen auf Envoy ein selbstsigniertes Origin-Zertifikat, damit Cloudflare im Modus „Full“ nicht mit Fehler 525 abbricht; für „Full (strict)“ braucht der Host Let’s Encrypt oder ein Wildcard.

• Wechseln auch Helm-Services den Controller?

  Ja, wenn das Chart einen Schalter ingress.mode hat: Clusterward setzt ihn beim Start auf beide Controller und am Ende auf den neuen, bei einem Abbruch zurück auf den alten. Ein Chart ohne diesen Schalter rendert sein Ingress selbst; dort lehnt Clusterward den Wechsel ab, statt still nichts zu tun.

• Woher weiß ich, was ein leeres Feld bewirkt?

  Jedes Feld zeigt den Standard des aktiven Controllers, der andere steht im Tooltip. Gefüllte Felder tragen die Markierung „überschrieben“, und die Übersicht listet nur Ihre Abweichungen.

• Wie funktioniert Basic Auth?

  Die htpasswd-Zeilen stehen in einer Umgebungsvariable des Services, gern als Secret. Beim Deployment kopiert Clusterward sie in ein Kubernetes-Secret für den Controller. Fehlt die Variable, scheitert das Deployment, statt den Host ohne Schutz zu veröffentlichen.

• Sieht meine App die echte IP der Besucher?

  Ja, wenn der Cluster das Proxy-Protokoll nutzt; bei neuen Clustern ist es Standard. Hinter Cloudflare wertet Clusterward den Header der Cloudflare-Edges aus, aber nur von Cloudflares veröffentlichten Adressen.

• Kann ich einen Host auf bestimmte IP-Adressen beschränken?

  Ja, pro Domain mit einer Liste erlaubter Adressbereiche. Das wirkt für Hosts ohne Cloudflare-Proxy und setzt das Proxy-Protokoll voraus, sonst sieht der Controller nur den Load Balancer.

• Wie ruft eine App einen Service einer anderen Umgebung auf?

  Über die interne Adresse, die die Port-Karte des Services zeigt (http://svc-<id>.<namespace>.svc.cluster.local). Ist eine der beiden Umgebungen isoliert, erlauben Sie die aufrufende Umgebung im Isolationsdialog unter „Who else may call in“; Clusterward legt die passenden Regeln auf beiden Seiten an.

• Was passiert, wenn ich die Standard-Klasse des Clusters ändere?

  Clusterward verweigert die Änderung, solange Services ohne eigene Klasse einen Host darüber ausliefern, und listet sie auf. „Festlegen und wechseln“ gibt ihnen die alte Klasse fest, danach wechselt der Standard, ohne dass ein Service umzieht.

Ihre Frage ist nicht dabei? Schreiben Sie uns, wir antworten in der Regel am selben Werktag.