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 Abschnitt 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.

Hinweis

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

Migrationsplan bearbeiten

Sie können den Migrationsplan mit dem migctl-Tool oder der Google Cloud Console bearbeiten.

migctl

Sie müssen den Migrationsplan herunterladen, bevor Sie ihn bearbeiten können:

  1. Laden Sie den Migrationsplan herunter. Der Migrationsplan von Linux-Arbeitslasten wird durch LinuxMigrationCommonSpec dargestellt:

    migctl migration get my-migration
    
  2. Bearbeiten Sie den heruntergeladenen Migrationsplan my-migration.yaml in einem Texteditor.

  3. Wenn die Änderungen abgeschlossen sind, speichern und laden Sie den überarbeiteten Migrationsplan hoch:

    migctl migration update my-migration --main-config my-migration.yaml
    
  4. Falls weitere Änderungen erforderlich sind, wiederholen Sie diese Schritte.

Console

Bearbeiten Sie den Migrationsplan in der Google Cloud Console mithilfe des YAML-Editors. Der Migrationsplan von Linux-Arbeitslasten wird durch die LinuxMigrationCommonSpec-CRD dargestellt:

  1. Rufen Sie in der Google Cloud Console die Seite Migrate to Containers auf.

    Zur Seite "Zu Containern migrieren"

  2. Klicken Sie auf den Tab Migrationen, um eine Tabelle mit den verfügbaren Migrationen aufzurufen.

  3. Wählen Sie in der Zeile für die gewünschte Migration den Namen der Migration aus, um den Tab Details zu öffnen.

  4. Wählen Sie den Tab YAML aus.

  5. Bearbeiten Sie den Migrationsplan nach Bedarf.

  6. Wenn Sie mit der Bearbeitung fertig sind, haben Sie folgende Möglichkeiten:

    1. Speichern Sie den Migrationsplan. Sie müssen dann die Migration manuell ausführen, um die Migrationsartefakte zu generieren. Folgen Sie der Anleitung unter Migration ausführen.

    2. Speichern und generieren Sie die Artefakte. Führen Sie die Migration durch. Dazu verwenden Sie Ihre Änderungen, um die Migrationsartefakte zu generieren. Der Vorgang entspricht dem unter Migration ausführen beschriebenen. Sie können die Migration anschließend wie im Abschnitt Migration überwachen beschrieben überwachen.

CRD

Sie müssen den Migrationsplan herunterladen, bearbeiten und anwenden. Der Migrationsplan von Linux-Arbeitslasten wird durch die LinuxMigrationCommonSpec-CRD dargestellt:

  1. Rufen Sie den Namen von AppXGenerateArtifactsFlow ab:

    kubectl get migrations.anthos-migrate.cloud.google.com -n v2k-system -o jsonpath={.status.migrationPlanRef.name} my-migration

    Das Benennungsmuster wird in Form von appx-generateartifactsflow-id zurückgegeben.

  2. Rufen Sie den Migrationsplan anhand des Namens ab und schreiben Sie ihn in eine Datei mit dem Namen my-plan.yaml:

    kubectl -n v2k-system get appxgenerateartifactsflows.anthos-migrate.cloud.google.com -o jsonpath={.spec.appXGenerateArtifactsConfig} appx-generateartifactsflow-id > my-plan.yaml
  3. Bearbeiten Sie den Migrationsplan nach Bedarf.

  4. Wenden Sie die Datei an:

    kubectl patch appxgenerateartifactsflows.anthos-migrate.cloud.google.com --type merge -n v2k-system --patch '{"spec": {"appXGenerateArtifactsConfig": '"$(jq -n --rawfile plan my-plan.yaml '$plan')"'}}' appx-generateartifactsflow-id

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 finden Sie auf der Seite „rsync“ im Abschnitt „INCLUDE/EXCLUDE PATTERN RULES“.

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 für eine der folgenden Optionen:

  • 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 auch 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 Feldwert image definiert die Namen und Positionen von zwei Images, die von einer migrierten VM erstellt wurden. Sie können diese Werte ändern, wenn Sie andere Namen verwenden möchten.

Während der Migration kopiert Migrate to Containers Dateien und Verzeichnisse, die Ihre migrierende Arbeitslast darstellen, standardmäßig in die Container Registry für eine Verwendung bei der Migration. Durch den Migrationsprozess wird die extrahierte Arbeitslast in ein Image umgewandelt, das in GKE ausgeführt werden kann.

Bei Migrate to Containers werden Dateien und Verzeichnisse der ursprünglichen VM in der Registry beibehalten. Dies erfolgt über den Pfad base. Dieses Image dient als nicht ausführbare Basisebene, die die extrahierten Arbeitslastdateien enthält, die dann mit der Laufzeitsoftwareebene von Migrate to Containers kombiniert werden, um ein ausführbares Container-Image zu erstellen.

Separate Ebenen vereinfachen das spätere Aktualisieren des Container-Images. Dadurch sind gesonderte Aktualisierungen der Basisebene oder der Softwareebene von Migrate to Containers nach Bedarf möglich.

Dieses Image kann nicht ausgeführt werden, bietet jedoch für Migrate to Containers die Möglichkeit, den Container von diesem Original zu aktualisieren, wenn Sie ein Upgrade von Migrate for Anthos ausführen.

Die Feldwerte base und name geben Images an, die in der Registry erstellt werden.

  • base: Name des Images, das aus den VM-Dateien und -Verzeichnissen erstellt wird, die von der Quellplattform kopiert werden. Dieses Image kann nicht in GKE ausgeführt werden, da es nicht für das dortige Deployment angepasst ist.
  • name: Name des ausführbaren Images, das für den Container verwendet wird. Dieses Image enthält sowohl den Inhalt der Quell-VM als auch die Laufzeit von Migrate to Containers, sodass es ausgeführt werden kann.
        image:
          # Review and set the name for extracted non-runnable base image,
          # if an image tag is not specified, a random tag is auto-generated when the image is built.
          base: "centos-mini-non-runnable-base"

          # Review and set the name for runnable container image,
          # if an image tag is not specified, a random tag is auto-generated when the image is built.
          name: "centos-mini"

Standardmäßig wird ein Tag, das dem Zeitstempel der Migration entspricht, automatisch auf diese Werte angewendet. Dieses Tag hat das folgende Format:

MM-DD-YYYY--hh:mm:ss

Wenn Sie ein eigenes Tag anwenden möchten, überschreiben Sie das Standard-Tag, bearbeiten Sie die CRD und fügen Sie es hinzu, wie unten gezeigt:

        image:
          # Review and set the name for extracted non-runnable base image,
          # if an image tag is not specified, a random tag is auto-generated when the image is built.
          base: "centos-mini-non-runnable-base:tag"

          # Review and set the name for runnable container image,
          # if an image tag is not specified, a random tag is auto-generated when the image is built.
          name: "centos-mini:tag"

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 einer aktualisierten blocklist.yaml-Datei, einer deployment_spec.yaml-Datei und einer Dockerfile.

Nachdem Sie eine Migration ausgeführt haben, um die Migrationsartefakte zu generieren, können Sie die Datei blocklist.yaml direkt bearbeiten und dann das Container-Image neu erstellen und übertragen. Beispiel:

  1. Aktualisieren Sie die Datei blocklist.yaml.

  2. Erstellen Sie das Container-Image neu und übertragen Sie es per Push.

    Die Methode zum erneuten Erstellen und Übertragen des Container-Images hängt von Ihrer Build-Umgebung ab. Sie können Folgendes angeben:

    1. gcloud, um das Image neu zu erstellen und nach Container Registry per Push zu übertragen, wie unter Kurzanleitung: Erstellen erläutert.
    2. docker build, wie unter Image erstellen und ausführen beschrieben.
  3. Nachdem Sie das neue Image neu erstellt und per Push übertragen haben, öffnen Sie die Datei deployment_spec.yaml in einem Editor, um den Image-Speicherort zu ändern:

    spec:
     containers:
       - image: new-image-location
    

    Beispiel: new-image-location kann my-new-image:v1.0 sein, wenn Sie das Image mit gcloud neu erstellt und nach Container Registry per Push übertragen haben.

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.

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.

  • 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.

v2kServiceManager: true
deployment:
  probes:
    livenessProbe:
      exec:
        command:
        - gamma
        - /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