Sichere Server-Bereitstellung mit Canary-Tests

• Ein Erfahrungsbericht von Taeho Kim von VCNC, dem Betreiber von Tada, über Canary-Deployments in einer Kubernetes-Umgebung.

• Der Name Canary-Deployment leitet sich davon ab, dass Bergleute früher Kanarienvögel in Käfigen mit in Kohleminen nahmen, um Gasaustritte zu erkennen.

• Beim Anheben der Major-Version von Spring Boot werden auch die Versionen abhängiger Bibliotheken zwangsweise geändert. Um dadurch entstehende Performance-Probleme oder nicht getestete Ausfälle zu minimieren, wurde ein Canary-Deployment versucht.

• Für Deployments in Kubernetes wird der Paketmanager Helm verwendet. Die Paketeinheit von Helm wird als „Chart“ bezeichnet, und wenn ein Chart in einem Kubernetes-Cluster installiert wird, entsteht ein Release.

• Für die Canary-Version wurden Chart und Release erstellt, und dem Ingress-Controller wurden Annotations hinzugefügt, sodass nur ein festgelegter Anteil der Anfragen an den Canary-Ingress geleitet wird.

Zukünftige Aufgaben

• Wenn bei einem Canary-Release Probleme auftreten, ist es schwer festzustellen, ob die Ursache in den Änderungen der Canary-Version liegt oder ob es sich um bereits zuvor auftretende Probleme handelt. Deshalb wird eine Methode benötigt, bei der eine Kontrollgruppe mit demselben Anteil betrieben und die Metriken verglichen werden.

• Da ein Teil der Anfragen unabhängig vom Nutzer an die Canary-Version gesendet wird, kann es selbst bei Problemen in der Canary-Version durch erneute Versuche dazu kommen, dass die bestehende Version die Anfrage verarbeitet und erfolgreich abschließt. Insgesamt kann jedoch der Anteil der Nutzer steigen, die Probleme der Canary-Version erleben. Daher scheint eine Routing-Steuerung zur Canary-Version nach Nutzergruppen — ähnlich wie Sticky Handling beim LB — mehr Kontrolle zu ermöglichen.