Migrationsplan für Linux-VMs anpassen

Bevor Sie einen Migrationsplan ausführen, sollten Sie ihn prüfen und optional anpassen. Die Details dieses Migrationsplans werden verwendet, um die Artefakte des Arbeitslastcontainers aus der Quell-VM zu extrahieren und um Kubernetes-Deployment-Dateien zu erstellen, mit denen Sie das Container-Image in anderen Clustern, z. B. in einem Produktionscluster, bereitstellen können.

In diesem Seite werden der Inhalt des Migrationsplans und die verschiedenen Arten von Anpassungen dargestellt, die Sie vor dem Ausführen der Migration und vor dem Erstellen von Deployment-Artefakten prüfen sollten.

Hinweise

In diesem Thema wird davon ausgegangen, dass Sie bereits eine Migration erstellt haben und die entsprechende Migrationsplandatei vorhanden ist.

Migrationsplan bearbeiten

Nachdem Sie das Dateisystem kopiert und analysiert haben, finden Sie den Migrationsplan im neuen Verzeichnis, das im angegebenen Ausgabepfad erstellt wird: ANALYSIS_OUTPUT_PATH/config.yaml.

Bearbeiten Sie den Migrationsplan nach Bedarf und speichern Sie die Änderungen.

Prüfen Sie die Details des Migrationsplans und die Leitbemerkungen, um nach Bedarf Informationen hinzuzufügen. Berücksichtigen Sie insbesondere Änderungen in folgenden Abschnitten.

Inhalte von der Migration ausschließen

Standardmäßig werden durch Migrate to Containers typische VM-Inhalte ausgeschlossen, die im Kontext von GKE keine Bedeutung haben. Sie können diesen Filter anpassen.

Im Feldwert filters sind Pfade aufgeführt, die von der Migration ausgeschlossen werden sollen und nicht Teil des Container-Images sind. Der Wert des Felds enthält rsync-Filterregeln, die festlegen, welche Dateien übertragen und welche übersprungen werden sollen. Wenn Sie vor einem Pfad und einer Datei ein Minuszeichen eingeben, wird das Element in der Liste von der Migration ausgeschlossen. Diese Liste wird gemäß der Zeilenreihenfolge in der YAML-Datei verarbeitet. Ausschlüsse/Einschlüsse werden entsprechend angewendet.

Weitere Informationen zu rsync-Filterregeln.

Dateien, die zu groß für das Docker-Image sind, werden in der YAML-Datei aufgelistet. Dadurch werden Dateien gekennzeichnet, die größer als 1 GB sind. Docker-Images, die zu groß sind oder größer als 15 GB sind, können während der Migration ausfallen.

Sie können die YAML-Liste bearbeiten, um Pfade hinzuzufügen oder zu entfernen. Im Folgenden finden Sie ein YAML-Beispiel mit Beispielausschlüssen sowie Benachrichtigungen für große und dünnbesetzte Dateien. Folgen Sie der Inline-Anleitung, um eine der folgenden Aktionen auszuführen:

Schließen Sie die erkannten Ordner aus, indem Sie ihre Kommentarzeichen entfernen und sie unter „Globale Filter“ platzieren.
Verschieben Sie die erkannten Ordner in ein nichtflüchtiges Volume, indem Sie ihre Kommentarzeichen entfernen und sie unter „Datenordner“ platzieren.

Sie können die erkannten dünnbesetzten Dateien auf dieselbe Weise ausschließen oder verschieben.

  global:
    # Files and directories to exclude from the migration, in rsync format.
    filters:
      - "- *.swp"
      - "- /etc/fstab"
      - "- /boot/"
      - "- /tmp/*"
      - "- /var/log/*.log*"
      - "- /var/log/*/*.log*"
      - "- /var/cache/*"

    ## The data folders below are too large to be included in the docker image.
    ## Consider uncommenting and placing them under either the global filters
    ## or the data folder section.
      # - '- /a' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)
      # - '- /a/c' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)

    ## Sparse files will fail the run of a docker image. Consider excluding the below
    ## detected files and any other sparse files by uncommenting and placing them in
    ## the global filters section, or export them to a persistent volume by specifying
    ## them in the data folder section.
      # - '- /a/b' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)
      # - '- /a/d' # (1.8GB, last access 2022-02-02 10:50:30, last modified 2020-02-02 10:50:30)

Namen des Container-Images festlegen

Der Wert des Feldes name im Abschnitt image definiert den Namen des Images, das von einer migrierten VM erstellt wurde und für den Container verwendet wird. Sie können diesen Wert ändern, wenn Sie einen anderen Namen verwenden möchten.

image:
     # Review and set the name for runnable container image.
     name: linux-system

Liste der Dienste anpassen

Standardmäßig deaktiviert Migrate to Containers nicht benötigte Dienste auf einer VM, wenn Sie sie in einen Container migrieren. Diese Dienste können manchmal Probleme mit dem migrierten Container verursachen oder werden in einem Containerkontext nicht benötigt.

Zusätzlich zu den Diensten, die von Migrate to Containers automatisch deaktiviert wurden, können Sie auch andere Dienste deaktivieren:

Migrate to Containers erkennt automatisch Dienste, die Sie optional deaktivieren können, und listet sie im Migrationsplan auf. Diese Dienste wie ssh oder ein Webserver sind für die migrierte Arbeitslast möglicherweise nicht erforderlich. Die Entscheidung liegt letztlich bei Ihnen. Bearbeiten Sie gegebenenfalls den Migrationsplan, um diese Dienste zu deaktivieren.
Migrate to Containers listet nicht alle Dienste auf, die auf der Quell-VM ausgeführt werden. Beispielsweise sind Dienste mit Bezug zum Betriebssystem nicht aufgeführt. Sie können optional den Migrationsplan bearbeiten und eine eigene Liste von Diensten hinzufügen, die im migrierten Container deaktiviert werden sollen.

Das Feld systemServices gibt die Liste der Dienste an, die von Migrate to Containers erkannt wurden. Beispiel:

    systemServices:
    - enabled: true|false
      name: service-name
      probed: true|false
    - enabled: true|false
      name: service-name
      probed: true|false
      ...

Um einen Dienst zu deaktivieren, legen Sie für enabled den Wert false fest.

Migrate to Containers listet nicht alle Dienste auf, die auf der Quell-VM ausgeführt werden, z. B. Dienste in Verbindung mit dem Betriebssystem. Sie können der Liste auch weitere Dienste hinzufügen. So deaktivieren Sie beispielsweise service2 und den Dienst cron:

    systemServices:
    - enabled: true
      name: service1
      probed: false
    - enabled: false
      name: service2
      probed: false
    - enabled: false
      name: cron
      probed: false

Wenn Sie eine Migration ausführen, um die Migrationsartefakte zu generieren, erstellt Migrate to Containers die Datei blocklist.yaml. In dieser Datei sind die Containerdienste aufgeführt, die anhand Ihrer Einstellungen im Migrationsplan deaktiviert werden sollen. Beispiel:

service_list:
- name: disabled-services
  services:
  # Because you used systemServices above to disabled service2 and cron:
  - service2
  - cron

So ändern Sie die Liste der deaktivierten Dienste später:

Bearbeiten Sie die Liste der Dienste im Migrationsplan.
Führen Sie die Migration aus, um die Migrationsartefakte neu zu generieren, einschließlich eines aktualisierten blocklist.yaml.

Alternativ können Sie nachdem Sie eine Migration ausgeführt haben, um die Migrationsartefakte zu generieren, die Datei blocklist.yaml direkt bearbeiten und dann das Container-Image mit Skaffold erstellen und bereitstellen.

Endpunkte der Dienste anpassen

Der Migrationsplan enthält das Array endpoints, das die Ports und Protokolle definiert, mit denen die von der migrierten Arbeitslast bereitgestellten Kubernetes-Dienste erstellt werden. Sie können Endpunktdefinitionen hinzufügen, bearbeiten oder löschen, um den Migrationsplan anzupassen.

Prüfen Sie die Programme, die Ports überwachen, um die Endpunktports abzurufen:

sudo netstat --programs --listening --tcp --udp [--sctp]

Fügen Sie dem Migrationsplan für jeden Dienstendpunkt die folgende Definition hinzu:

    endpoints:
    - port: PORT_NUMBER
      protocol: PORT_PROTOCOL
      name: PORT_NAME

Wobei:

PORT_NUMBER gibt die Containerportnummer an, an die Anfragen an den Dienst weitergeleitet werden.
PORT_PROTOCOL gibt das Portprotokoll an, z. B. HTTP, HTTPS oder TCP. Eine vollständige Liste der Protokolle finden Sie unter Unterstützte Protokolle.
PORT_NAME gibt den Namen an, mit dem der Dienstendpunkt aufgerufen wird. Migrate to Containers generiert einen eindeutigen PORT_NAME für jede generierte Endpunktdefinition.

Migrate to Containers erkennt beispielsweise die folgenden Endpunkte:

  endpoints:
    - port: 80
      protocol: HTTP
      name: backend-server-nginx
    - port: 6379
      protocol: TCP
      name: backend-server-redis

Um den Wert des Attributs name festzulegen, kombiniert Migrate to Containers den Quell-VM-Namen, in diesem Beispiel backend-server, mit dem Programmnamen des Dienstes. Die generierten Namen sind mit den Kubernetes-Namenskonventionen kompatibel und im Migrationsplan eindeutig. Der obige Migrationsplan erstellt beispielsweise einen Dienst, der für Nginx auf Port 80 über HTTP angewendet wird.

Bei allen Duplikaten hängt Migrate to Containers ein Zählersuffix an. Wenn Nginx beispielsweise mit zwei Ports verknüpft ist, wird in der zweiten Definition das Suffix -2 zu name hinzugefügt:

  endpoints:
    - port: 80
      protocol: HTTP
      name: backend-server-nginx
    - port: 8080
      protocol: HTTPS
      name: backend-server-nginx-2
    - port: 6379
      protocol: TCP
      name: backend-server-redis

Wenn Sie eine Migration zum Generieren der Migrationsartefakte ausführen, erstellt Migrate to Containers für jeden Endpunkt eine Dienstdefinition in der Datei deployment_spec.yaml.

Im Folgenden ist beispielsweise eine Service-Definition in der Datei deployment_spec.yaml dargestellt:

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  name: backend-server-nginx
spec:
  ports:
  - port: 80
    protocol: HTTP
    targetPort: 80
  selector:
    app: backend-server
status:
  loadBalancer: {}

NFS-Bereitstellungen anpassen

Migrate to Containers enthält NFS-Bereitstellungen im generierten Migrationsplan. Diese Informationen werden aus der Datei fstab erfasst und in das Array nfsMounts im Migrationsplan geschrieben. Sie können Definitionen für NFS-Bereitstellungspunkte hinzufügen oder bearbeiten, um den Migrationsplan anzupassen.

Beim Generieren des Migrationsplans tut Migrate to Containers Folgendes:

NFS-Bereitstellungen für /sys und /dev werden ignoriert.
NFS-Bereitstellungen mit einem anderen Typ als nfs oder nfs4 werden ignoriert.

Jede NFS-Bereitstellung im Migrationsplan enthält die IP-Adresse des Servers sowie den lokalen Bereitstellungspfad im folgenden Format:

    nfsMounts:
    - mountPoint: MOUNT_POINT
      exportedDirectory: DIR_NAME
      nfsServer: IP
      mountOptions:
         - OPTION_1
         - OPTION_2
      enabled: false|true

Dabei gilt:

MOUNT_POINT gibt den von fstab abgerufenen Bereitstellungspunkt an.
DIR_NAME gibt den Namen des freigegebenen Verzeichnisses an.
IP gibt die IP-Adresse des Servers an, der den Bereitstellungspunkt hostet.
OPTION_N gibt alle Optionen an, die für den Bereitstellungspunkt aus fstab extrahiert wurden.

Beispielsweise für den folgenden Eintrag in fstab:

<file system>       <mount point>   <type>  <options>   <dump>  <pass>
10.49.232.26:/vol1  /mnt/test       nfs     rw,hard     0       0

Migrate to Containers generiert den folgenden Eintrag im Migrationsplan:

    nfsMounts:
    - mountPoint: /mnt/test
      exportedDirectory: /vol1
      nfsServer: 10.49.232.26
      mountOptions:
         - rw
         - hard
      enabled: false

Wenn Sie Migrate to Containers für die Verarbeitung von Einträgen im Array nfsMounts konfigurieren möchten, legen Sie für den Eintrag mountPoint den Wert enabled auf true fest. Sie können einen, einige oder alle mountPoints-Einträge aktivieren, die Einträge bearbeiten oder eigene Einträge hinzufügen.

Wenn Sie eine Migration ausführen, um die Migrationsartefakte zu generieren, erstellt Migrate to Containers für jede aktivierte NFS-Bereitstellung eine Volumes- und VolumeMounts-Definition sowie eine PersistentVolume- und PersistentVolumeClaim-Definition in die Datei deployment_spec.yaml.

Im Folgenden ist beispielsweise eine volumeMounts-Definition in der Datei deployment_spec.yaml dargestellt:

    spec:
      containers:
          - image: gcr.io/myimage-1/image-name
            name: some-app
            volumeMounts:
                   - mountPath: /sys/fs/cgroup
                     name: cgroups
                   - mountPath: /mnt/test
                     name: nfs-pv

Der Wert von name ist dabei eine eindeutige Kennung, die von Migrate to Containers generiert wurde.

Im Folgenden wird ein Beispiel für PersistentVolumeClaim- und PersistentVolume-Definitionen in der Datei deployment_spec.yaml dargestellt:

apiVersion: v1
kind: PersistentVolumeClaim
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Mi
  storageClassName: ""
  volumeName: nfs-pv

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  mountOptions:
    - rw
    - hard
  nfs:
    path: /vol1
    server: 10.49.232.26

In Cloud Logging geschriebene Logdaten anpassen

In der Regel schreibt eine Quell-VM Informationen in eine oder mehrere Logdateien. Sie haben die Möglichkeit, die migrierte Arbeitslast im Rahmen der Migration der VM so zu konfigurieren, dass diese Loginformationen in Cloud Logging geschrieben werden.

Wenn Sie den Migrationsplan generieren, sucht Migrate to Containers automatisch nach Logzieldateien auf der Quell-VM. Migrate to Containers schreibt dann Informationen zu diesen erkannten Dateien in den Bereich logPaths des Migrationsplans:

deployment:
    ...
    logPaths:
    - appName: APP_NAME
      globs:
      - LOG_PATH

Beispiel:

deployment:
    ...
    logPaths:
    - appName: tomcat
      globs:
      - /var/log/tomcat*/catalina.out

Wenn Sie die Migrationsartefakte generieren, generiert Migrate to Containers die Datei logs.yaml aus dem Migrationsplan. Diese Datei enthält die Liste der Logdateien, die auf der Quell-VM erkannt wurden. Zum Beispiel enthält logs.yaml aus der obigen logsPath-Definition:

logs:
  tomcat:
  - /var/log/tomcat*/catalina.out

In diesem Beispiel werden beim Bereitstellen der migrierten Arbeitslast Loginformationen, die in catalina.out geschrieben wurden, automatisch in Cloud Logging geschrieben.

Die Einträge werden jeweils in einer Zeile des Logs im folgenden Format angezeigt:

DATE TIME APP_NAME LOG_OUTPUT

Das folgende Beispiel zeigt das Formular mit einem Eintrag aus Tomcat:

2019-09-22 12:43:08.681193976 +0000 UTC tomcat log-output

Sie haben zwei Möglichkeiten, das Logging zu konfigurieren:

Bearbeiten Sie den Migrationsplan, bevor Sie die Migrationsartefakte zum Hinzufügen, Entfernen oder Bearbeiten von logPaths-Einträgen generieren. Wenn Sie die Migrationsartefakte generieren, werden diese Änderungen in der Datei logs.yaml widergespiegelt.
Bearbeiten Sie logs.yaml, nachdem die Migrationsartefakte generiert wurden, um logs-Einträge hinzuzufügen, zu entfernen oder zu bearbeiten.

Der Vorteil des Bearbeitens des Migrationsplans besteht darin, dass Ihre Änderungen bei jedem Generieren der Artefakte in logs.yaml widergespiegelt werden. Wenn Sie logs.yaml direkt bearbeiten und die Artefakte dann aus irgendeinem Grund neu generieren, müssen Sie Ihre Änderungen noch einmal auf logs.yaml anwenden.

Linux v2kServiceManager-Systemdiagnosen festlegen

Sie können die Ausfallzeit und den Bereitschaftsstatus Ihrer verwalteten Container überwachen. Geben Sie dazu Tests im Migrationsplan Ihres Tomcat-Webservers an. Mit einem Monitoring der Systemdiagnose können Sie die Ausfallzeiten migrierter Container reduzieren und ein besseres Monitoring bereitstellen.

Unbekannte Systemstatus können zu einer Beeinträchtigung der Verfügbarkeit, zu falsch-positivem Verfügbarkeits-Monitoring und zu einem möglichen Datenverlust führen. Ohne eine Systemdiagnose kann kubelet den Zustand eines Containers nur „vermuten“ und sendet Traffic eventuell an eine nicht bereite Containerinstanz. Dies kann zu Trafficverlusten führen. Außerdem kann Kubelet keine Container erkennen, die sich in einem fixierten Zustand befinden, d. h. es kann diese nicht neu starten.

Eine Systemdiagnose funktioniert durch Ausführen einer kleinen skriptbasierten Anweisung beim Starten des Containers. Das Script prüft jeden Zeitraum auf erfolgreiche Bedingungen, die durch die Art der verwendeten Diagnose definiert sind. Der Zeitraum wird im Migrationsplan durch ein periodSeconds-Feld definiert. Sie können diese Skripts manuell ausführen oder definieren.

Weitere Informationen zu kubelet-Diagnosen finden Sie in der Kubernetes-Dokumentation unter Aktivitäts-, Bereitschafts- und Startprüfungen konfigurieren.

Es gibt zwei Arten von Prüfungen, die konfiguriert werden können. Beide Prüfungen werden in der probe-v1-core-Referenz definiert und haben dieselbe Funktion wie die entsprechenden Felder von container-v1-core

Aktivitätsprüfung: Aktivitätsprüfungen werden verwendet, um festzustellen, wann ein Container neu gestartet werden muss.

Hinweis: Wenn ein Prozess in Ihrem Container selbst abstürzen kann, wenn ein Problem auftritt, oder er fehlerhaft wird, benötigen Sie nicht unbedingt eine Aktivitätsprüfung. Kubelet führt automatisch die richtige Aktion gemäß dem restartPolicy des Pods aus.

Bereitschaftsprüfung: Bereitschaftsprüfungen werden verwendet, um festzustellen, wann ein Container bereit ist, Traffic anzunehmen. Wenn Sie nur dann Traffic an einen Pod senden möchten, wenn eine Prüfung erfolgreich ist, geben Sie eine Bereitschaftsprüfung an. Eine Bereitschaftsprüfung kann ähnlich funktionieren wie eine Aktivitätsprüfung. Eine Bereitschaftsprüfung in den Spezifikationen gibt jedoch an, dass ein Pod ohne Trafficempfang gestartet wird, und Traffic nur nach erfolgreicher Prüfung empfängt.

Nach der Erkennung wird die Diagnosekonfiguration dem Migrationsplan hinzugefügt. Die Prüfungen können wie unten gezeigt in der Standardkonfiguration verwendet werden. Entfernen Sie den Abschnitt probes aus der YAML-Datei, um Prüfungen zu deaktivieren.

deployment:
  probes:
    livenessProbe:
      exec:
        command:
        - /ko-app/service-manager-runtime
        - /probe

    readinessProbe:
      exec:
        command:
        - gamma
        - /probe
      initialDelaySeconds: 60
      periodSeconds: 5

image:
  # Disable system services that do not need to be executed at the migrated workload containers.
  # Enable the 'probed' property to include system services in the container health checks.
  systemServices:
  - enabled: true
    name: apache2
    probed: true
  - enabled: true
    name: atd
    probed: false

Standardmäßig sind alle Dienstprüfungen deaktiviert. Sie müssen bestimmen, welche Teilmenge der Dienste überwacht werden soll.

Es gibt vier vordefinierte Möglichkeiten, einen Container mithilfe einer Diagnose zu prüfen. Bei jeder Diagnose muss genau einer dieser vier Mechanismen definiert werden:

exec: Führt einen angegebenen Befehl im Container aus. Die Ausführung wird als erfolgreich bewertet, wenn der Statuscode für den Exit 0 ist.
grpc: Führt einen Remote-Prozeduraufruf mit gRPC aus. gRPC-Prüfungen sind eine Alphafunktion.
httpGet: Führt eine HTTP-GET-Anfrage an die IP-Adresse des Pods an einem angegebenen Port und Pfad aus. Die Anfrage wird als erfolgreich bewertet, wenn der Statuscode größer oder gleich 200 und kleiner als 400 ist.
tcpSocket: Führt eine TCP-Prüfung der IP-Adresse des Pods an einem angegebenen Port durch. Die Diagnose gilt als erfolgreich, wenn der Port geöffnet ist.

Standardmäßig aktiviert ein Migrationsplan die Prüfmethode exec. Verwenden Sie die manuelle Konfiguration für Ihren Migrationsplan, um eine andere Methode zu aktivieren.

Definieren Sie eine ausführbare Bereitschaftsprüfung und ein Script, um die Logik zu implementieren und um externe Abhängigkeiten für die Bereitschaftsprüfung hinzuzufügen.

Nächste Schritte

Migration ausführen