Hallo allerseits!
In diesem Artikel haben wir uns entschlossen, ein wenig darüber zu spekulieren, wann und warum Unternehmen Kubernetes benötigen. Wie schwierig ist die Technologie für den Einstieg, wie schnell und wie wird sie sich auszahlen. Lohnt es sich und was alles bedroht? Wir haben uns nicht die Aufgabe gestellt, eine eingehende technische Überprüfung zu schreiben, von der es viele gibt, aber in den folgenden Materialien werden wir definitiv unsere Best Practices in Bezug auf Anwendungsarchitektur und Stabilität unter Kubernetes teilen. Jetzt konzentrieren wir uns darauf, ob das Spiel die Kerze wert ist und was wir auf dem Weg nach draußen bekommen.
Time-to-Market - die Geschwindigkeit, mit der Aktualisierungen auf den Markt gebracht werden - wird heute zu einem Schlüsselfaktor für die Effektivität von IT-Lösungen. Das Produkt muss jeden Tag verbessert werden: Fügen Sie neue Funktionen und Module hinzu, halten Sie die Dokumentation und Skripte in einwandfreiem Zustand. Gleichzeitig sollten Online-Systeme reibungslos funktionieren und aktualisiert werden, ohne die Benutzer zu beeinträchtigen.
Wächter des unauffälligen kontinuierlichen Updates sind Microservices, Container und die Infrastruktur für ihre Orchestrierung - Kubernetes (oder K8S, wie es in technischen Kreisen genannt wird).
Wie Kubernetes kontinuierliche Systemaktualisierungen bereitstellt
Die Hauptaufgabe beim Aktualisieren einer IT-Lösung besteht darin, den ordnungsgemäßen Betrieb nach der Übertragung von der Entwicklungsumgebung auf die Produktplattform sicherzustellen. Und auch im reibungslosen Betrieb des Systems zum Zeitpunkt der Produktaktualisierung.
Das Problem liegt in der Tatsache, dass die Einstellungen der Entwicklungsumgebung und der Industrieserver häufig nicht übereinstimmen. Container beheben dieses Problem, indem sie alle Softwarekomponenten in einem Paket kombinieren, das von der externen Umgebung isoliert ist. Auf diese Weise können Sie Anwendungen schnell und zuverlässig in jeder Infrastruktur bereitstellen und die Codebasis des Systems aktualisieren.
Von Benutzern nicht bemerkt, erfolgen Aktualisierungen durch Duplizieren von Containern und sequentielle Umleitung von Benutzern von einem zum anderen. Für die Containerverwaltung (Orchestrierung) verwenden wir Kuberenetes. Letztendlich erleichtert es das Lösungsmanagement, die Bereitstellung und Aktualisierung, die Leistungsüberwachung und das Debuggen im Fehlerfall.
Wenn ein Unternehmen Kubernetes braucht
Es ist Zeit für Unternehmen, über einen Wechsel zur Kubernetes-Plattform nachzudenken, wenn:
- Ein Projekt oder System ist ein wichtiges Werkzeug für Unternehmen und muss daher fehlertolerant sein und weiter funktionieren, auch wenn ein Teil nicht in Ordnung ist.
- Das System ist stark ausgelastet und behält schnelle Updates oder Verbesserungen bei.
- Das System benötigt regelmäßig zusätzliche Kapazität. Und braucht sie sofort.
- Und mit all dem wird die Geschwindigkeit der Bereitstellung von Updates für die industrielle Umgebung in Wochen, Monaten, Jahren, aber niemals - Stunden oder Tagen - gemessen.
Sie benötigen Kubernetes auch als Werkzeug zur Automatisierung und Standardisierung der Arbeit mit der Lösung, wenn zusätzlich zu den oben genannten:
- Es gibt keine Isolation zwischen den IT-Systemen des Unternehmens und beide können sich gegenseitig beeinflussen.
- Wenn Sie jedes Mal ein separates Skript schreiben müssen, um mit den Parametern des Servers zu kommunizieren, auf dem das System bereitgestellt wird, können Sie diesen Prozess nur von Hand skalieren.
- Es gibt Schlüsselpersonen im Entwicklungsteam - Träger von „geheimem Wissen“ über das Projekt oder System, und sie scheinen einzigartig und unersetzlich.
Der Wechsel zu Kubernetes ist im Wesentlichen ein Muss für Unternehmen, die Online-Informationssysteme rund um die Uhr unterstützen müssen.
Warum Kubernetes?
Kubernetes ist nicht die einzige Alternative für die kontinuierliche Integration und Bereitstellung (CI / CD). Aber es war Kubernetes, das zum Industriestandard für die Verwaltung von Systemen wurde, die eine hohe Verfügbarkeit erfordern.
Für uns als Entwickler sind die entscheidenden Argumente für Kubernetes folgende:
- Die Plattform konzentriert sich auf Anwendungen, nicht auf die Infrastruktur.
- Kubernetes eignet sich für die Arbeit mit einem Rechenzentrum sowie mit mehreren Rechenzentren, die in verschiedenen Städten verteilt sind.
- Einfache Lösungsunterstützung durch klare Dokumentation und eine aktive Community.
- Flexible Konfiguration verschiedener Anwendungen, sichere Verkehrsverteilung.
- Docker-Container-Unterstützung.
Was sind die Vorteile des Kubernetes-Geschäfts?
- Flexible Konfiguration und automatisierter Update-Prozess
Sie bestimmen selbst, welcher Teil des Systems in Betrieb genommen werden soll. Mit Kubernetes können Sie einen kurzen Release-Zyklus durchführen. Alle Vorgänge - vom Quellcode des Systems bis zur Freigabe in die Produktumgebung - erfolgen automatisch. Sie benötigen kein Team von Ingenieuren, damit das System funktioniert. Aktuelle Updates wirken sich nicht auf die Leistung des Systems aus und können jederzeit für Entwickler durchgeführt werden. - Platzierung und Skalierung des Systems
Das System kann sowohl von der Rechenleistung des Kunden (oder im Rechenzentrum) als auch von jedem Cloud-Anbieter, z. B. Amazon oder Azure, abhängig gemacht werden. Jedes Maß an Leistung und Fehlertoleranz kann leicht durch Skalieren des Clusters erreicht werden. - Standardisierung und Selbstdokumentation
Die Lösung erfordert keine Anweisungen. Es ist selbstdokumentierend und wird sofort automatisch in eine Nutzungseinheit - einen Container - verpackt. Wir beschreiben die Konfiguration in Kubernetes als Plan / Diagramm. Wir schreiben keine Skripte, die die Umgebung vorbereiten, wie es vor Kubernetes war. Stattdessen geben wir an Kubernetes Informationen (ein Diagramm) weiter, wie die Lösung funktionieren soll. Und er selbst setzt dieses Schema um.
Entwickler schreiben jetzt eine Anwendung, um in einem Container zu arbeiten. Die Entwickler von DevOps schreiben ein Diagramm, wie eine Anwendung in einem Container funktionieren soll, und Kubernetes selbst führt die Aufgaben zum Erstellen einer Lösung aus.
Die Kubernetes-Technologie ist standardisiert. Es ist für Sie einfach, einen neuen Mitarbeiter in Ihrem Freigabesystem zu schulen oder das System an einen neuen Auftragnehmer zu übertragen.
Die endgültige Konfigurationsbeschreibung, die Kubernetes erstellt, ist auch die Dokumentation für das System. Aus den Namen geht sofort hervor, welche Parameter konfiguriert sind und wofür sie bestimmt sind.
Aus diesem Grund universalisiert die Kubernetes-Plattform insgesamt Releases, Updates und Releases der Anwendung.
- Schmerzlose Live-Tests
Der Testprozess der Lösung hat sich geändert. Entwickler können bei Bedarf Umgebungen für automatisierte Tests erstellen, die mit den Produktumgebungen identisch sind. Die allgemeinen Protokolle zur Funktionsweise der Anwendung und zur Funktionsweise von Kubernetes mit der Anwendung helfen dabei, Probleme zu untersuchen und Fehler noch schneller zu finden.
Was für eine Geschäftsumstellung auf Kubernetes erforderlich ist
Kubernetes selbst wird nur ein kleiner Teil Ihres neuen Systems sein. Sie müssen darauf vorbereitet sein, dass Kubernetes als Tool zur Standardisierung des gesamten Entwicklungszyklus, zum Aktualisieren und Veröffentlichen von Anwendungen zum Zeitpunkt des Übergangs eine Änderung in allen Bereichen mit sich bringt: Softwarearchitektur, Entwicklungsprozess und Wartung der Infrastruktur.
- Lösungsarchitektur
Aus Sicht des Produkts ist der Übergang nur möglich, wenn das System implementiert oder auf eine Microservice-Architektur aktualisiert wird, die auf Diensten basiert, die in Containern verpackt werden können (zustandslose Dienste). - Entwicklungsprozess
Aus Sicht des Entwicklungsprozesses beinhaltet der Übergang in erster Linie eine Änderung des Denkens. Jegliche im letzten Moment hinzugefügten Situationsverbesserungen und „Krücken“ sind vollständig ausgeschlossen. Ein IT-Lösungsentwickler kann nur als ein Team arbeiten, das zunächst ein zunächst getestetes, unterstütztes, verpacktes und zerlegbares Produkt herstellt. Alles sollte logisch von der ersten Codezeile bis zur Operation erstellt werden. - Aktualisierungsprozess
Bereits in der Phase der Entwicklung der Anwendungsarchitektur müssen Sie darüber nachdenken, wie Sie die Lösung aktualisieren können, ohne anzuhalten. Und verstehen Sie sofort, wie Sie die Datenbank und die API aktualisieren, wie logisch es ist, mehrere Versionen der Anwendung zu unterstützen, und berücksichtigen Sie dabei, dass Benutzer während des Updates mit dem System arbeiten und in verschiedene Versionen fallen können.
Eine weitere Überlegung hängt mit der Tatsache zusammen, dass beim Wechsel zu Kubernetes die Infrastruktur im schreibgeschützten Modus funktioniert. Um das System zu aktualisieren, müssen Sie neue Versionen der Anwendungsabbilder erstellen und Kubernetes anweisen, die neue Version zu verwenden. Später wird die alte Version und deaktiviert wird sich selbst löschen.
Damit können Systemverbesserungen und Änderungen in der Arbeitstechnologie nicht vermieden werden. Das Bewegen wird nicht schnell sein. Sie müssen das Paradigma jedoch nur einmal ändern.
Fall. Wie wir das Microservice-System auf Kubernetes übertragen haben
Wir betreiben in einer Produktumgebung eine hoch ausgelastete Lösung, die auf einer Microservice-Architektur basiert und mehr als 300.000 Transaktionen pro Tag und zu Spitzenzeiten von 60 bis 80.000 pro Stunde überträgt. Wir aktualisieren das Produkt regelmäßig. Es gibt auch dringendere Versionen, die zuvor erforderlich waren, um das System oder einen Teil seiner Funktionalität für eine Weile auszusetzen.
Wir sind ohne K8S in die Lebensmittelumgebung gegangen, aber wir haben das System zunächst mit einem Auge entwickelt. Die Übersetzung der Lösung in Kubernetes dauerte 6 Wochen. Wir haben uns in folgende Richtungen bewegt:
1) Einrichten der Bereitstellungspipeline
a. Konfigurieren der Pipeline für die kontinuierliche Montage, Prüfung und Anwendungsaktualisierung (CI / CD) in Testumgebungen.
b. Richten Sie kontinuierliche Updates in einer industriellen Umgebung ein.
c. Vorbereitung und Konfiguration der Umgebung so nah wie möglich an der industriellen Umgebung (Preprod). Wir haben den Cluster neben den aktuellen virtuellen Maschinen bereitgestellt und getestet.
d. Entwicklung eines Plans für die Migration in ein industrielles Umfeld.
Alles scheint einfach zu sein, wir haben eine CI / CD-Pipeline für alle Umgebungen und Sie können wechseln, aber es ist zu früh!
2) Auswahl der Clusterkonfiguration
Einige Wochen haben wir uns mit der Auswahl der stabilsten Konfiguration von Komponenten und Versionen des Kubernetes-Clusters befasst: Betriebssystem + Docker + Kubernetes.
Wir haben 3 verschiedene Konfigurationen von Betriebssystemen getestet (Ubuntu, CentOS, neueste Versionen von Oracle Linux). Auf jedem Betriebssystem wurden zwei verschiedene Versionen von Docker und Kubernetes überprüft - diejenige, die in den neuesten Versionen der Standardbetriebssystempakete geliefert wurde, und die neueste Version des Herstellers. Infolgedessen zeigten die Konfigurationen aus der Standarddistribution von Oracle Linux die größte Stabilität, und wir haben uns für sie entschieden.
3) Konfigurieren der Containereinstellungen
Wir haben mehr Zeit damit verbracht, die Parameter des Containers zu optimieren - wir haben die Anforderungen für Speicher, Festplatte und Prozesse festgelegt.
Und erst nachdem wir dies alles getan und verschiedene Parameter der Systemfunktion (Stabilität, Fehlertoleranz und andere) in der Vorprode unter Last in der Nähe der Kampflasten getestet hatten und das System stabil funktionierte, gingen wir zur Endphase über - der Migration.
Dann war alles einfach.
Tag C. Migration
Für die Kampfmigration haben wir die Zeit mit der minimalen Systemlast gewählt: die minimale Anzahl von Benutzern und das Fehlen einer erhöhten Last gemäß dem Zeitplan der internen Arbeit der Systemalgorithmen.
Die Ausfallzeit des Systems betrug ungefähr eine Stunde und hatte praktisch keine Auswirkungen auf die Benutzer. Die Migration selbst bestand darin, Benutzer von einem System auf ein anderes zu wechseln und festzustellen, dass alles in Ordnung war.
Leben mit Kubernetes
Jetzt hat der Aktualisierungsprozess keine Auswirkungen auf die Systemleistung. Er kann jederzeit für Entwickler ausgeführt werden und sieht wie folgt aus:
- Die Entwickler haben eine Überarbeitung vorgenommen, diese getestet und den Code an die Veröffentlichung gesendet.
- Der Code wurde automatisch zusammengestellt, in Docker-Images verpackt und in einem privaten Docker-Repository veröffentlicht.
- Kubernetes löst automatisch neue Versionen von Diensten aus, überprüft, ob die Dienste ordnungsgemäß funktionieren, schaltet Benutzer auf die Verwendung neuer Versionen von Diensten um, stoppt die Arbeit alter Versionen und entfernt sie aus dem Cluster. Das Update hat stattgefunden.
Zusammenfassung unserer Erfahrungen
Sie benötigen Kubernetes, wenn:
- Eine hohe Verfügbarkeit des Systems ist erforderlich.
- Das System entwickelt sich dynamisch und Sie müssen Änderungen an der Produktumgebung mit geschlossenen Augen vornehmen.
- Sie möchten als ein einziges Team vom Code bis zur Produktumgebung arbeiten.
- Sie erstellen ein dynamisches, sich weiterentwickelndes System, das Sie jahrelang betreiben werden.
Kubernetes ist „teuer“, da für den Einstieg in die Technologie Folgendes erforderlich ist:
- Studieren durch Entwickler verwandter Technologien.
- Überprüfung der Prozesse für Design, Entwicklung, Bereitstellung, Test und Umweltmanagement.
- Erfahrung im Betrieb von Kubernetes selbst: Jetzt müssen Sie nicht nur Ihr System, sondern auch die Kubernetes-Anwendungsdienste überwachen.
Kubernetes sehr schnell zurückzahlen:
- Das Systemaktualisierungsverfahren ist viel einfacher und schneller. Entwickler werden von einem ganzen Arbeitsblock befreit.
- Jeder neue Spezialist wird das Projekt bereits auf Schienen betreten.
- Der Förderer ist transparent und automatisiert.
- Die Erfahrung wird von Ihrem Team für andere Systeme wiederholt.
- Sie aktualisieren das System, ohne es außer Betrieb zu setzen, was bedeutet, dass Sie das Geschäft nicht stoppen.
PS Praktischer Rat: Teilen Sie den Zugang zur Technologie in zwei Phasen: Entwickeln Sie ein System mit der richtigen Microservice-Architektur und verschieben Sie es unter die Kontrolle von K8S. Somit wird der Übergang unter Kubernetes nicht zu einem globalen Refactoring.