Mein Name ist Sergey, ich komme von der Firma ITSumma, und ich möchte Ihnen erzählen, wie wir an Backups in Kubernetes herangehen. In letzter Zeit habe ich viel Beratungsarbeit im Bereich der Implementierung verschiedener DevOps-Lösungen für verschiedene Teams geleistet und arbeite insbesondere an Projekten mit K8s. Auf der Konferenz Uptime Day 4, die sich mit Backup in komplexen Architekturen beschäftigte, hielt ich einen Vortrag über das Backup des 'Kuben', und hier ist eine freie Zusammenfassung davon. Ich möchte nur vorweg warnen, dass es sich nicht um eine direkte Anleitung handelt, sondern eher um eine Zusammenfassung von Gedanken zu diesem Thema.
Im Grunde genommen sind Monitoring und Backup zwei grundlegende Werkzeuge zur Verbesserung der Ausfallsicherheit jedes Projekts. Aber in Kubernetes wird doch alles selbst balanciert, werden Skalierungen automatisch vorgenommen, und wenn etwas passiert, wird es einfach wieder hochgefahren... Bei einer ersten oberflächlichen Untersuchung des Themas, auf die Frage, wie man beim Backup von K8s vorgeht, erhielt ich im Internet die Antwort: "Warum?" Viele glauben, dass Kubernetes eine magische Lösung ist, die alle Infrastrukturprobleme beseitigt und sicherstellt, dass das Projekt niemals ausfällt. Doch die Realität sieht anders aus.
Wie ging es uns früher beim Thema Backup? Wir hatten identische Umgebungen für das Hosting – entweder virtuelle Maschinen oder physische Server, Server, auf die wir drei grundlegende Praktiken anwendeten:
- Synchronisierung von Code und Statischen Inhalten
- Synchronisierung der Konfigurationen
- Datenbank-Replikation
Und voilà: Jederzeit können wir auf die Backup-Umgebung umschalten, alle sind zufrieden, wir stehen auf und gehen auseinander.
Was wird uns angeboten, um die permanente Verfügbarkeit unserer Kubernetes-Anwendung zu erhöhen? Der erste Punkt, den die inoffizielle Dokumentation anspricht, ist, mehrere Maschinen zu installieren und viele Master-Instanzen einzurichten – ihre Anzahl sollte in der Lage sein, die Anforderungen für das Erreichen des Quorums innerhalb des Clusters zu erfüllen, und auf jedem Master sollte etcd, API, MC, Scheduler usw. laufen… Und es scheint, als wäre alles wunderbar: Wenn mehrere Arbeitsknoten oder Master ausfallen, wird unser Cluster neu ausbalanciert und die Anwendung bleibt betriebsbereit. Es klingt wieder nach Magie! Aber oft befindet sich unser Cluster in einem einzigen Rechenzentrum, was bestimmte Fragen aufwerfen kann. Was passiert, wenn ein Bagger kommt und ein Kabel ausgräbt, ein Blitz einschlägt oder eine universelle Flut eintritt? Alles wäre kaputt, und unser Cluster wäre nicht mehr vorhanden. Wie geht man mit der Hochverfügbarkeit in Anbetracht dieser Problematik um?
Zunächst einmal sollten Sie einen weiteren Cluster in heißer Reserve haben, also einen Cluster, auf den Sie jederzeit umschalten können. In Bezug auf Kubernetes müssen die Infrastrukturen vollständig identisch sein. Das bedeutet, dass, wenn es irgendwelche speziellen Plugins für die Dateisystemintegration oder maßgeschneiderte Lösungen für Ingress gibt, diese auf Ihren beiden (oder drei, oder zehn, hier kommt es darauf an, wie viel Geld und Ressourcen die Administratoren haben) Clustern vollständig gleich sein müssen. Es ist erforderlich, zwei Sätze von Anwendungen (Deployments, StatefulSets, DaemonSets, CronJobs usw.) klar zu definieren: welche von ihnen kontinuierlich im Reservebetrieb laufen können und welche besser erst beim tatsächlichen Umschalten gestartet werden sollten.
Sollte unser Backup-Cluster also vollständig identisch mit unserem Produktions-Cluster sein? Nein. Während wir früher bei monolithischen Projekten und physischer Infrastruktur praktisch identische Umgebungen pflegten, sollte dies in Kubernetes meiner Meinung nach nicht der Fall sein. Lassen Sie uns ansehen, warum.
Nehmen wir als Beispiel die grundlegenden Entitäten von Kubernetes — Deployments. Diese sollten identisch sein. Die Anwendungen müssen so konfiguriert sein, dass sie jederzeit den Datenverkehr übernehmen können, sodass unser Projekt weiterlaufen kann. Wenn es um Konfigurationsdateien geht, müssen wir darauf achten, ob sie identisch sein sollen oder nicht. Das heißt, wenn wir, als kluge Menschen, keine verbotenen Substanzen verwenden und die Datenbank nicht in K8s lagern, sollten in unseren ConfigMaps die Einstellungen für den Zugriff auf die produktive Datenbank vorhanden sein (deren Backup-Prozess separat eingerichtet wird). Daher müssen wir für den Zugriff auf die Backup-Datenbank eine separate Konfigurationsdatei (ConfigMap) einrichten. Genauso verfahren wir auch mit Secrets: Passwörtern für den Datenbankzugang, API-Schlüsseln; zu jedem Zeitpunkt kann entweder das produktive Secret oder das Backup aktiv sein. Somit haben wir bereits zwei Kubernetes-Entitäten, deren Backup-Versionen nicht identisch mit den produktiven sein sollten. Die nächste Entität, auf die wir achten sollten, ist der CronJob. Backup-CronJobs sollten auf keinen Fall mit dem Set an CronJobs des Produktionsclusters identisch sein! Wenn wir ein Backup-Cluster hochfahren und es mit allen aktivierten CronJobs vollständig hochfahren, werden die Nutzer beispielsweise zwei E-Mails gleichzeitig erhalten statt einer. Oder eine gewisse Synchronisation von Daten mit externen Quellen wird zweimal durchgeführt, was uns dann zu Verzögerungen, Frustrationen und Konflikten führt.
Wie schlagen uns die Leute aus dem Internet vor, einen Cluster zur Sicherung zu organisieren? Die zweithäufigste Antwort nach "Warum?" ist die Nutzung von Kubernetes Federation.
Was ist das? Es handelt sich sozusagen um einen großen Meta-Cluster. Wenn wir die Architektur von Kubernetes betrachten — wo wir einen Master und mehrere Nodes haben — dann gibt es aus Sicht der Federation ebenfalls einen Master und mehrere Nodes, wobei jede Node ein eigener Cluster ist. Das bedeutet, wir arbeiten mit denselben Entitäten und Primitiven wie bei einem einzelnen Kubernetes-Cluster, nur dass wir nicht mit unseren physischen Maschinen, sondern mit ganzen Clustern arbeiten. Innerhalb der Federation erfolgt eine vollständige Synchronisierung der föderativen Ressourcen von Eltern zu Nachkommen. Wenn wir beispielsweise ein Deployment über die Federation gestartet haben, wird es in jedem unserer untergeordneten Cluster bereitgestellt. Wenn wir ein ConfigMap oder Secret nehmen und es über die Federation ausrollen, verteilt es sich auf alle unsere untergeordneten Cluster; dabei ermöglicht die Federation die Anpassung unserer Ressourcen in den Nachfolger-Clustern. Das heißt, wir haben ein ConfigMap genommen, über die Federation bereitgestellt und wenn wir dann etwas auf bestimmten Clustern anpassen müssen, gehen wir zu dem spezifischen Cluster und diese Änderung wird nicht weiter synchronisiert.
Kubernetes Federation ist ein relativ neues Tool, das jedoch nur einen begrenzten Support für die Ressourcen bietet, die Kubernetes bereitstellt. Bei der Veröffentlichung einer der ersten Dokumentationsversionen war nur die Unterstützung von ConfigMaps, Deployment unter ReplicaSet und Ingress erwähnt. Secrets und die Arbeit mit Volumes wurden nicht unterstützt, was das Angebot stark einschränkt. Besonders, wenn wir damit experimentieren möchten, unsere eigenen Ressourcen über die Custom Resource Definition an Kubernetes zu übergeben – in der Federation können wir diese nicht einbringen. Es ist also eine Lösung, die zwar vielversprechend wirkt, uns aber manchmal in Schwierigkeiten bringt. Auf der anderen Seite ermöglicht die Federation eine flexible Verwaltung unseres ReplicaSets. Beispielsweise möchten wir 10 Replikate unserer Anwendung betreiben. Standardmäßig wird die Federation diese Zahl proportional auf die Anzahl der Cluster verteilen. Und wir können das alles auch noch konfigurieren! Wir können festlegen, dass auf dem Produktionscluster 6 Replikate unserer Anwendung laufen sollen, während auf dem Reservierungscluster, zur Ressourcenschonung oder für unsere eigenen Experimente, nur 4 Replikate laufen sollen. Das ist ebenfalls sehr praktisch. Allerdings müssen wir für die Federation neue Lösungen anwenden, während wir etwas hinzufügen oder anpassen und uns gezwungen sehen, mehr nachzudenken…
Kann man den Prozess der Kubernetes-Reservierung einfacher gestalten? Welche Werkzeuge stehen uns überhaupt zur Verfügung?
Zunächst einmal haben wir immer ein CI/CD-System, das heißt, wir gehen nicht manuell auf die Server und schreiben create/apply. Das System generiert YAML-Dateien für unsere Container.
Außerdem gibt es mehrere Cluster; wir haben entweder eines oder mehrere (wenn wir klug sind) Registrys, die wir ebenfalls reserviert haben. Und es gibt ein großartiges Tool namens kubectl, das mit mehreren Clustern gleichzeitig arbeiten kann.
Ich bin der Meinung, dass die einfachste und effektivste Lösung für den Aufbau eines Backup-Clusters ein einfacher paralleler Deploy ist. Es gibt eine Pipeline im CI/CD-System; zuerst bauen wir unsere Container, testen sie und deployen die Anwendungen über kubectl auf mehrere unabhängige Cluster. Wir können gleichzeitig Deployments auf mehreren Clustern durchführen. Entsprechend lösen wir auch die Bereitstellung der Konfigurationen in diesem Schritt. Im Voraus kann man ein Set von Konfigurationen für unser Produktionscluster und ein Set von Konfigurationen für das Backup-Cluster definieren, und im CI/CD-System die Produktionsumgebung auf das Produktionscluster und die Backup-Umgebung auf das Backup-Cluster ausrollen. Im Vergleich zur Föderation müssen wir nicht nach der Festlegung der föderativen Ressource auf jeden Kind-Cluster gehen und etwas überschreiben. Das haben wir im Voraus erledigt. Gut gemacht von uns.
Aber… es gibt… ich hatte geschrieben, dass es „die Wurzel allen Übels“ gibt, aber es sind tatsächlich zwei. Erstens, das Dateisystem. Es gibt irgendeinen PV, oder wir nutzen Speicher von extern. Wenn wir Dateien innerhalb des Clusters speichern, müssen wir nach den alten Praktiken handeln, die aus der Zeit der physischen Infrastrukturen stammen: zum Beispiel mit lsync synchronisieren. Oder mit einem anderen, von Ihnen bevorzugten Ansatz. Wir verteilen alles auf andere Maschinen und leben weiter.
Zweitens, und eigentlich ein noch wichtigerer Streitpunkt – die Datenbank. Wenn wir kluge Leute sind und die Datenbank nicht in Kubernetes halten, erfolgt die Datensicherung nach dem alten Schema – Master-Slave-Replikation, dann Umschaltung, die Replikation holen wir nach und leben gut. Aber wenn wir unsere DB im Cluster haben, gibt es prinzipiell viele fertige Lösungen zur Organisation derselben Master-Slave-Replikation, viele Lösungen, um eine DB innerhalb von Kubernetes hochzuziehen.
Über Datenbanksicherung wurden bereits unzählige Berichte verfasst und ebenso viele Artikel geschrieben. Hier gibt es wirklich nichts Neues zu sagen. Im Großen und Ganzen: Verfolgen Sie Ihre Träume, leben Sie, wie Sie wollen, erfinden Sie auch komplizierte Lösungen, aber denken Sie immer daran, wie Sie alles sichern werden.
Jetzt möchte ich erklären, wie der Prozess des Wechsels zu einer Backup-Plattform im Falle eines Brandes grundsätzlich ablaufen wird. Zunächst implementieren wir parallel die stateless-Anwendungen. Diese beeinflussen nicht die Geschäftslogik unserer Anwendungen und unseres Projekts; wir können ständig zwei Satzentwicklungen von Anwendungen laufen lassen, die gleichzeitig mit dem Verkehr beginnen können. Es ist sehr wichtig, beim Wechsel zur Backup-Plattform darauf zu achten, ob Konfigurationen angepasst werden müssen. Zum Beispiel haben wir einen Produktions-Clustering in Kubernetes, einen Backup-Cluster in Kubernetes und eine externe Master-Datenbank sowie eine Backup-Master-Datenbank. Wir haben vier Optionen, wie diese Anwendungen in der Produktion miteinander interagieren können. Unsere Datenbank kann umschalten, was bedeutet, dass der Verkehr im Produktions-Cluster auf eine neue Datenbank umgeleitet werden muss; ein Cluster kann ausfallen, und wir sind auf die Backup-Plattform umgezogen, arbeiten aber weiterhin mit der Produktionsdatenbank. Schließlich gibt es noch die dritte Option, bei der sowohl das eine als auch das andere ausfällt. In diesem Fall schalten wir beide Anwendungen um und passen unsere Konfiguration an, damit die neuen Anwendungen bereits mit der neuen Datenbank arbeiten.
Welche Schlussfolgerungen können wir also daraus ziehen?
Erste Schlussfolgerung: Mit einem Backup zu leben, ist gut. Aber es ist teuer. Im Idealfall sollte man nicht nur mit einem Backup leben. Idealerweise braucht man mehrere Backups. Zuerst sollte das Backup mindestens in einem anderen Rechenzentrum sein, und zweitens bei einem anderen Anbieter. Das habe ich oft erlebt – und das ist auch in meiner Praxis vorgekommen. Projekte kann ich leider nicht benennen, besonders als es einen Brand im Rechenzentrum gab… Ich dachte: Wir wechseln auf das Backup! Und die Backup-Server standen im gleichen Rack…
Oder stellen Sie sich vor, Amazon wird in Russland gesperrt (das ist passiert). Und was bringt es, dass unser Backup bei einem anderen Amazon liegt? Das ist ebenfalls nicht verfügbar. Daher nochmals: Halten Sie das Backup mindestens in einem anderen Rechenzentrum, idealerweise bei einem anderen Anbieter.
Zweites Fazit: Wenn Ihre Anwendung im Kubernetes mit externen Quellen kommuniziert (das kann sowohl eine Datenbank als auch eine externe API sein), definieren Sie sie unbedingt als Dienst mit externem Endpoint. So müssen Sie beim Wechseln nicht 15 Ihrer Anwendungen neu deployen, die auf dieselbe Datenbank zugreifen. Definieren Sie die Datenbank als eigenen Dienst und greifen Sie so darauf zu, als ob sie sich in Ihrem Cluster befindet: Wenn Ihre Datenbank ausfällt, ändern Sie einfach die IP an einem Ort und arbeiten glücklich weiter.
Und zum Schluss: Ich liebe den "Kuben" sowie die Experimente damit. Außerdem teile ich gerne die Ergebnisse dieser Experimente und generell meine persönlichen Erfahrungen. Deshalb habe ich eine Webinarreihe über K8s aufgezeichnet, willkommen auf für weitere Details.
Quelle: habr.com
