Blog
Migration zu Kubernetes: Vorteile und Best Practices

Migration zu Kubernetes: Vorteile und Best Practices

17
min read
Daniel Yavorovych
June 23, 2018

Die Änderung der Serverarchitektur ist für jedes Projekt immer ein großer Schritt. Hier bei Dysnix führen wir die meisten unserer Kunden durch diesen Prozess, indem wir Kubernetes-Dienste bereitstellen. Und jedes Mal war es eine andere Erfahrung.

Wenn sich Ihr Unternehmen für eine Kubernetes-Migrationsstrategie entscheidet, gibt es dafür natürlich einen guten Grund: Erhöhung der Stabilität, Vereinheitlichung der Umgebung und schnelles Autoscaling.

Kubernetes passt am besten zu Mikroserver-Architekturen. Tatsächlich gilt: Je unterschiedlicher die Cluster-Entitäten sind, desto besser. Dies ermöglicht:

  • Präzise Grenzwerte für jeden Dienst festlegen
  • Nur notwendige Verbindungen herstellen
  • Auswahl des eindeutigen Kubernetes-Entitätstyps für jeden Dienst (Deployment, ReplicationController, DaemonSet usw.)

Bevor ich den Prozess auch nur näher erkläre, möchte ich, dass Sie sich vorstellen, echtes Ziel Ihrer Migration.

  • Warum planen Sie eine Migration zu Kubernetes?
  • Wenn die Logik Ihrer App geändert werden muss, verfügen Sie über genügend Ressourcen, um sie zu ändern? Kann das Design Ihrer App als „container-native“ bezeichnet werden?
  • Welche Kubernetes-Vorteile erwarten Sie danach?

Diese und andere Fragen sollten berücksichtigt werden, bevor Sie mit der Migration zu Kubernetes beginnen, da dieser Prozess für Entwickler und Unternehmen im Allgemeinen kein Witz ist. Unterhalb der Spitze des Eisbergs kann ein ganzer Berg an Nacharbeiten auf Ihr Team warten. Ihre Mitarbeiter müssen also auf jeden Fall darauf vorbereitet sein und genau wissen, wofür diese Maßnahmen gedacht sind. Auf der anderen Seite kann Ihr Anwendungsdesign oder Ihre Geschäftslogik in Ihrem speziellen Fall keine Vorteile von Kubernetes herausholen, selbst wenn die Kubernetes-Migration reibungslos endet.

In diesem Artikel werde ich das Fachwissen von Dysnix zur Migration zu Kubernetes-Prozessen und -Tools teilen, häufige Fehler beschreiben und wie man sie vermeidet.

Ground Zero: Zerlegung einer App und Neuerfindung als Kubernetes-native

Als logische Fortsetzung des vorherigen Punktes gehe ich vom strategischen zum taktischen Aspekt über. Schauen wir uns an, was Sie beachten müssen und was Sie mit den Antworten tun müssen, die Sie aus den Fragen zu den „Zielen“ erhalten.

Prüfen und visualisieren Sie Ihre aktuelle Architektur

Ihre Dokumentation, Visualisierungstools und eine umfassende Planung helfen Ihnen dabei, den Zeit- und Ressourcenumfang abzuschätzen, den Sie für die Migration benötigen. Beschreiben Sie jeden Teil Ihrer App und die Verbindungen dazwischen und markieren Sie sie auf dem Schema. Verwenden Sie nach Belieben eine Bereitstellungs- oder sechseckige Ansicht, oder sogar ein einfaches Datenflussdiagramm macht dasselbe. Nachdem dieser Schritt abgeschlossen ist, erhalten Sie eine vollständige Übersicht der Module und wie sie miteinander verbunden sind. Auf diese Weise erhalten Sie ein umfassendes Verständnis dafür, was genau zu Kubernetes migriert wird.

Überdenken Sie die aktuelle App-Architektur

Trotz der Begeisterung, die Sie in dieser Phase verspüren könnten — „Lass uns alles neu schreiben!“ — Sie müssen cool bleiben und die Migrationsreihenfolge Ihrer Module von der einfachsten zur schwierigsten ändern. Mit diesem Ansatz werden Sie in der Lage sein, Ihr Team zu schulen und sich auf die „Herkulesaufgaben“ vorzubereiten. Oder versuchen Sie, Ihren Plan anhand eines anderen Konzepts vorzubereiten: Wählen Sie die wichtigsten Module aus, beispielsweise diejenigen, die für die Arbeit mit der Geschäftslogik verantwortlich sind, und legen Sie sie als die wichtigsten fest. Andere Module können als sekundär markiert werden und dann bearbeitet werden, nachdem der Kern der App zu k8s migriert wurde.

Die Aufgaben, die Sie hier lösen müssen, sind:

  1. Finden Sie eine geeignete Protokollierungsmethode für Ihre App;
  2. Wählen Sie aus, wie Ihre Sitzungen gespeichert werden sollen (z. B. im gemeinsamen Speicher);
  3. Überlegen Sie, wie Sie den Dateispeicher für Ihre zukünftige k8s-App implementieren werden;
  4. Denken Sie über neue Herausforderungen beim Testen und Beheben von Problemen für Ihre App nach.

Ich sollte erwähnen, dass je nach Art Ihrer App einige Phasen mit der Zeit schrumpfen oder sich erweitern können, und das ist in Ordnung. Darüber hinaus müssen Sie möglicherweise zusätzliches Personal einstellen und das Fachwissen Ihres Teams vervielfachen. Jedes Unternehmen erlebt die Migration individuell.

Aber lassen Sie uns in einer kurzen Beschreibung auf den gesamten folgenden Prozess zurückkommen:

  • Phase der Containerisierung. Hier bereiten Sie einen Docker-Startcontainer mit Konfigurationen für Ihre App vor. Er beschreibt die Umgebung, die Programmiersprachen und andere Einstellungen für das Docker-Image. Später werde ich in einem praktischen Anwendungsfall beschreiben, wie ein Container gestartet wird.
  • Erstellen Sie das Schema Ihrer App-Module und wählen Sie Kubernetes-Objekte für jedes Modul aus. Diese Phase verläuft in der Regel reibungslos, da es eine Vielzahl von Typen und Optionen für die Komponenten Ihrer App gibt. Anschließend sollten Sie YAML-Dateien schreiben, um zugeordnete Kubernetes-Objekte zu erstellen.
  • Anpassung der Datenbank. Die gängigste Praxis ist, es so zu lassen, wie es ist, aber eine Verbindung zu einer neuen Kubernetes-basierten Anwendung herzustellen. Nachdem Sie einen Docker-Container gestartet haben, benötigen Sie nur noch die Entscheidung der Geschäftsleitung, um die gesamte App, einschließlich Ihrer Datenbank, zu containerisieren.

Jetzt haben Sie ein allgemeines Verständnis der Einführung von Kubernetes. Lassen Sie uns mit technischen Besonderheiten, bewährten Methoden für die Anwendungsmigration und Anwendungsfällen für Kubernetes näher auf das Thema eingehen.

Migrieren Sie die Anwendung Schritt für Schritt zu Kubernetes

Speicherung persistenter Daten

Bei der Entwicklung der Projektarchitektur versuchen wir, das Speichern von Daten in Dateien vollständig zu vermeiden. Warum?

  • Die meisten Plattformen (AWS, Google) ermöglichen nur die Installation von Speicher auf Blockebene von einem einzigen Punkt aus. Es schränkt die horizontale Skalierung der Container ein, die von Persistent Volume verwendet wird.
  • Wenn ein Dateisystem viele Dateien enthält, treten Probleme beim Zugriff auf das Dateisystem auf, was die allgemeine Reaktionsfähigkeit der Ressource erheblich beeinträchtigt.

Um dies zu vermeiden, gibt es folgende Möglichkeiten:

  • Wir speichern statische Inhalte in Object Storage. Wenn das Amazon ist, mit dem wir es zu tun haben, verwenden wir S3. Wenn es sich um einen Hardware-Cluster handelt: Ceph RDB für persistenten Speicher und Ceph Rados für S3.
  • Wir versuchen, die meisten Daten auf DB- und/oder NoSQL-Speichern (wie ElasticSearch) zu speichern.
  • Wir speichern Sessions und Cache in In-Memory-Datenbanken (redis/memcache).
Storing persistent data

Wenn jedoch Persistent Volume erforderlich ist, sollte es ordnungsgemäß vorbereitet werden.

  1. Sammeln Sie zunächst die Liste ALLER Kataloge, die persistente Daten speichern. Wenn Sie dies nicht tun, werden die Daten ohne Fehler aufgezeichnet, aber nach dem Neustart des Containers oder der Migration auf einen anderen Knoten gehen ALLE Daten VERLOREN.
  2. Versuchen Sie, die Kataloge so zu kompilieren, dass alle Ihre Daten unten in einem einzigen Katalog gespeichert werden, da Sie nur ein Persistent Volume für einen Container verwenden können müssen. Diese Regel ist nicht immer anwendbar, und manchmal ist es einfach notwendig, Daten auf mehrere PVs zu verteilen. Nur der Architekt der Anwendung, der den Zweck eines persistenten Speichers und das vorgesehene Datenvolumen, das dort gespeichert werden soll, kennt, kann die endgültige Antwort geben.
  3. Wählen Sie ein geeignetes Dateisystem aus. Ext4 eignet sich für die meisten Aufgaben, aber manchmal kann die Wahl eines geeigneteren Dateisystems die Leistung verbessern.
  4. Wählen Sie eine optimale PV-Größe. Keine Sorge, Sie können es bei Bedarf problemlos erweitern. Wenn ein Dateisystem jedoch überlastet ist, beansprucht die Größenänderung noch mehr Ressourcen und kann die Leistung beeinträchtigen.

Wenn alle Anforderungen erfüllt sind, erstellen Sie eine YAML-Datei für Kubernetes Persistent Volume. Im Fall von AWS könnte das so aussehen:


apiVersion: v1
    kind: PersistentVolume
    metadata:
        name: example-my-pv
        annotations:
            volume.beta.kubernetes.io/storage-class: "default"
    spec:
        capacity:
            storage: 100Gi
        accessModes:
            - ReadWriteOnce
        awsElasticBlockStore:
            volumeID: vol-0dc1fcf80ac20300a
            fsType: ext4
Daniel Yavorovych
CTO and Co-founder at Dysnix
Brainpower and problem-solver, meditating and mountain hiking.
Table of content
In die Zwischenablage kopiert
Fügen Sie es ein, wo immer Sie möchten