Best Practices für die Planung

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

Migrate for Anthos and GKE stellt Tools bereit, die Sie auf einer VM-Arbeitslast ausführen, um die Eignung der Arbeitslast für die Migration zu einem Container zu ermitteln. Weitere Informationen finden Sie unter:

Migrate for Anthos and GKE werden für bestimmte Arten von Linux- und Windows-Arbeitslasten empfohlen, die unten beschrieben werden.

Geeignet

Linux

Zu den Anwendungen, die sich für die Migration mit Migrate for Anthos and GKE gut eignen, gehören 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 for Anthos and GKE 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 for Anthos eignen, umfassen Arbeitslasten, die alle 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 for Anthos and GKE sind mit diesen VM-Betriebssystemen kompatibel.

Nicht geeignet

Linux

Unter Linux sind folgende Anwendungen und Server für die Migration mit Migrate for Anthos and GKE ungeeignet:

  • 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 for Anthos and GKE 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 Front-End-, Anwendungs- und Datenbankebenen. Bei der Migration zu Google Cloud wird der Front-End-Dienst mit einem Load-Balancer 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 Front-End-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 for Anthos and GKE PersistentVolume- und PersistentVolumeClaim-Definitionen generieren soll, müssen Sie den Migrationsplan 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 for Anthos and GKE 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. Cloud Data Transfer Service oder Data Transfer Appliance

  2. Kopieren von Daten mit gsutil 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

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 for Anthos and GKE-Arbeitslasten erreichen nur Runlevel 3. VMs, die mit Migrate for Anthos and GKE 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 for Anthos and GKE deaktiviert automatisch hardware- oder umgebungsspezifische Dienste sowie eine vordefinierte Gruppe von zusätzlichen Diensten, die auf VMs ausgeführt werden. Diese Dienste sind nach der Migration der Arbeitslasten in Container nicht mehr erforderlich.

Beispielsweise deaktivieren Migrate for Anthos and GKE automatisch iptables, ip6tables und Firewalld. Für eine vollständige Liste der von Migrate for Anthos and GKE deaktivierten Dienste laden Sie die Datei blocklist.yaml herunter.

Deaktivierte Dienste anpassen

Standardmäßig deaktiviert Migrate for Anthos and GKE 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 for Anthos aktualisieren.

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