Fehlerbehebung

Informieren Sie sich über die Schritte zur Fehlerbehebung. Diese können hilfreich sein, wenn mit Migrate for Anthos 1.7.5 Probleme auftreten.

Shell-Befehle für den Container ausführen

Sie können über eine bash-Shell oder über PowerShell mit dem Befehl kubectl exec auf einen Container zugreifen.

Hinweis: Für die folgenden Beispiele ersetzen Sie für PowerShell je nach Version /bin/bash durch cmd.exe, powershell.exe oder pwsh.exe.

Verwenden Sie kubectl describe pods, um den Namen des Pods in Ihrem Cluster zu finden, mit dem Sie eine Verbindung herstellen möchten.
Im folgenden Beispiel listet der Befehl den Pod suitecrm-0 auf.
```
kubectl describe pods | grep Name

Name:               suitecrm-0
```
Führen Sie Shell-Befehle mit einer der folgenden Methoden aus:
- Öffnen Sie mit kubectl exec eine Bash-Befehls-Shell, in der Sie Befehle ausführen können.
```
kubectl exec -it pod-name -- /bin/bash
```
  Im folgenden Beispiel wird eine Shell für den Pod suitecrm-0 abgerufen:
```
kubectl exec -it suitecrm-0 -- /bin/bash
```
- Verwenden Sie kubectl exec, um Befehle direkt auszuführen.
```
kubectl exec -it pod-name -- /bin/bash -c "command(s)"
```
  Im folgenden Beispiel wird das Stammverzeichnis des Pods suitecrm-0 aufgeführt:
```
kubectl exec -it suitecrm-0 -- /bin/bash -c "ls /"
```

Weitere Informationen finden Sie in der Kubernetes-Dokumentation.

Kubernetes-Ressourcen debuggen

Weitere Hilfe erhalten Sie auf den folgenden Seiten:

Wenn Sie ein Problem mit Google Kubernetes Engine haben, lesen Sie die Seite Fehlerbehebung für GKE.
Wenn bei Ihrem Cluster ein Problem auftritt, lesen Sie den Abschnitt Fehlerbehebung bei Clustern in der Kubernetes-Dokumentation.
Falls bei Ihrer Anwendung, den zugehörigen Pods oder dem Controllerobjekt ein Problem auftritt, lesen Sie Fehlerbehebung für Anwendungen.

Der Fehler RESOURCE_OPERATION_RATE_EXCEEDED wird im Migrationsstatus oder in den Logs angezeigt

Der Fehler RESOURCE_OPERATION_RATE_EXCEEDED tritt auf, wenn die Quellplattform einer Migration Compute Engine ist und Sie das Limit für Laufwerk-Snapshots bei der Migration einer Compute Engine-VM überschreiten.

Im Rahmen der Migration erstellt Migrate for Anthos einen Snapshot der Laufwerk-Images von einer VM, die auf der Quellplattform ausgeführt wird. Für eine Compute Engine-VM können sie einen Laufwerk-Snapshot höchstens alle 10 Minuten oder sechsmal pro Stunde erstellen. Mit dieser Fehlermeldung wird darauf hingewiesen, dass Sie das Limit überschritten haben.

Damit diese Häufigkeit nicht überschritten wird, empfiehlt es sich, den Cluster in derselben Zone wie die Compute Engine-VM zu erstellen. Befindet sich der Cluster in derselben Zone wie die VM, kann Migrate for Anthos das Laufwerk klonen, anstatt einen Snapshot zu erstellen. Dieser Prozess ist effizienter und umgeht das Snapshot-Limit.

Weitere Informationen:

Unter Verarbeitungscluster in Google Cloud für Windows-Arbeitslasten konfigurieren erfahren Sie mehr über das Erstellen eines Clusters.
Weitere Informationen zum Limit finden Sie unter Häufige Snapshots effizient erstellen.

Ein unter /etc/fstab aufgelistetes Gerät kann nicht bereitgestellt werden

Standardmäßig parst das System /etc/fstab und stellt alle aufgelisteten Geräte an den erforderlichen Bereitstellungspunkten bereit. Wenn ein Gerät nicht erkannt oder nicht bereitgestellt wird, erhält der Arbeitslast-Pod nicht den Status „Bereit“.

Betrachten Sie beispielsweise eine Linux-Quell-VM in Amazon EC2, die ein sitzungsspezifisches Laufwerk hat. Hier ist Persistenz nicht gewährleistet. Diese Laufwerke werden nicht an das Ziel gestreamt, sodass der Container sie nicht bereitstellen kann.

In diesem Fall erhalten Sie unter Umständen Nachrichten wie diese:

Unable to locate resolve [X] fstab entries: …
Error: Failed mount -o defaults /dev/mapper/mpathe-part /rootfs/mnt/ephemeral

So können Sie dieses Problem umgehen:

Entfernen Sie unter /etc/fstab auf der Linux-VM den Befehl zur Gerätebereitstellung.
Legen Sie die Umgebungsvariable HC_INIT_SKIP_MOUNT_FAILURES fest, um das System so zu konfigurieren, dass es Bereitstellungsfehler überspringt und den Vorgang fortsetzt.

So legen Sie die Umgebungsvariable HC_INIT_SKIP_MOUNT_FAILURES fest:

Erstellen Sie im Migrations-Namespace v2k-system im Migrationsverarbeitungscluster eine ConfigMap. Definieren Sie beispielsweise die ConfigMap in einer Datei mit dem Namen jobs-config.yaml:
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: jobs-config
  namespace: v2k-system
data:
  environment: |
    HC_INIT_SKIP_MOUNT_FAILURES = true
```
Wenden Sie die ConfigMap auf den Cluster an:
```
kubectl apply -f jobs-config.yaml
```
Rufen Sie mit dem folgenden Befehl die ConfigMap auf:
```
kubectl describe configmaps -n v2k-system
```
Fügen Sie die ConfigMap dem Migrationsplan hinzu. Der Migrationsplan ist die YAML-Datei, die Sie beim Erstellen der Migration generiert haben. Weitere Informationen zum Bearbeiten des Migrationsplans finden Sie unter Migrationsplan anpassen.

Bearbeiten Sie im Migrationsplan den Abschnitt configs, um die ConfigMap hinzuzufügen:
```
configs:
  jobsConfig:
    name: jobs-config
```
Speichern Sie die Änderungen und führen Sie die Migration wie unter Migration ausführen beschrieben aus.

Fehler bei den Funktionen eines bereitgestellten Containers aufgrund von AppArmor

AppArmor ermöglicht einem Systemadministrator, die Berechtigungen eines bereitgestellten Containers mithilfe benutzerdefinierter Profile einzuschränken. In manchen Fällen müssen Sie ein Profil auf Ihren bereitgestellten Container anwenden, um dessen Funktionen anzupassen.

So passen Sie das AppArmor-Profil an:

Erstellen Sie das Profil im Cluster, in dem Sie den migrierten Container bereitstellen. Weitere Informationen finden Sie in der Dokumentation zu AppArmor.

Bearbeiten Sie die Datei deployment_spec.yaml, um die Umgebungsvariable HC_APPARMOR_PROFILE mit dem Namen des AppArmor-Profils hinzuzufügen:

spec:
  containers:
  - image: gcr.io/my-project/my-container:v1.0.0
    name: my-container
    env:
    - name: HC_APPARMOR_PROFILE
      value: "apparmor-profile-name"
    securityContext:
      privileged: true
...

Weitere Informationen zum Bearbeiten von deployment_spec.yaml finden Sie unter Generierte Bereitstellungsdateien prüfen.

FailedAttachVolume-Fehler wird im Migrationsstatus oder in den Protokollen angezeigt (Vorschau)

Wenn Sie mit Anthos-Clustern auf AWS eine Migration ausführen, erscheint möglicherweise der Fehler FailedAttachVolume im Migrationsstatus oder in den Logs mit der Meldung:

"The encrypted volume was unable to access the KMS master key"

Dieser Fehler bedeutet, dass Ihre AWS-VM ein verschlüsseltes Laufwerk verwendet und Sie den Zugriff nicht richtig konfiguriert haben. Weitere Informationen finden Sie unter Voraussetzungen für die Migration von Linux-VMs mit AWS-Verarbeitungsclustern.

ProvisioningFailed-Fehler wird im Migrationsstatus oder in den Logs angezeigt (Vorschau)

Wenn Sie mit Anthos-Clustern auf AWS eine Migration ausführen, erscheint möglicherweise der Fehler ProvisioningFailed im Migrationsstatus oder in den Logs mit der Meldung:

"ProvisioningFailed - "Could not create volume V_ID"

Dieser Fehler kann auftreten, wenn Sie versuchen, Daten in ein neues verschlüsseltes Volume zu exportieren, der Cluster aber keinen Zugriff auf den Verschlüsselungsschlüssel hat und deshalb das EBS-Laufwerk nicht erstellen kann. Weitere Informationen finden Sie unter Voraussetzungen für die Migration von Linux-VMs mit AWS-Verarbeitungsclustern.

Ich möchte personalisierten Support

Kunden, die mit Migrate for Anthos migrieren, steht kostenpflichtiger Support zur Verfügung. Setzen Sie sich mit uns in Verbindung, damit wir Ihnen helfen können .

Informationen für den Google Cloud-Support bereitstellen

Der Systemreport bietet Support für Migrate for Anthos mit Informationen zur Clusterkonfiguration, um Probleme schneller zu beheben.

Sie können über Cloud Shell auf das Skript zugreifen.

Zu Cloud Shell

Führen Sie als Nächstes das Skript collect_sysreport.sh aus.

/google/migrate/anthos/collect_sysreport.sh [-n NAMESPACE] [-o OUTPUT_DIRECTORY] [-m MIGRATION]

Wobei:

[NAMESPACE]: (Optional) Der Namespace, in dem Migrate for Anthos bereitgestellt wurde (Standard ist v2k-system).
[OUTPUT_DIRECTORY]: (Optional) Pfad zu dem Verzeichnis, in dem der Systemreport gespeichert wird (Standard ist $HOME).
[MIGRATION]: (Optional) Zusätzliche Informationen, die für eine Migration erfasst werden.

Das Skript erstellt anthos-migrate-logs.TIMESTAMP.tar.xz. Dieses Element stellen Sie dem Google Cloud-Support zur Verfügung.

Das Skript erfasst standardmäßig Folgendes:

Logs vom Migrate for Anthos CSI-Controller und von CSI-Knoten.
Syslog von den CSI-Knotenhosts von Migrate for Anthos.
Logs vom Migrate for Anthos-Controller.
Alle Migrate for Anthos-Entitäten aus dem Cluster.
Wenn Sie eine Migration angeben und bei der Migration das standardmäßige Artefakt-Repository verwendet wird, erfassen Sie die Migrationsartefakte aus Cloud Storage oder dem S3-Bucket.
Die Ausgabe von:
- kubectl cluster-info
- kubectl get nodes; kubectl describe node
- kubectl version
- kubectl top node
Die Logs der Arbeitslast.
Die Ausgabe von:
- ps aux
- netstat -tlnp
- iptables -t nat -L
- fstab
- kubectl get pod
- kubectl describe pod
- kubectl top pod --all-namespaces --containers
- kubectl cluster-info dump
- kubectl api-resources -o wide
- kubectl top pod --all-namespaces --containers
- kubectl api-resources -o wide
- kubectl get componentstatuses --all-namespaces
- kubectl get endpoints --all-namespaces
- kubectl get events --all-namespaces
- kubectl describe limits --all-namespaces
- kubectl get namespaces
- kubectl describe pvc --all-namespaces
- kubectl describe pv --all-namespaces
- kubectl describe quota --all-namespaces
- kubectl describe sa --all-namespaces
- kubectl describe services --all-namespaces
- kubectl describe services --all-namespaces
- kubectl get ingresses --all-namespaces
- kubectl describe networkpolicies --all-namespaces
- kubectl get podsecuritypolicies --all-namespaces
- kubectl get clusterrolebindings --all-namespaces
- kubectl describe storageclasses --all-namespaces
- kubectl describe volumeattachments --all-namespaces