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 unter, 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.

Beheben Sie Probleme mit den Funktionen von Argo CD

Die Funktion ist AKTIV, aber die Anwendungen werden nicht synchronisiert

Wenn Ihre Argo-CD-Funktion ACTIVE den Status anzeigt, die Anwendungen jedoch nicht synchronisiert werden, überprüfen Sie den Zustand der Funktion und den Anwendungsstatus.

Überprüfen Sie den Zustand der Fähigkeiten:

Sie können Probleme mit dem Status und dem Status von Fähigkeiten in der EKS-Konsole oder mithilfe der 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 Bewerbungsstatus:

# 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 stecken im Status „In Bearbeitung“ fest

Wenn eine Anwendung Progressing zwar angezeigt wird, sie aber nie erreichtHealthy, ü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 Zielcluster-Konfiguration (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 bei der Authentifizierung im Repository

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-Funktionsrolle über die folgenden 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 eine codecommit:GitPull Genehmigung 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 Anmeldeinformationen für die Authentifizierung enthält (SSH-Schlüssel, Token oder username/password).

Für Repositorys, 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 Cluster-Registrierung 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 Role ü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 das Cross-Konto:

Stellen Sie bei kontoübergreifenden Bereitstellungen sicher, dass die Argo CD Capability Role über einen Zugriffseintrag auf dem Zielcluster verfügt. Die verwaltete Funktion verwendet EKS Access Entries für den kontoübergreifenden Zugriff, nicht für die Übernahme der IAM-Rollen.

Weitere Informationen zur Multi-Cluster-Konfiguration finden Sie unter. Zielcluster registrieren

Verlängerte Synchronisierungszeit der Anwendung

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 Bewerbungsbedingungen für Verzögerungen in der Abstimmungswarteschlange:

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

Überprüfen Sie die TargetRevision-Konfiguration

Anwendungen, die targetRevision: HEAD dies verwenden, machen den Manifest-Cache bei jedem Commit in das Repository ungültig, was die Synchronisationszeiten 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 deine Anwendung synchronisiert wird und dann sofort wieder abgeschaltet wird OutOfSync oder wenn sie in einer Synchronisationsschleife stecken bleibt, liegt die Ursache normalerweise in einer Abweichung 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 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 eine Abweichung feststellt.

Die Symptome sind:

Um dies 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 eine Abweichung festgestellt wird. Wenn der Start Ihrer Arbeitslast 30—60 Sekunden dauert, wird die Selbstheilung ausgelöst, bevor die Arbeitslast steigt. Healthy Wenn diese prune Option aktiviert ist, können teilweise gestartete Ressourcen zum Erliegen kommen.

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

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

ApplicationSet oder Konflikte im Zusammenhang mit dem Besitz von Ressourcen

Wenn zwei Anwendungen oder dieselbe Kubernetes-Ressource ApplicationSets verwalten, zeigt Argo CD eine an. SharedResourceWarning Die Ressource erreicht niemals einen stabilen Zustand. Dies passiert häufig, wenn ein gemeinsam genutzter Ressourcenname nicht auf die einzelnen Umgebungen oder Cluster beschränkt ist.

Um dieses Problem zu lösen:

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

Blockiertes Löschen von Ressourcenfinalisierern

Wenn eine Anwendung im Terminating Status feststeckt 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.

Zur Bestätigung listen Sie Ressourcen auf, die einen Löschzeitstempel haben, aber noch 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:

Verwenden Sie die Finalizer-Liste, die der vorherige Befehl gedruckt hat, und setzen Sie die Liste auf die Finalizer ein, die Sie behalten möchten, und lassen Sie nur den blockierenden Finalizer weg. Ersetzen Sie finalizer-a und durch diese Namenfinalizer-b:

kubectl patch resource-kind
            resource-name -n my-namespace \
  --type merge -p '{"metadata":{"finalizers":["finalizer-a","finalizer-b"]}}'

Wenn der blockierende Finalizer der einzige auf der Ressource ist, übergeben Sie eine leere Liste:. --type merge -p '{"metadata":{"finalizers":[]}}'

Bei einer fehlgeschlagenen Synchronisierung wird nicht automatisch erneut versucht, dieselbe Version zu verwenden

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

Bestätigen Sie dies, indem Sie den Anwendungsstatus überprüfen:

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

Um dies zu beheben, repariere den Manifestdefekt in deinem Git-Repository und pushe einen neuen Commit. Alternativ kannst du eine manuelle Synchronisation auslösen:

argocd app sync my-app
         

Die Abwanderung von Monorepo-Commit löst eine umfassende Regenerierung aus

Wenn viele Anwendungen dasselbe Projektarchiv verwenden, ändert sich jeder Commit in dieses Projektarchiv HEAD für alle Anwendungen. HEAD Dies löst für jede Anwendung eine manifeste Regenerierung aus, auch für diejenigen, deren Dateien sich nicht geändert haben. Weitere Informationen zu targetRevision und Caching finden Sie im Abschnitt „Verlängerte Synchronisierungszeit von Anwendungen“ auf dieser Seite.

Um die Regenerierung nur auf die Dateien zu beschränken, die jede Anwendung verwendet, fügen Sie die 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 Manifeste nur, 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, heften targetRevision Sie es stattdessen an einen Zweignamen oder ein Tag an. HEAD

Standardmäßige und mutierende Webhooks in Kubernetes führen zu Phantom-Diffs

Wenn Ihre Anwendung OutOfSync sofort nach einer Synchronisierung angezeigt wird, überprüfen Sie den Diff auf Felder, die Sie nie gesetzt haben (wie, oder). terminationGracePeriodSeconds dnsPolicy /spec/replicas Der Kubernetes-API-Server oder ein sich verändernder Webhook haben diese Felder zum Zeitpunkt der Anwendung hinzugefügt.

Um dies für Felder zu beheben, 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 den 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 Belastung 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 hohe Anzahl von Überwachungsereignissen generieren und zu einer Abwanderung von Synchronisationen führen, können Sie die Belastung reduzieren, indem Sie diese Ressourcenarten ausschließen oder Überwachungsereignisse filtern. Diese Änderungen erfordern eine Controller-Konfiguration auf Instanzebene.

Öffnen Sie für die verwaltete Funktion einen AWS Support-Fall, um Ressourcenausschlüsse oder die Filterung nach Ereignissen für diese Ressourcentypen anzufordern.

Bewährte Methoden

Wann soll ich Kontakt aufnehmen AWS Support

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

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

Nächste Schritte