Unterstützung für die Verbesserung dieser Seite beitragen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link Diese Seite bearbeiten auf, der sich im rechten Bereich jeder Seite befindet.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Probleme mit den Funktionen von Argo CD beheben

Die Funktion ist AKTIV, aber die Anwendungen werden nicht synchronisiert

Wenn Ihre Argo-CD-Funktion ACTIVE den Status anzeigt, Anwendungen aber nicht synchronisiert werden, überprüfen Sie den Funktionsstatus und den Anwendungsstatus.

Überprüfen Sie den Zustand der Funktionen:

Sie können Funktionszustands- und Statusprobleme in der EKS-Konsole oder über die AWS CLI anzeigen.

Konsole:

AWS CLI:

# View capability status and health
aws eks describe-capability \
  --region region-code \
  --cluster-name my-cluster \
  --capability-name my-argocd

# Look for issues in the health section

Häufige Ursachen:

Überprüfen Sie den Status der Bewerbung:

# List applications
kubectl get application -n argocd

# View sync status
kubectl get application my-app -n argocd -o jsonpath='{.status.sync.status}'

# View application health
kubectl get application my-app -n argocd -o jsonpath='{.status.health}'

Überprüfen Sie die Bewerbungsbedingungen:

# Describe application to see detailed status
kubectl describe application my-app -n argocd

# View application health
kubectl get application my-app -n argocd -o jsonpath='{.status.health}'

Anwendungen bleiben im Status „In Bearbeitung“ hängen

Wenn eine Anwendung angezeigt wird, Progressing aber nie erreicht wirdHealthy, überprüfen Sie den Ressourcenstatus und die Ereignisse der Anwendung.

Überprüfen Sie den Zustand der Ressourcen:

# View application resources
kubectl get application my-app -n argocd -o jsonpath='{.status.resources}'

# Check for unhealthy resources
kubectl describe application my-app -n argocd | grep -A 10 "Health Status"

Häufige Ursachen:

Überprüfen Sie die Zielclusterkonfiguration (für Multi-Cluster-Setups):

# List registered clusters
kubectl get secret -n argocd -l argocd.argoproj.io/secret-type=cluster

# View cluster secret details
kubectl get secret cluster-secret-name -n argocd -o yaml

Fehler beim Repository-Authentifizierung

Wenn Argo CD nicht auf Ihre Git-Repositorys zugreifen kann, überprüfen Sie die Authentifizierungskonfiguration.

Für CodeCommit Repositorys:

Stellen Sie sicher, dass die IAM-Capability-Rolle über Berechtigungen verfügt CodeCommit :

# View IAM policies
aws iam list-attached-role-policies --role-name my-argocd-capability-role
aws iam list-role-policies --role-name my-argocd-capability-role

# Get specific policy details
aws iam get-role-policy --role-name my-argocd-capability-role --policy-name policy-name
      

Die Rolle benötigt codecommit:GitPull Berechtigungen für die Repositorys.

Für private Git-Repositorys:

Stellen Sie sicher, dass die Repository-Anmeldeinformationen korrekt konfiguriert sind:

# Check repository secret exists
kubectl get secret -n argocd repo-secret-name -o yaml

Stellen Sie sicher, dass das Geheimnis die richtigen Authentifizierungsdaten (SSH-Schlüssel, Token oder username/password) enthält.

Für Repositorien, die Secrets Manager verwenden:

# Verify IAM Capability Role has Secrets Manager permissions
aws iam list-attached-role-policies --role-name my-argocd-capability-role

# Test secret retrieval
aws secretsmanager get-secret-value --secret-id arn:aws:secretsmanager:region-code:111122223333:secret:my-secret
      

Multi-cluster Probleme bei der Bereitstellung

Wenn Anwendungen nicht auf Remote-Clustern bereitgestellt werden, überprüfen Sie die Clusterregistrierung und die Zugriffskonfiguration.

Überprüfen Sie die Clusterregistrierung:

# List registered clusters
kubectl get secret -n argocd -l argocd.argoproj.io/secret-type=cluster

# Verify cluster secret format
kubectl get secret CLUSTER_SECRET_NAME -n argocd -o yaml

Stellen Sie sicher, dass das server Feld den EKS-Cluster-ARN und nicht die Kubernetes-API-URL enthält.

Überprüfen Sie den Zugriffseintrag für den Zielcluster:

Überprüfen Sie auf dem Zielcluster, ob die Argo-CD-Capability-Rolle über einen Zugriffseintrag verfügt:

# List access entries (run on target cluster or use AWS CLI)
aws eks list-access-entries --cluster-name target-cluster

# Describe specific access entry
aws eks describe-access-entry \
  --cluster-name target-cluster \
  --principal-arn arn:aws:iam::111122223333:role/my-argocd-capability-role
      

Überprüfen Sie die IAM-Berechtigungen für kontoübergreifend:

Stellen Sie bei kontoübergreifenden Bereitstellungen sicher, dass die Argo-CD-Capability-Rolle über einen Zugriffseintrag auf dem Zielcluster verfügt. Die verwaltete Funktion verwendet EKS-Zugriffseinträge für den kontoübergreifenden Zugriff und nicht für die Übernahme von IAM-Rollen.

Weitere Informationen zur Konfiguration mehrerer Cluster finden Sie unter. Zielcluster registrieren

Längere Anwendungssynchronisierungszeit

Wenn Ihre Anwendungen zwar synchronisiert werden, aber länger als erwartet dauert, verwenden Sie die folgenden Diagnoseschritte, um die Ursache zu ermitteln.

Überprüfen Sie die Uhrzeit der letzten Synchronisierung

Bestätigen Sie die Verzögerung, indem Sie überprüfen, wann Anwendungen zuletzt synchronisiert wurden:

# View last sync time for all applications
kubectl get application -n argocd -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.operationState.finishedAt}{"\n"}{end}'

# View last sync time for a specific application
kubectl get application my-app -n argocd -o jsonpath='{.status.operationState.finishedAt}'

Überprüfen Sie die Anwendungsbedingungen

Überprüfen Sie die Anwendungsbedingungen für Verzögerungen bei der Warteschlange beim Abgleich:

# Check conditions on an application
kubectl get application my-app -n argocd -o jsonpath='{.status.conditions}'

Überprüfen Sie die TargetRevision-Konfiguration

Anwendungen, die den Manifest-Cache verwenden, machen den Manifest-Cache bei jedem Commit in das Repository targetRevision: HEAD ungültig, was die Synchronisierungszeiten verlangsamt:

# List applications using HEAD as targetRevision
kubectl get application -n argocd -o jsonpath='{range .items[?(@.spec.source.targetRevision=="HEAD")]}{.metadata.name}{"\n"}{end}'

Häufige Ursachen

Abhilfemaßnahmen

Anwendungen werden wiederholt synchronisiert oder hängen nicht mehr synchron

Wenn Ihre Anwendung synchronisiert wird OutOfSync und dann sofort gestartet wird oder wenn sie in einer Synchronisierungsschleife stecken bleibt, liegt die Ursache normalerweise in einer Drift zwischen dem, was Git definiert, und dem, was im Cluster existiert. Beginnen Sie mit der Basisdiagnose.

Sammeln Sie Diagnoseinformationen

# View current sync and health status
argocd app get my-app

# Show exact fields that differ between Git and live state
argocd app diff my-app

# Check whether the app has ever reached a stable state
argocd app history my-app
         

Der argocd app diff Befehl ist der nützlichste Ausgangspunkt. Es zeigt Ihnen genau, welche Felder dazu führen, dass die Anwendung nicht mehr synchron erscheint.

Self-managed Zertifikate führen zu Abweichungen

Controller wie Cert-Manager, OPA Gatekeeper und KEDA generieren Zertifikate zur Laufzeit. Diese Laufzeitwerte sind nicht in Git enthalten, sodass Argo CD bei jedem Abgleich Abweichungen erkennt.

Die Symptome sind:

Um dieses Problem zu beheben, fügen Sie ignoreDifferences für die betroffenen Felder Folgendes hinzu und aktivieren Sie RespectIgnoreDifferences in Ihren Synchronisierungsoptionen:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
spec:
  ignoreDifferences:
    - group: admissionregistration.k8s.io
      kind: ValidatingWebhookConfiguration
      jsonPointers:
        - /webhooks/0/clientConfig/caBundle
    - group: ""
      kind: Secret
      jsonPointers:
        - /data/tls.crt
        - /data/tls.key
  syncPolicy:
    syncOptions:
      - RespectIgnoreDifferences=true

Self-heal unterbricht langsam startende Workloads

Wenn diese Option aktiviert selfHeal ist, synchronisiert Argo CD die Anwendung erneut, wenn Drift erkannt wird. Wenn es 30—60 Sekunden dauert, bis Ihr Workload gestartet wird, wird die Selbstheilung ausgelöst, bevor der Workload gestartet wird. Healthy Wenn diese prune Option aktiviert ist, kann dies dazu führen, dass teilweise gestartete Ressourcen heruntergefahren werden.

Um dieses Problem zu beheben, korrigieren Sie zunächst die zugrunde liegende Abweichung (siehe das Zertifikatsszenario). Wenn Drift nicht die Ursache ist, erwägen Sie, Self-Heal für Workloads zu deaktivieren, die Sie ausschließlich über Git verwalten:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
spec:
  syncPolicy:
    automated:
      selfHeal: false
      prune: false

ApplicationSet oder Kollisionen beim Besitz von Ressourcen

Wenn zwei Anwendungen oder dieselbe Kubernetes-Ressource ApplicationSets verwalten, zeigt Argo CD eine. SharedResourceWarning Die Ressource erreicht nie einen stabilen Zustand. Dies ist häufig der Fall, wenn ein gemeinsam genutzter Ressourcenname nicht pro Umgebung oder Cluster festgelegt ist.

Um dieses Problem zu lösen:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: my-appset
spec:
  syncPolicy:
    preserveResourcesOnDeletion: true

Beim Löschen von Ressourcen in den Finalizern ist es hängengeblieben

Wenn eine Anwendung im Terminating Status „hängenbleibt“ oder die Meldung „N Objekte, die noch gelöscht werden müssen“ anzeigt, blockiert der resources-finalizer.argocd.argoproj.io Finalizer das Löschen, bis alle verwalteten Ressourcen gelöscht sind. Eine verwaltete Ressource mit einem eigenen Finalizer, der nicht verarbeitet werden kann, blockiert das Löschen auf unbestimmte Zeit.

Um dies zu bestätigen, listen Sie Ressourcen auf, die zwar einen Löschzeitstempel haben, aber nicht entfernt wurden:

kubectl get all -n my-namespace -o json | \
  jq '.items[] | select(.metadata.deletionTimestamp != null) | {name: .metadata.name, kind: .kind, finalizers: .metadata.finalizers}'

Um dieses Problem zu lösen:

kubectl patch resource-kind
            resource-name -n my-namespace \
  --type json -p '[{"op": "remove", "path": "/metadata/finalizers/0"}]'

Fehlgeschlagene Synchronisierung versucht nicht automatisch, dieselbe Revision zu verwenden

Wenn eine Synchronisierung mit einer bestimmten Revision fehlschlägt, versucht Argo CD nicht automatisch, dieselbe Revision erneut zu versuchen. Dies geschieht häufig aufgrund eines offensichtlichen Fehlers, z. B. aufgrund eines doppelten ComparisonError Umgebungsvariablenschlüssels.

Bestätigen Sie dies, indem Sie den Status der Anwendung überprüfen:

argocd app get my-app
# Look for: Operation: Sync  Phase: Failed  Revision: <sha>

Um dieses Problem zu beheben, beheben Sie den offensichtlichen Fehler in Ihrem Git-Repository und senden Sie einen neuen Commit. Alternativ können Sie eine manuelle Synchronisierung auslösen:

argocd app sync my-app
         

Der Monorepo Commit Churn löst eine umfassende Regenerierung aus

Wenn sich viele Anwendungen HEAD auf demselben Repository befinden, ändert sich jeder Commit an dieses Repository HEAD für alle Anwendungen. Dadurch wird die Manifest-Regenerierung für jede Anwendung ausgelöst, auch für diejenigen, deren Dateien sich nicht geändert haben. Weitere Informationen zu targetRevision und zum Zwischenspeichern finden Sie im Abschnitt „Verlängerte Anwendungssynchronisierungszeit“ auf dieser Seite.

Um die Regenerierung nur auf die Dateien zu beschränken, die jede Anwendung verwendet, fügen Sie die folgende manifest-generate-paths Anmerkung hinzu:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  annotations:
    argocd.argoproj.io/manifest-generate-paths: /apps/my-app
spec:
  source:
    repoURL: https://github.com/my-org/my-monorepo.git
    targetRevision: HEAD
    path: apps/my-app

Mit dieser Anmerkung regeneriert Argo CD nur dann Manifeste, wenn sich Dateien unter dem angegebenen Pfad ändern. Für gemeinsam genutzte Bibliotheken, die anwendungsübergreifend verwendet werden, können Sie mehrere Pfade angeben, die durch Semikolons () getrennt sind. ;

Wenn möglich, sollten Sie stattdessen targetRevision an einen Branchennamen oder ein Branch-Tag anheften. HEAD

Die Standardeinstellung von Kubernetes und die Änderung von Webhooks führen zu Phantomunterschieden

Wenn Ihre Anwendung OutOfSync unmittelbar nach einer Synchronisierung angezeigt wird, überprüfen Sie den Unterschied auf Felder, die Sie nie festgelegt haben (wie, oder). terminationGracePeriodSeconds dnsPolicy /spec/replicas Der Kubernetes-API-Server oder ein mutierender Webhook haben diese Felder bei der Bewerbung hinzugefügt.

Um dieses Problem für Felder zu lösen, die von einem anderen Controller verwaltet werden (z. B. /spec/replicas wenn ein HPA die Skalierung verwaltet), fügen Sie Folgendes hinzu: ignoreDifferences

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
spec:
  ignoreDifferences:
    - group: apps
      kind: Deployment
      jsonPointers:
        - /spec/replicas
  syncPolicy:
    syncOptions:
      - RespectIgnoreDifferences=true

Für Felder, die durch standardmäßige oder mutierende Kubernetes-Webhooks hinzugefügt wurden, können Sie serverseitigen Diff in der Anwendung aktivieren:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  annotations:
    argocd.argoproj.io/compare-options: ServerSideDiff=true,IncludeMutationWebhook=true

Server-side diff führt pro Ressource einen Probelauf durch, wodurch die Auslastung des Kubernetes-API-Servers erhöht wird. Testen Sie dies an einer kleinen Anzahl von Anwendungen, bevor Sie es allgemein aktivieren.

High-churn Ressourcen, die dem Controller gehören

Einige Controller generieren eine große Anzahl kurzlebiger oder häufig aktualisierter Ressourcen. Beispiele hierfür sind Karpenter-Knotenobjekte, Cilium-Identitäts- und Endpunktobjekte sowie Kyverno-Richtlinienberichte. Wenn diese Ressourcen eine große Anzahl von Überwachungsereignissen generieren und zu einer Fluktuation bei Synchronisationen führen, können Sie die Auslastung reduzieren, indem Sie diese Ressourcentypen ausschließen oder Überwachungsereignisse filtern. Diese Änderungen erfordern eine Controller-Konfiguration auf Instanzebene.

Öffnen Sie für die verwaltete Funktion eine AWS Support-Anfrage, um Ressourcenausschlüsse oder die Filterung von Überwachungsereignissen für diese Ressourcentypen anzufordern.

Bewährte Methoden

Wann sollten Sie Kontakt aufnehmen AWS Support

Öffnen Sie in den folgenden Situationen eine AWS Support-Anfrage:

Nehmen Sie die Ergebnisse von argocd app get und argocd app diff für die betroffenen Anwendungen in Ihre Support-Anfrage auf.

Nächste Schritte