Zum Hauptinhalt springen
Betreiben Sie Ihre Anwendung und den AgentEye-Collector im selben Kubernetes-Pod, sodass Telemetriedaten zur Erfassung niemals eine Netzwerkgrenze überschreiten müssen. Das SDK Ihrer Anwendung und der Collector teilen sich einen gemeinsamen In-Pod-Ereignis-Spool, was einen latenzarmen, prozessinternen Telemetrie-Übergabe ohne exponierten localhost-Port, ohne Durchquerung eines Service-Mesh und mit einem direkt an die beobachtete Arbeitslast gebundenen Collector-Lebenszyklus ermöglicht. Das mTLS-Client-Zertifikat, das der Collector vorlegt, wird direkt über AWS Secrets Manager in Ihren Pod geliefert, sodass eine Zertifikatsrotation ohne manuelles Verschieben von Dateien auf Ihrer Seite auskommt. Das hier beschriebene Sidecar- und Shared-Spool-Modell ist cloud-agnostisch: Zwei Container, die sich ein emptyDir-Ereignis-Spool teilen, funktionieren auf jeder Kubernetes-Distribution. Lediglich der Pfad zur Zertifikatsauslieferung in diesem Leitfaden (AWS Secrets Manager + Secrets Store CSI Driver + IRSA) ist spezifisch für AWS/EKS. Wenn Sie eine andere Umgebung verwenden, behalten Sie das Pod- und Spool-Layout bei und ersetzen Sie den Secret-Mount-Mechanismus aus Phase 2 und 3 durch den Ihrer Plattform.
Wann sollte dieses Muster verwendet werden? Wählen Sie Single-Pod, wenn Ihre Anwendung den Collector nicht über eine Netzwerkgrenze hinweg ansprechen soll (latenzarme In-Pod-IPC, enge Lebenszyklus-Kopplung, Pod-Isolierung pro Mandant). Für Multi-App-Flotten, die einen gemeinsamen Collector pro Node oder Cluster verwenden, lesen Sie stattdessen enterprise-docs/kubernetes-deployment.md.

Auf einen Blick

Zwei Datenflüsse, zwei Volumes:
  • Ereignisse (In-Pod): Das SDK Ihrer Anwendung schreibt .jsonl-Dateien in das gemeinsame emptyDir unter $AGENTEYE_HOME/events/; der Collector-Sweeper liest und lädt sie hoch. Kein localhost-Port, kein Loopback – reine Shared-Filesystem-Übergabe.
  • mTLS-Zertifikat (Pod ← Cloud): Der Secrets Store CSI Driver bindet das Zertifikats-Bundle aus dem Secrets Manager als schreibgeschütztes Volume unter /etc/agenteye/tls/ ein, begrenzt auf den Collector-Container.
Zwei unabhängige Parteien:
ParteiVerantwortlichkeit
ExosphereStellt das mTLS-Client-Zertifikat aus und liefert das Bundle in das Secrets Manager Ihres AWS-Kontos unter einem stabilen Namen. Veröffentlicht das erneuerte Bundle vor Ablauf erneut in demselben Secret.
SieInstallieren den Secrets Store CSI Driver, gewähren dem ServiceAccount des Pods per IRSA Lesezugriff auf das Secret und wenden das Pod-Manifest an. Das ist alles.

Voraussetzungen

In Ihrem AWS-Konto / EKS-Cluster

  • Ein EKS-Cluster mit einem zugehörigen OIDC-Provider. Überprüfen Sie dies mit:
    Wenn der Befehl eine https://oidc.eks.…-URL zurückgibt, ist OIDC aktiviert. Andernfalls verknüpfen Sie einen:
  • Der Secrets Store CSI Driver und der AWS-Provider sind im Cluster installiert (siehe § Phase 2).
  • AWS CLI v2 und kubectl auf Ihrer Arbeitsstation.

Abstimmung mit Exosphere

Vor der Bereitstellung liefert Exosphere das mTLS-Client-Bundle in das Secrets Manager Ihres AWS-Kontos und stellt Folgendes bereit:
  • Den Secret-Namen (Konvention: agenteye/mtls-client/<your-cluster>)
  • Die AWS-Region, in der das Secret gespeichert ist
  • Die AgentEye-Backend-URL zur Konfiguration des Collectors
  • Ihren Collector-API-Key (siehe enterprise-docs/api-keys.md)

Phase 1: Was Exosphere liefert

Sie generieren das mTLS-Client-Zertifikat nicht selbst. Exosphere stellt es aus und liefert das Bundle direkt in das Secrets Manager Ihres AWS-Kontos, sodass das einzige Credential-Material, das in Ihrer Umgebung landet, das fertige, einsatzbereite Secret ist. Was in Ihrem Konto ankommt:
EigenschaftWert
Secret-Nameagenteye/mtls-client/<cluster-name> (stabil über Erneuerungen hinweg)
RegionDie AWS-Region, die Sie für Ihren EKS-Cluster festgelegt haben
PayloadEin einzelnes JSON-Secret mit drei Schlüsseln (client.crt, client.key und ca.crt), die jeweils das PEM-kodierte Material enthalten
TagAgentEyeCluster=<cluster-name>
Bei der Erneuerung wird dasselbe Secret mit einer neuen Version aktualisiert, sodass ARN und Name sich nie ändern; Ihre SecretProviderClass und IAM-Policy bleiben unverändert funktionsfähig. Informationen zum Zertifikatslebenszyklus (Gültigkeit, Erneuerungsrhythmus, Ablaufwarnungen) finden Sie unter enterprise-docs/kubernetes-deployment.md.

Phase 2: Secrets Store CSI Driver + AWS-Provider installieren

Überspringen Sie diesen Schritt, wenn Sie bereits eine andere Arbeitslast betreiben, die AWS-Secrets per CSI einbindet.
Überprüfung:
Erwartet: Running für jeden Pod.
Warum rotationPollInterval=1h? Wenn Exosphere ein erneuertes Zertifikat veröffentlicht, wird Secrets Manager direkt aktualisiert. Der CSI Driver liest das Secret in diesem Intervall erneut und überschreibt die eingebundenen Dateien. Der Collector liest die Zertifikatsdateien einmalig beim Start, sodass er das erneuerte Zertifikat erst nach einem Prozess-Neustart vorlegt; unter § Zertifikatsrotation erfahren Sie, wie Sie diesen auslösen.

Phase 3: Pod-Lesezugriff auf das Secret gewähren (IRSA)

3.1 IAM-Policy erstellen

Speichern Sie als agenteye-mtls-reader-policy.json:
Ersetzen Sie <region>, <account-id> und <cluster-name>. Das abschließende -* entspricht dem sechsstelligen Zufallssuffix, den AWS an jeden Secret-ARN anhängt. Policy erstellen:

3.2 IAM-Rolle erstellen und an den ServiceAccount des Pods binden

Dies erstellt einen ServiceAccount namens agenteye-pod mit der eks.amazonaws.com/role-arn-Annotation, die auf die neue Rolle verweist.

3.3 Erforderliche IAM-Berechtigungen: Zusammenfassung

BerechtigungGeltungsbereichZweck
secretsmanager:GetSecretValuearn:aws:secretsmanager:<region>:<acct>:secret:agenteye/mtls-client/<cluster>-*CSI Driver liest das Zertifikats-Bundle bei jedem Mount- und Rotations-Tick.
secretsmanager:DescribeSecretwie obenCSI Driver ruft DescribeSecret auf, um Versionsänderungen zwischen den Abfragen zu erkennen.
Gewähren Sie dem Pod NICHT secretsmanager:PutSecretValue, secretsmanager:UpdateSecret oder secretsmanager:DeleteSecret. Der Pod liest das Secret ausschließlich; das Schreiben neuer Versionen übernimmt Exosphere bei der Ausstellung oder Erneuerung des Zertifikats. Wenn das Secret mit einem kundenverwalteten KMS-Schlüssel (nicht dem Standard-Schlüssel aws/secretsmanager) verschlüsselt ist, gewähren Sie zusätzlich:

Phase 4: Den Pod bereitstellen

4.1 SecretProviderClass

agenteye-mtls-spc.yaml:
Der jmesPath-Block weist den AWS-Provider an, das JSON-Secret in drei separate Dateien auf der Festplatte aufzuteilen. Die Anführungszeichen in '"client.crt"' sind erforderlich, weil JMESPath . als Teilausdruck-Operator behandelt.

4.2 Pod-/Deployment-Manifest

Wie die beiden Container miteinander kommunizieren. Das AgentEye-SDK und der Collector kommunizieren nicht über einen Netzwerk-Socket; es gibt keinen lokalen HTTP-Port. Das SDK schreibt Ereignis-Batches als .jsonl-Dateien in $AGENTEYE_HOME/events/, und der Collector überwacht dieses Verzeichnis kontinuierlich und lädt jede Datei hoch. Für einen Sidecar-Pod bedeutet das:
  • Beide Container binden dasselbe emptyDir-Volume am gleichen Pfad ein.
  • Beide Container setzen AGENTEYE_HOME auf diesen Pfad.
  • Ihr Anwendungs-Image muss das AgentEye-SDK installiert und konfiguriert haben (siehe enterprise-docs/python-sdk.md).
Wenn AGENTEYE_HOME nicht gesetzt ist, verwenden sowohl das SDK als auch der Collector standardmäßig ~/.agenteye, und die beiden Container haben unterschiedliche Home-Verzeichnisse, sodass sie auf zwei separate Spools landen würden und die Übergabe lautlos fehlschlägt. Setzen Sie AGENTEYE_HOME auf beiden Containern auf denselben expliziten Pfad. Die Überprüfung in §4.3 und die entsprechende Zeile im Abschnitt Fehlerbehebung erkennen dies, falls es versäumt wurde.
agenteye-pod.yaml (Deployment mit einem Replikat, nach Bedarf skalierbar):
Das Secret agenteye-collector-api-key enthält den API-Key des Collectors (zur Bereitstellung siehe enterprise-docs/api-keys.md). Anwenden:

4.3 Überprüfung

Erwartet: client.crt, client.key, ca.crt sind alle vorhanden, schreibgeschützt und im Besitz des Container-Benutzers. Bestätigen Sie, dass der gemeinsame Ereignis-Spool für beide Container sichtbar ist:
Wenn die beiden Auflistungen voneinander abweichen, ist das Volume nicht in beiden Containern eingebunden (oder AGENTEYE_HOME unterscheidet sich); siehe § Fehlerbehebung. End-to-End-Smoke-Test:
Erwartet: Der Collector lädt alle in der Warteschlange befindlichen Ereignisse hoch und gibt eine Zusammenfassung Done: N/N uploaded, 0 failed. aus. Wenn der Spool leer ist, gibt er No pending files. aus und beendet sich, ohne etwas zu validieren – führen Sie dies daher erst aus, nachdem Ihre Anwendung mindestens ein Ereignis geflusht hat. Beachten Sie, dass flush nur bei lokalen Konfigurationsfehlern mit einem Nicht-Null-Exitcode abbricht: fehlende Konfiguration (keine URL/kein Key auflösbar) oder ein unlesbares/nicht parsebares TLS-Zertifikat (siehe § Fehlerbehebung). Ein falscher API-Key ändert den Exitcode nicht — der Upload erhält eine 401-Antwort, die Datei wird nach failed/ verschoben, und der Befehl gibt dennoch [FAILED] … pro Datei sowie Done: 0/N uploaded, N failed. aus und beendet sich mit 0. Um einen falschen Key oder einen abgelehnten Upload zu erkennen, lesen Sie die Done:/[FAILED]-Ausgabe oder prüfen Sie, ob Dateien in $AGENTEYE_HOME/failed/ landen, nicht den Exitcode.

Zertifikatsrotation

Das Client-Zertifikat ist 90 Tage gültig und wird automatisch etwa 15 Tage vor Ablauf erneuert; Exosphere veröffentlicht das erneuerte Bundle dann in dasselbe Secrets Manager-Secret. Danach läuft der In-Pod-Ablauf wie folgt:
  1. Das Secret in Secrets Manager erhält eine neue AWSCURRENT-Version. ARN und Name bleiben unverändert.
  2. Innerhalb des rotationPollInterval (standardmäßig 1h; siehe § Phase 2) liest der CSI Driver die neue Version und überschreibt die Dateien unter /etc/agenteye/tls/.
  3. Der Collector lädt die Zertifikatsdateien einmalig beim Start, sodass er das vorherige Zertifikat weiter vorlegt, bis der Prozess neu gestartet wird. Um zum erneuerten Material zu wechseln, starten Sie den Collector neu; ein Rolling Restart reicht aus:
    Um dies zu automatisieren, fügen Sie einen Sidecar hinzu, der /etc/agenteye/tls/ überwacht (z. B. mit inotifywait) und den Rollout auslöst, wenn sich die Dateien ändern.
Da das vorherige Zertifikat nach der Erneuerung noch etwa 15 Tage gültig bleibt, haben Sie ein großzügiges Zeitfenster für den Neustart ohne Unterbrechung der Datenerfassung. Exosphere veröffentlicht das erneuerte Bundle für Sie; die einzige routinemäßige Aktion auf Ihrer Seite besteht darin, sicherzustellen, dass der Collector innerhalb dieses Zeitfensters neu gestartet wird.

Fehlerbehebung

SymptomWahrscheinliche UrsacheLösung
Pod bleibt in ContainerCreating, Ereignisse zeigen MountVolume.SetUp failed for volume "agenteye-mtls"CSI-Provider kann Secrets Manager nicht erreichenPrüfen Sie, ob IRSA korrekt gebunden ist: kubectl describe sa agenteye-pod -n <ns> zeigt die eks.amazonaws.com/role-arn-Annotation. Prüfen Sie CloudTrail auf den AssumeRole-Aufruf.
Fehler: AccessDeniedException: not authorized to perform secretsmanager:GetSecretValueIAM-Policy ist auf den falschen ARN beschränktDas Secret-ARN-Suffix ist zufällig; verwenden Sie agenteye/mtls-client/<cluster>-* mit Wildcard, nicht den exakten ARN.
Fehler: ParameterNotFound vom AWS-ProviderSecret-Name stimmt nicht zwischen SecretProviderClass.objects[].objectName und dem von Exosphere gelieferten Secret übereinBestätigen Sie den genauen Namen mit aws secretsmanager list-secrets --filters Key=tag-key,Values=AgentEyeCluster.
jmesPath-Fehler, nur eine Datei eingebundenJMESPath-SyntaxDie Punkte in den JSON-Schlüsseln erfordern doppelte Anführungszeichen: '"client.crt"', nicht client.crt.
Collector-Logs zeigen tls: bad certificate nach einer ErneuerungDer CSI Driver hat die neue Version noch nicht abgefragt, oder der Collector läuft noch mit dem beim Start geladenen vorherigen ZertifikatBestätigen Sie, dass die eingebundenen Dateien aktualisiert wurden (ls -l /etc/agenteye/tls/), und starten Sie dann den Collector neu, um sie zu laden: kubectl rollout restart deploy/my-app-with-collector -n <ns>. Siehe § Zertifikatsrotation.
Collector-Container crashloopt mit no such file or directory: /etc/agenteye/tls/client.crtVolume beim ersten Start noch nicht befüllt; Startup-Probe zu aggressivFügen Sie eine kurze Anfangsverzögerung hinzu oder verwenden Sie einen Init-Container, der auf das Vorhandensein der Datei wartet: until [ -f /etc/agenteye/tls/client.crt ]; do sleep 1; done.
CSI-Driver-Pod OOMKilledStandard-Speicherlimits zu niedrig für Cluster mit vielen SecretProviderClassesErhöhen Sie --set linux.resources.limits.memory=200Mi bei der Helm-Installation.
App läuft einwandfrei, agenteye-collector flush meldet No pending files., aber das AgentEye-Dashboard zeigt keine EreignisseApp und Collector teilen sich nicht denselben Ereignis-SpoolPrüfen Sie, ob (a) beide Container dasselbe agenteye-spool-emptyDir am selben Pfad einbinden und (b) beide AGENTEYE_HOME auf diesen Pfad setzen. Führen Sie die beiden ls /var/lib/agenteye/-Prüfungen aus § 4.3 aus; die Auflistungen müssen übereinstimmen.
Zuerst zu prüfende Logs:

Referenz: Dateien auf dem Pod-Datenträger

Der Pod hat zwei Datenpfade auf dem Datenträger:

mTLS-Zertifikats-Bundle: /etc/agenteye/tls/ (CSI, schreibgeschützt, nur Collector)

Eingebunden durch den Secrets Store CSI Driver aus AWS Secrets Manager.
DateiInhaltVom Collector verwendet als
client.crtPEM-kodiertes Client-ZertifikatAGENTEYE_TLS_CERT
client.keyPEM-kodierter privater SchlüsselAGENTEYE_TLS_KEY
ca.crtPEM-kodiertes CA-ZertifikatAGENTEYE_TLS_CA (optional, nur wenn das AgentEye-Server-Zertifikat nicht öffentlich vertrauenswürdig ist)
Alle drei sind schreibgeschützt eingebunden und im Besitz des Container-Benutzers. Sie werden vom CSI Driver bei der Rotation des Secrets neu geschrieben.

Ereignis-Spool: $AGENTEYE_HOME/ (emptyDir, gemeinsam les- und schreibbar für beide Container)

Geteilt über ein emptyDir-Volume namens agenteye-spool.
PfadGeschrieben vonGelesen vonZweck
$AGENTEYE_HOME/events/*.jsonlApp (AgentEye-SDK)Collector-SweeperEreignis-Batches, die das SDK geflusht hat und die auf den Upload warten.
$AGENTEYE_HOME/failed/Collector (bei Upload-Fehler)Sie (beim Debugging)JSONL-Dateien, die der Collector nach Wiederholungsversuchen nicht hochladen konnte.
$AGENTEYE_HOME/config.jsonSie (optional)CollectorOptionale Collector-Konfigurationsdatei (Alternative zu Umgebungsvariablen).
Sowohl das Unterverzeichnis events/ als auch failed/ werden beim Start automatisch vom Collector angelegt; kein initContainer erforderlich.

Verwandte Dokumentation