George Sims beschreibt in einem am 3. September 2026 im CNCF-Blog veröffentlichten Beitrag die Migration eines grundlegenden Authentifizierungsdienstes in einem Kubernetes-Cluster aus dem default Namespace in einen dedizierten Namespace, ohne den Dienst zu unterbrechen. Der Dienst, den der Autor auth-svc nannte, wurde fortlaufend von Dutzenden Diensten verwendet und war für die Authentifizierung der Benutzer in einem gesamten Clusterbereich verantwortlich; sein Ausfall hätte daher die Anmeldung in diesem Bereich verhindert.
Das Problem bestand nicht lediglich darin, ein Deployment in einen anderen Namespace zu verschieben. Die Verbraucher innerhalb des Clusters griffen über den Namen auth-svc.default.svc.cluster.local auf den Dienst zu, während Benutzer außerhalb des Clusters über einen separaten Ingress darauf zugriffen. Außerdem gehörten die konsumierenden Dienste verschiedenen Teams und unterschiedlichen Veröffentlichungsplänen an, wodurch eine gleichzeitige Änderung aller Verweise unpraktikabel wurde.
Warum reicht es nicht aus, den Dienst zu verschieben und die Verweise zu aktualisieren?
Der Autor weist darauf hin, dass die Bereitstellungspipeline die Bereitstellung des Dienstes nur in einem Namespace unterstützte und nicht dafür ausgelegt war, zwei Instanzen gleichzeitig zu betreiben. Eine Änderung der gemeinsamen Pipeline hätte andere Teams beeinflusst, was das Team vermeiden wollte. Zudem gab es eine auf OPA basierende Richtlinie, die das gleichzeitige Vorhandensein identischer Ingress-Regeln in zwei Namespaces verhinderte, um eine mehrdeutige Weiterleitung infolge einer unvollständigen Migration zu vermeiden.
Aus diesem Grund beruhte die Lösung nicht darauf, jeden Verbraucher dazu zu zwingen, die neue Adresse zu kennen, sondern darauf, die alte Adresse vorübergehend gültig zu halten und sie an den migrierten Dienst weiterzuleiten.
ExternalName als Weiterleitungsadresse
Nachdem die tatsächliche Instanz des Dienstes im neuen Namespace authentication bereitgestellt worden war, wurde das alte Service-Objekt in default in einen Dienst vom Typ ExternalName umgewandelt. Sein Name verwies nun auf auth-svc.authentication.svc.cluster.local, sodass Dienste, die die alte Adresse verwendeten, weiterhin auf die neue Instanz zugreifen konnten, ohne dass ihr Code sofort geändert oder sie erneut bereitgestellt werden mussten.
Der Autor vergleicht diesen Mechanismus mit einem Postweiterleitungsdienst: Es ist nicht nötig, alle Personen mit der alten Adresse zu kontaktieren; stattdessen werden Anfragen an den neuen Standort weitergeleitet, bis die Verbraucher ihre Adressen schrittweise aktualisieren. Dieser Ansatz setzt jedoch voraus, dass die Verbraucher einen DNS-Namen verwenden. Wenn einige Systeme eine feste IP-Adresse nutzen oder DNS umgehen, ist die Situation nicht dieselbe und die Migration erfordert eine andere Behandlung.
Vor der Abschaltung der alten Instanz überwachte das Team die Metriken, um sicherzustellen, dass die an die alte Adresse eingehenden Anfragen tatsächlich das neue Deployment erreichten und weder fehlschlugen noch in eine Weiterleitungsschleife gerieten. Nach der Überprüfung wurde die Anzahl der alten Instanzen auf null reduziert, statt sie sofort zu löschen. Dadurch blieb ein schneller Rollback möglich, indem die alten Instanzen bei auftretenden Problemen wieder gestartet wurden; die endgültige Löschung wurde auf einen späteren Zeitpunkt verschoben.
Behandlung des Ingress-Konflikts
Der externe Zugriffsweg benötigte einen Ingress im neuen Namespace, bevor der alte Ingress entfernt werden konnte. Die OPA-Richtlinie verhinderte jedoch, dass beide identischen Regeln gleichzeitig erstellt wurden. Daher verwendete das Team eine vorübergehende und gezielte Ausnahme, statt die Richtlinie vollständig zu deaktivieren: Dem Namespace authentication wurde ein Label hinzugefügt, um während der Migration eine Umgehung der Prüfung auf doppelte Ingress-Regeln zu erlauben, und zwar mit dem Schlüssel policy.example.com/allow-duplicate-ingress: "true".
Während des kurzen Überschneidungsfensters wurde der neue Ingress neben dem alten betrieben; anschließend wurde überprüft, dass der Datenverkehr das neue Deployment erreichte. Danach wurde der alte Ingress gelöscht, und die vorübergehende Ausnahme wurde auslaufen gelassen, statt sie als dauerhafte Einstellung zu betrachten.
Was ändert sich praktisch?
Die Erfahrung zeigt, dass die Migration eines sensiblen Dienstes nicht zwangsläufig eine synchrone Abstimmung mit allen Verbrauchern erfordert, wenn eine klare, auf DNS basierende Abstraktionsgrenze vorhanden ist. Das macht jedoch schrittweise Tests, eine sorgfältige Überwachung und einen Rollback-Plan nicht überflüssig. Das Team führte den Prozess zunächst in der Entwicklungsumgebung und anschließend in der Testumgebung durch und wartete nach dem erfolgreichen Abschluss der Testphase zwei Wochen, bevor es ihn in der Produktion umsetzte.
Die übergreifende Erkenntnis lautet, dass die Ansammlung von Diensten im default Namespace so lange unbemerkt bleiben kann, bis ein Dienst Richtlinien oder Ressourcen benötigt, die an einen dedizierten Namespace gebunden sind. Dann wird die betriebliche Altlast zu einem tatsächlichen Problem. ExternalName bietet einen praktikablen Weg für Dienste, die auf DNS basieren, ist aber keine allgemeine Lösung für Systeme mit festen Adressen. Außerdem müssen das Überschneidungsfenster und die Sicherheitsausnahme bewusst und vorübergehend angelegt sowie von klaren Messwerten begleitet werden.