EKS Kubernetes Agent FAQs

Availability: Generally available for EKS.

If you need additional assistance, contact Finout at [e-mail].

---

Does the Central Collector support horizontal scaling?

No. The Central Collector runs as a single replica by design, backed by a PersistentVolumeClaim. Based on load testing at scale, a single replica is sufficient for large clusters.

---

What happens to data if the Central Collector pod restarts or is rescheduled?

The agent is designed to survive restarts with minimal data loss:

• Rotated metric files persist on the PVC and survive pod restarts, rescheduling, and node failures. Once a file is rotated, it remains on disk until the uploader confirms delivery to S3.

• Node Collectors buffer and retry while the Central Collector is temporarily unavailable, so metrics continue to flow without manual intervention.

• In-flight data — the batch held in memory at the moment of a crash — may be lost. With a 30-second scrape interval, this is typically 1–2 scrape windows and is negligible for cost allocation purposes.

---

Is traffic between Node Collectors and the Central Collector availability-zone-aware?

No. Because the Central Collector runs as a single replica, there is no AZ topology awareness. Cross-AZ traffic between Node Collectors and the Central Collector may incur standard inter-AZ data transfer costs from your cloud provider.

---

Does the agent require any inbound network access or open ports?

No. The agent requires outbound HTTPS only — no inbound ports are opened. All communication originates from within the cluster.

---

How does the agent authenticate uploads to S3?

The agent fetches short-lived presigned URLs from app.finout.io and uses them to upload metric files directly to S3. Each presigned URL is scoped to a single upload operation and expires automatically — no static S3 credentials are stored in the cluster

---

How can I avoid NAT Gateway charges for metric uploads?

If your Kubernetes worker nodes are in private subnets and reach S3 via an AWS NAT Gateway, metric uploads may incur NAT Gateway data processing fees. To avoid this, configure an S3 Gateway VPC Endpoint in the VPC that hosts your cluster.

When configuring the endpoint:

• Endpoint type: Gateway Endpoint for S3 (com.amazonaws.<region>.s3)

• Route tables: Associate with the route tables used by your Kubernetes worker nodes

• Endpoint policy (if restrictive): Ensure it permits s3:PutObject to Finout's ingestion bucket

Contact Finout Support to obtain the Finout bucket details.

---

How do I uninstall the agent?

See the Install the Finout EKS Kubernetes Agent guide for uninstall instructions.

---

How do I migrate from an existing Kubernetes integration to the Kubernetes Agent?

Migration from an existing Kubernetes integration (Prometheus or Datadog) to the agent is handled by the Finout team — you don't need to manage the cutover yourself.

After the agent is installed successfully on all your clusters, the Finout team will stop your existing Prometheus/Datadog enrichment and replace it with the agent Cost Center, ensuring no overlap between the two data sources on the same cluster. Any overlap would cause duplicated metrics and compromised costs.

Do not stop the Finout Prometheus/Datadog integration until the Finout team confirms the migration has completed successfully.

Why do my costs look slightly different after migrating to the agent?

Minor differences are expected and normal. A few reasons:

• Scrape frequency and timing — the agent runs on its own schedule, independent of Prometheus/Datadog collection intervals

• Broader metric coverage — the agent scrapes all available metrics and labels by default, whereas a customer's existing monitoring stack may not expose all of them. This typically results in lower idle cost and more accurate allocation on the agent side.

• More accurate network cost allocation — the agent excludes network metrics for pods running with hostNetwork: true configuration, by default. Pods with this configuration share the node's network namespace, causing a report of full node-level traffic per pod — inflating their network costs. The agent corrects this automatically by filtering out these pods’ network metrics.

  • Customers migrating from the CronJob will see lower network costs for those workloads and a slight increase in idle — total cluster cost stays the same, the attribution is just more accurate.

  • Customers migrating from Datadog won't see this difference, as Datadog already excludes hostNetwork pods from network metrics on their end.

---

Can I use the Finout Kubernetes agent and the Prometheus CronJob in the same environment

Yes. You can run the agent on some clusters and the CronJob on others, for example the agent on dev EKS and the CronJob on prod EKS. Each cluster must be covered by only one integration. Please contact Finout Support to set up this combination.