Guideline / Tutorial for a Coroot comprehensive production deployment #487
-
Hi everyone, We’re planning a centralized Coroot deployment in a shared “observability” Kubernetes cluster (in AWS) that will serve multiple other Kubernetes clusters. The central cluster will host all main Coroot components, and each remote cluster (across various projects/environments) will run Coroot agents to push telemetry to the central instance. We do not use a service mesh; instead, we have a private NGINX Ingress controller to facilitate cross-cluster communication (traffic stays within AWS private networking). We want to enable all Coroot features – including full metrics (via eBPF), logs, distributed tracing, profiling, and database monitoring – with integrations for AWS RDS (PostgreSQL) and ElastiCache. Deployment is managed via GitOps (Flux), and we typically prefer defining HelmReleases for components. We’re open to using the Coroot Operator (especially if it simplifies things), but would like to understand best practices in a Flux + Helm context as well. Has anyone else done any similar setup and help providing guidance? Thanks!!! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
The recommended approach is to deploy Coroot in a centralized cluster using the operator. Then, deploy the operator in target clusters with |
Beta Was this translation helpful? Give feedback.
The recommended approach is to deploy Coroot in a centralized cluster using the operator. Then, deploy the operator in target clusters with
agentsOnly
mode enabled, which will deploy the node-agent and cluster-agent. Note that node-agents and the cluster-agent in each target cluster must have network connectivity to the collector in the centralized cluster.