Best Practices für die Planung

In diesem Thema erhalten Sie Tipps für Anwendungsmigrationen zu Google Kubernetes Engine (GKE) oder GK Enterprise, basierend auf Migrationen von realen Anwendungen, die mit Migrate to Containers durchgeführt wurden.

Die Discovery-Client-Befehlszeile des Migrationscenters oder die mcdc-Befehlszeile ist ein Tool, mit dem Sie die Eignung der VM-Arbeitslast für die Migration zu einem Container ermitteln können.

Migrate to Containers wird für bestimmte Arten von Linux- und Windows-Arbeitslasten empfohlen, die unten beschrieben werden.

Geeignet

Linux

Linux-Anwendungen, die sich für die Migration mit Migrate to Containers gut eignen, umfassen die folgenden Anwendungsarchitekturen:

  • Web-/Anwendungsserver
  • Geschäftslogik-Middleware (z. B. Tomcat)
  • Multi-VMs, mehrstufige Stacks (z. B. LAMP)
  • Kleine/mittlere Datenbanken (z. B. MySQL und PostgreSQL)

Darüber hinaus weisen Anwendungen, die sich am besten für die Migration mit Migrate to Containers eignen, die folgenden Betriebseigenschaften auf:

  • Stoßweise auftretende Arbeitslasten mit niedrigen Arbeitszyklen
  • Umgebungen für Entwicklung, Tests und Schulungs-Labs
  • Durchgehend aktivierte Dienste mit geringer Last

Die meisten Linux-Arbeitslasten sind mit der Migration kompatibel, mit Ausnahme der ausdrücklich unter Nicht geeignet aufgeführten Arbeitslasten.

Windows

Windows-Anwendungen, die sich für die Migration mit Migrate to Containers eignen, umfassen Arbeitslasten, die alle der folgenden Kriterien erfüllen:

  • IIS 7 oder höher, ASP.NET mit .NET Framework 3.5 oder höher
  • Web- und Logikstufen
  • WS2008 R2 oder höher

Betriebssystemunterstützung

Migrate to Containers ist mit diesen VM-Betriebssystemen kompatibel.

Nicht geeignet

Linux

Unter Linux umfassen Anwendungen und Server, die für die Migration mit Migrate to Containers nicht geeignet sind, Folgendes:

  • Große In-Memory-Datenbanken mit hoher Leistung
  • VMs mit speziellen Kerneltreibern (z. B. NFS im Kernelmodus)
  • Abhängigkeiten von bestimmter Hardware
  • Software mit Lizenzen, die mit einer bestimmten Hardware-ID-Registrierung verknüpft sind

Windows

Für Windows sind Arbeitslasten ohne IIS 7 oder höher nicht für die Migration geeignet. Andere Arten von Anwendungen, die für die Migration nicht geeignet sind:

  • Anwendungen mit Abhängigkeiten auf GPUs oder TPUs
  • Low-Level-Netzwerkanwendungen
  • Desktop-, RDP- und VDI-Anwendungen
  • Anwendungen mit BYOL

DNS- und Netzwerkzugriffsregeln

Bevor Sie zu GKE migrieren, sollten Sie sich mit den von Ihren migrierten Arbeitslasten verwendeten Netzwerkressourcen und Diensten vertraut machen und darauf achten, dass diese über Ihre Virtual Private Cloud zugänglich und adressierbar sind.

Kubernetes-Dienstnamen planen

Wenn Ihre Arbeitslasten für den Zugriff auf Dienste vom DNS abhängen, müssen Sie Ihr Kubernetes-Namespace-Schema sowie die Netzwerkrichtlinien und Dienstnamen planen.

Die durch den Migrationsprozess generierte Bereitstellungsspezifikation enthält ein vorgeschlagenes kopfloses Service-Objekt vom Typ "ClusterIP". "ClusterIP" bedeutet, dass kein Load-Balancing und eine einzelne interne IP-Adresse des Clusters nur innerhalb des Clusters erreichbar ist. Der Kubernetes-Endpunkt-Controller ändert die DNS-Konfiguration so, dass Einträge (Adressen) zurückgegeben werden, die auf die Pods verweisen. Diese sind mit "app": "app-name" in der Datei "deployment_spec.yaml" gekennzeichnet.

Dienste für Verbindungen zu Pods und Containern erstellen und anwenden

Nach der Migration einer Arbeitslast gelten Hostnamen nicht mehr. Damit Verbindungen zu Ihren Arbeitslasten zugelassen werden, müssen Dienste erstellt und angewendet werden.

Migrierte Namen und IP-Adressen ermitteln und konfigurieren

GKE verwaltet die Datei /etc/Hosts. In Migrate to Containers ist die Anpassung der Hostdatei von der Quell-VM an GKE noch nicht automatisiert. Die Namen und IP-Adressen in der Hostdatei auf der migrierten VM müssen ermittelt und als hostAliases konfiguriert werden.

Abhängige Dienste im selben Namespace platzieren

Dienste, die voneinander abhängig sind, sollten sich im selben Kubernetes-Namespace befinden und für die Kommunikation kurze DNS-Namen verwenden (z. B. app und db). Mit dieser Konfiguration lassen sich auch mehrere Anwendungsumgebungen replizieren, z. B. Produktions-, Staging- und Testumgebungen.

Zugriffsoberfläche mit GKE-Netzwerken steuern

GKE hat ausgefeilte Netzwerkeinstellungen. Auf Pods kann über verschiedene Netzwerke zugegriffen werden, z. B. über das öffentliche Internet, ein VPC-Netzwerk oder ein internes Clusternetzwerk. Damit lässt sich die Zugriffsoberfläche weiter steuern und auf eine Arbeitslast beschränken, ohne dass sich durch das Verwalten von VLANs, Filtern oder Routingregeln zusätzliche Komplexität ergibt.

Eine typische dreistufige Anwendung hat beispielsweise Frontend-, Anwendungs- und Datenbankebenen. Bei der Migration zu Google Cloud wird der Frontend-Dienst mit einem LoadBalancer im VPC-Netzwerk konfiguriert. Außerhalb des GKE-Clusters kann nicht direkt auf die anderen Ebenen zugegriffen werden. Eine Netzwerkzugriffsrichtlinie sorgt dafür, dass der Anwendungsdienst nur über die Frontend-Pods aus dem internen Clusternetzwerk zugänglich ist. Eine weitere Richtlinie gibt vor, dass die Datenbank-Pods nur über die Anwendungs-Pods zugänglich sind.

NFS

NFS-Bereitstellungen als nichtflüchtige Volumes festlegen

Beim Erstellen des Migrationsplans werden NFS-Clientbereitstellungen auf der Quell-VM automatisch erkannt und dem generierten Plan hinzugefügt.

Die Bereitstellungen werden dem Plan zwar hinzugefügt, aber standardmäßig deaktiviert. Das bedeutet, dass Definitionen von PersistentVolume und PersistentVolumeClaim nicht in der Datei deployment_spec.yaml enthalten sind, wenn Sie Migrationsartefakte generieren. Wenn Migrate to Containers PersistentVolume- und PersistentVolumeClaim-Definitionen generieren soll, müssen Sie den Migrationsplan zuerst bearbeiten, um die NFS-Clientbereitstellung zu aktivieren.

Weitere Informationen finden Sie unter NFS-Bereitstellungen anpassen.

NFS-Server im Kernelmodus

VMs mit NFS-Servern, die im Kernelmodus ausgeführt werden, können mit Migrate to Containers nicht zu GKE migriert werden. Diese VMs müssen zu VMs in Compute Engine migriert werden. Alternativ können Sie Filestore für eine cloudnative NFS-Lösung verwenden.

Daten aus NFS-Quellfreigaben migrieren

Wenn Ihre Quell-VM eine NFS-Freigabenbereitstellung verwendet, können diese Daten nicht automatisch migriert werden. Stellen Sie die Freigabe im migrierten Arbeitslastcontainer mit einem nichtflüchtigen NFS-Volume bereit. Wenn Sie eine Remote-NFS-Quellfreigabe verwenden, können Sie auch die Daten in eine andere Dateifreigabe kopieren, die Zugriff mit geringerer Latenz auf den Cluster bietet.

Weitere Informationen über Optionen zum Kopieren von Daten finden Sie hier:

  1. Storage Transfer Service oder Transfer Appliance.

  2. Kopieren von Daten mit gcloud storage rsync (von der Quelldateifreigabe in einen Bucket und dann vom Bucket in die Dateifreigabe in der Cloud)

  3. Lösungen von Drittanbietern wie NetApp SnapMirror für NetApp Cloud Volumes

  4. OSS-Dienstprogramme wie Rsync

Zugänglichkeit der Datenbanken sicherstellen

Wenn Ihre Anwendung auf einer Datenbank basiert, die entweder lokal auf der VM oder auf einem externen Computer ausgeführt wird, müssen Sie dafür sorgen, dass über den neuen migrierten Pod weiterhin auf die Datenbank zugegriffen werden kann. Sie müssen prüfen, ob Ihre Netzwerk-Firewallrichtlinie den Zugriff vom Cluster auf die Datenbank zulässt.

Für die Migration der Datenbank zu Google Cloud empfehlen wir die Verwendung des Database Migration Service.

Alternativ können Sie die Datenbank im Cluster ausführen. Weitere Informationen finden Sie unter Datenbankbereitstellungen in GKE planen.

Dafür sorgen, dass injizierte Metadaten verfügbar sind

Wenn Ihre Anwendungen auf injizierten Metadaten (z. B. Umgebungsvariablen) basieren, müssen Sie dafür sorgen, dass diese Metadaten in GKE verfügbar sind. Wenn dieselbe Methode zum Injizieren von Metadaten nicht verfügbar ist, bietet GKE ConfigMaps und Secrets.

Erforderliche Dienste für den Start in Runlevel 3 konfigurieren

Migrate to Containers-Arbeitslasten erreichen nur Runlevel 3. VMs, die mit Migrate to Containers in GKE migriert wurden, werden im Container unter Linux Runlevel 3 gebootet. Bestimmte Dienste (z. B. X11 oder XDM für Remote-GUI-Zugriff über VNC) werden standardmäßig so konfiguriert, dass sie nur in Runlevel 5 gestartet werden. Alle erforderlichen Dienste sollten so konfiguriert sein, dass sie in Runlevel 3 gestartet werden.

Nicht benötigte Dienste deaktivieren

Migrate to Containers deaktiviert automatisch hardware- oder umgebungsspezifische Dienste sowie eine vordefinierte Gruppe zusätzlicher Dienste, die auf VMs ausgeführt werden. Diese Dienste sind nach der Migration der Arbeitslasten in Container nicht mehr erforderlich.

Beispielsweise deaktiviert Migrate to Containers automatisch iptables, ip6tables und Firewalls. Eine vollständige Liste der durch Migrate to Containers deaktivierten Dienste laden Sie die Datei blocklist.yaml herunter.

Deaktivierte Dienste anpassen

Standardmäßig deaktiviert Migrate to Containers die nicht benötigten Dienste, die oben aufgeführt sind. Sie können auch eine eigene benutzerdefinierte Liste von Diensten definieren, die in einem migrierten Container deaktiviert werden sollen. Legen Sie dazu den Migrationsplan fest, um eine Sperrliste zu definieren. Mit einer Sperrliste geben Sie einen oder mehrere Dienste an, die in einem migrierten Container zu deaktivieren sind.

Migrierte VMs pflegen und aktualisieren

Die während der Migration generierten Artefakte können Sie für Folgendes einsetzen: Softwareaktualisierungen für Anwendungsbetriebssysteme und Betriebssysteme im Nutzermodus, Sicherheitspatches, eingebettete Konfigurationen bearbeiten, Dateien hinzufügen oder ersetzen und Runtime-Software von Migrate to Containers aktualisieren.

Weitere Informationen finden Sie unter Image-Updates nach der Migration.

Nächste Schritte