> ## Documentation Index > Fetch the complete documentation index at: https://docs.befailproof.ai/llms.txt > Use this file to discover all available pages before exploring further. # Managed Deployment auf Ihrem Kubernetes-Cluster > Dokumentation zum AgentEye Managed Deployment auf Ihrem Kubernetes-Cluster. AgentEye ist eine selbst gehostete Observability- und Evaluierungsplattform für KI- und LLM-Agenten. Sie erfasst Agenten-Sessions, Tool-Aufrufe, Modellanfragen und Fehler, verwandelt diese in durchsuchbare Analysen und Evaluierungen und stellt die Ergebnisse in einem Dashboard mit einem optionalen schreibgeschützten KI-Assistenten bereit. Im Managed-Deployment-Modell stellen Sie einen dedizierten Kubernetes-Cluster bereit, und Exosphere betreibt die gesamte Plattform darin – einschließlich Deployment, Konfiguration, Betrieb, Backup und Upgrades aller Komponenten in Ihrem Auftrag. Ihr Team profitiert vom vollen Plattformwert (Agenten-Transparenz, Analysen, Evaluierung und der optionale Assistent), ohne selbst Datenbanken, Zertifikate oder Upgrades verwalten zu müssen. Alle Daten verbleiben in Ihrem Cloud-Account. *** ## Voraussetzungen * Ein **GitHub PAT** zum Abrufen von Container-Images und zum Herunterladen von Artefakten (siehe [enterprise-docs/github-token.md](/de/agenteye/github-token)) * Ein **dedizierter Kubernetes-Cluster** (siehe Anforderungen unten) * Ein **Storage-Bucket** für Datenbank-Backups * **Netzwerkkonnektivität**: Port 443 eingehend zum Load Balancer des Clusters *** ## Schritt 1: Dedizierten Kubernetes-Cluster bereitstellen Erstellen Sie einen Kubernetes-Cluster, der ausschließlich für AgentEye genutzt wird. Er sollte nicht mit anderen Workloads geteilt werden, damit die gesamte Plattform (Anwendungsdienste, Datenbanken, Analysen und Caching) isoliert läuft und Ihre bestehende Infrastruktur nicht beeinträchtigt. | Anforderung | Details | | ----------------- | ----------------------------------------------------------------------------------------------------------- | | **Distribution** | Beliebiges konformes Kubernetes: EKS, GKE, AKS oder selbst verwaltet | | **Version** | 1.27 oder neuer | | **Node-Pool** | Minimum: **3 Nodes, jeweils 4 vCPU / 8 GB RAM** (Standard-General-Purpose-Instanzen) | | **Storage** | Eine Standard-StorageClass, die Block-Volumes bereitstellt (z. B. `gp3` auf AWS, `pd-ssd` auf GCP) | | **Load Balancer** | Der Cluster muss in der Lage sein, Cloud-LoadBalancer-Services bereitzustellen (Standard bei EKS, GKE, AKS) | > Exosphere installiert und verwaltet alles weitere im Cluster: Ingress-Controller, TLS-Zertifikate, Datenbanken, Caching, Monitoring und alle Anwendungs-Deployments. *** ## Schritt 2: Zugang für das AgentEye-Team gewähren Exosphere benötigt cluster-admin-Zugriff (oder gleichwertige umfangreiche RBAC-Berechtigungen), um Namespaces, Custom Resource Definitions, Ingress-Controller und Storage-Provisioner zu verwalten. | Anforderung | Details | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | **Zugriffsmethode** | IAM-Rolle (bevorzugt für EKS/GKE), kubeconfig oder SSO-basierter Zugriff | | **VPN / Bastion** | Wenn der Kubernetes-API-Server privat ist, stellen Sie VPN-Zugangsdaten oder Bastion-Zugriff für das Exosphere-Operations-Team bereit | *** ## Schritt 3: Netzwerkkonnektivität konfigurieren Ihr Netzwerk-Team muss eingehenden Traffic auf **Port 443** zu den Load Balancern des Clusters zulassen. Das Deployment betreibt zwei separate Load Balancer: einen für die Event-Ingestion (mTLS-geschützt) und einen für das Dashboard: | Traffic | Quelle | Ziel | Sicherheit | | ------------------- | -------------------------------- | -------------------------------- | ------------------------------------------------------ | | **Event-Ingestion** | Collector-Pods in Ihren Clustern | Ingest-LoadBalancer, Port 443 | mTLS (Client-Zertifikat) + API-Key | | **Dashboard** | Entwickler-Browser | Dashboard-LoadBalancer, Port 443 | HTTPS auf Ihrer Domain, passwortloser E-Mail-OTP-Login | Der Ingest-Endpunkt ist durch gegenseitiges TLS geschützt; Collectors müssen bei jeder Anfrage sowohl ein gültiges Client-Zertifikat **als auch** einen gültigen API-Key vorweisen. Das Dashboard läuft auf seinem eigenen Load Balancer und Hostnamen, wobei der Login auf Ihre erlaubten E-Mail-Adressen/Domains beschränkt ist. **DNS-Einträge (einmalig):** Sie erstellen zwei CNAME-Einträge unter einer Domain, die Sie kontrollieren – einen für den Ingest-Endpunkt und einen für das Dashboard (z. B. `agenteye.your-company.example`) – die auf die von Exosphere bereitgestellten Load-Balancer-Hostnamen verweisen. Exosphere stellt dann automatisch öffentlich vertrauenswürdige TLS-Zertifikate für beide Hostnamen bereit, einschließlich der Erneuerungen. > **Hinweis zu Port 80:** Die automatische Zertifikatsausstellung und -erneuerung erfolgt über HTTP auf Port 80 jedes Load Balancers. Wenn Ihre Sicherheitsrichtlinien die Einschränkung des Dashboard-Load-Balancers auf unternehmenseigene IP-Bereiche erfordern, teilen Sie dies Exosphere vorab mit – wir wechseln dann auf eine DNS-basierte Zertifikatsvalidierung (ein zusätzlicher DNS-Eintrag auf Ihrer Seite), damit Erneuerungen auch hinter der Einschränkung funktionieren. > **Ausgehend:** Cluster-Nodes benötigen Internet-Zugriff, um Container-Images von `ghcr.io` zu beziehen. Wenn Ihr Netzwerk ausgehenden Traffic einschränkt, nehmen Sie `ghcr.io` in die Allowlist auf oder spiegeln Sie Images in Ihre interne Registry. *** ## Schritt 4: Backup-Storage-Bucket bereitstellen Datenbank-Backups werden in einem Cloud-Storage-Bucket gespeichert, der Ihnen gehört. | Anforderung | Details | | ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Dienst** | S3 (AWS), GCS (GCP) oder Azure Blob Storage | | **Zugriff** | Gewähren Sie den Cluster-Nodes Schreibzugriff über eine IAM-Rolle für Service Accounts (IRSA auf EKS, Workload Identity auf GKE) oder stellen Sie Zugangsdaten bereit | | **Aufbewahrung** | Sie kontrollieren die Lifecycle-Policy des Buckets (Aufbewahrungszeitraum, Archivierungsregeln). Exosphere schreibt Backups; Sie entscheiden, wie lange sie aufbewahrt werden | Ein tägliches Backup sichert sowohl PostgreSQL (relationale Zustandsdaten) als auch ClickHouse (Events und Evaluierungen) in einem komprimierten Archiv und lädt es in Ihren Bucket hoch. Backups werden außerdem vor jedem Upgrade durchgeführt. *** ## Schritt 5: Ansprechpartner benennen Benennen Sie eine Person oder einen Slack/Teams-Kanal auf Ihrer Seite für Fragen auf Cluster-Ebene: Node-Health, Cloud-Account-Limits, Netzwerkänderungen. Der tägliche Betrieb erfordert diesen Kontakt nicht. *** ## Was wir deployen Sobald Exosphere Cluster-Zugriff hat, werden folgende Komponenten für Sie deployt und verwaltet: | Komponente | Funktion | | --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **AgentEye Server** | HTTP-API, die Events von Collectors empfängt, Analysen ausführt und Daten an das Dashboard liefert | | **Dashboard** | Web-Interface zur Anzeige von Agenten-Sessions, Tool-Aufrufen, Modellanfragen und Fehlern; enthält den optionalen schreibgeschützten KI-Assistenten | | **ClickHouse** | Erforderlicher kanonischer Speicher für ingested Events, Analysen und Evaluierungen | | **PostgreSQL** | Relationaler Speicher für Organisationen, API-Keys, Benutzer, Dashboards und gespeicherte Abfragen | | **Redis** | Optionaler gemeinsamer Cache und Rate-Limit-Backend; die Plattform degradiert graceful, wenn er nicht verfügbar ist | | **KI-Assistent (optional)** | Interner schreibgeschützter Assistenten-Container; bleibt deaktiviert, bis ein LLM-Endpunkt konfiguriert wird | | **Ingress-Controller** | Zwei Load Balancer (einer für mTLS-geschützte Ingestion, einer für das Dashboard), die TLS mit öffentlich vertrauenswürdigen, automatisch erneuerten Zertifikaten terminieren und mTLS am Ingest-Endpunkt durchsetzen | | **cert-manager** | Automatisiert die TLS-Zertifikatsbereitstellung und die Ausstellung von mTLS-Client-Zertifikaten | | **Zertifikats-Monitoring** | Ein geplanter Job prüft den Ablauf von Zertifikaten und sendet Warnmeldungen (z. B. an Slack), wenn Zertifikate ihrer Erneuerung nähern | Das Managed-Angebot betreibt außerdem die Evaluierungspipeline der Plattform, die Agentenaktivitäten anhand Ihrer Evaluierungskriterien bewertet. Weitere Informationen zu diesen Funktionen finden Sie unter [enterprise-docs/assistant.md](/de/agenteye/assistant) und [enterprise-docs/evaluation-suite.md](/de/agenteye/evaluation-suite). *** ## Was Sie von uns erhalten Nach Abschluss des Deployments erhalten Sie: | Element | Details | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Dashboard-URL** | Ein Hostname unter Ihrer Domain (z. B. `https://agenteye.your-company.example`), mit einem öffentlich vertrauenswürdigen, automatisch erneuerten TLS-Zertifikat bereitgestellt. Sie erstellen einen CNAME zum von uns bereitgestellten Load-Balancer-Hostnamen; der Login erfolgt passwortlos per E-Mail-OTP | | **Collector-Endpunkt** | Der `/events`-Pfad des Ingest-Hostnamens (z. B. `https://ingest.your-company.example/events`), mTLS-geschützt | | **Client-Zertifikat-Bundle** | Pro Cluster: Client-Zertifikat, privater Schlüssel und CA-Zertifikat, bereitgestellt als Kubernetes-Secret-Manifest. Einmalig pro Cluster anwenden | | **GitHub PAT** | Zum Herunterladen von Collector-Binärdateien und Python-SDK-Paketen | | **Collector-API-Keys** | Scoped Keys mit `events:add`-Berechtigung, einer pro Collector-Deployment | | **Installationsanleitungen** | Schritt-für-Schritt-Dokumentation für Collector und Python-SDK | *** ## Was Sie nach der Einrichtung tun Ihre einzige laufende Arbeit betrifft Ihre eigenen Agent-Maschinen, nicht den AgentEye-Cluster: 1. **Collector installieren** in jedem Kubernetes-Cluster, der KI-Agenten ausführt: Client-Zertifikat einbinden und Endpunkt-URL sowie API-Key konfigurieren. Siehe [enterprise-docs/collector-installation.md](/de/agenteye/collector-installation). 2. **Python-SDK integrieren** in Ihren Agenten-Code. Siehe [enterprise-docs/python-sdk.md](/de/agenteye/python-sdk). 3. **Dashboard öffnen** in Ihrem Browser, um Agentenaktivitäten anzuzeigen. Keine Cluster-Operationen, kein Datenbankmanagement, keine Zertifikatserneuerungen, keine Upgrades. *** ## Sicherheit * **Daten verbleiben in Ihrem Cloud-Account.** Cluster, Storage und Datenbanken laufen ausnahmslos in Ihrer Umgebung. Keine Daten verlassen Ihre Grenzen. * **Sie kontrollieren den Zugriff.** Der Cluster befindet sich in Ihrem Account. Sie können den Zugriff von Exosphere jederzeit prüfen, überwachen oder widerrufen. Alle Operationen werden im Audit-Log Ihrer Cloud erfasst (CloudTrail, GCP Audit Logs usw.). * **mTLS bei der Event-Ingestion.** Jede Collector-Anfrage erfordert sowohl ein gültiges Client-Zertifikat als auch einen API-Key. Ein geleakter Key ist ohne das Zertifikat wertlos; ein gestohlenes Zertifikat ist ohne einen gültigen Key nutzlos. * **Dashboard-Zugangskontrolle.** Das Dashboard läuft auf seinem eigenen Load Balancer, getrennt von der Event-Ingestion, und der Login erfolgt passwortlos per E-Mail-OTP, beschränkt auf die von Ihnen erlaubten E-Mail-Adressen/Domains. Eine IP-Quellbereichs-Allowlist am Load Balancer ist auf Anfrage verfügbar; da die automatische Zertifikatserneuerung den Load Balancer erreichen muss, kombiniert Exosphere die Einschränkung mit DNS-basierter Zertifikatsvalidierung, damit Erneuerungen weiterhin funktionieren. * **Zertifikate pro Cluster.** Jeder Ihrer Cluster erhält ein eigenes Client-Zertifikat. Wenn ein Cluster kompromittiert wird, kann dieses Zertifikat unabhängig widerrufen werden, ohne andere zu beeinträchtigen. *** ## Deployment-Zeitplan | Phase | Dauer | Ihr Einsatz | | -------------------------- | -------- | ----------------------------------------------------------------------------- | | **Cluster-Bereitstellung** | 1–2 Tage | Cluster bereitstellen und Exosphere Zugriff gewähren | | **Plattform-Einrichtung** | 1 Tag | Keiner; Exosphere installiert alle Infrastrukturkomponenten | | **Anwendungs-Deployment** | 1 Tag | Keiner; Exosphere deployt Server und Dashboard und erstellt API-Keys | | **Collector-Rollout** | 1–3 Tage | Collectors in Ihren Clustern installieren (mit Unterstützung durch Exosphere) | | **Produktions-Burn-in** | 1 Woche | Keiner; Exosphere überwacht und optimiert | Typische Gesamtdauer: **ca. 2 Wochen** vom Kickoff bis zur Produktionsreife. *** ## Support Bei Fragen oder Problemen wenden Sie sich an Exosphere unter `support@exosphere.host`. *** ## Nächste Schritte * [Getting Started](/de/agenteye/getting-started): Vollständige End-to-End-Anleitung * [Collector Installation](/de/agenteye/collector-installation): Collector installieren und konfigurieren * [Python SDK](/de/agenteye/python-sdk): Ihren Agenten-Code instrumentieren * [API Keys](/de/agenteye/api-keys): Zugriff und Berechtigungen verwalten * [Troubleshooting](/de/agenteye/troubleshooting): Häufige Probleme und Lösungen