Sensor Collector System Requirements for Kubernetes

To ensure proper operation of the Sensor Collector, your system must meet the following specifications:

Kubernetes Cluster

Minimum Versions

Kubernetes 1.31, 1.32 or 1.33, helm version 3

Storage

For multiple nodes

For production High Availability, the StorageClass used by Sensor Collector must be network-attached.

Confirm that the storage class you will use meets this set of attributes:

For single node

If High Availability is not required, any storage class will be acceptable.

LoadBalancer Service

For multiple nodes

When running in production HA mode, the service.type: LoadBalancer will be used because it provides a stable external VIP for Sensor Agent connections. This VIP survives node failures (the LB health-checks and routes to healthy nodes).

To use service.type: LoadBalancer, the K8s cluster must have a LoadBalancer provider of your choice that allocates external IPs for type: LoadBalancer Services. For example:

For single node

The Sensor Collector Helm chart defaults to service.type: NodePort, which works on every K8s cluster with zero additional infrastructure. With NodePort, a Sensor Agent connects to a specific node IP and that if that node fails, the Sensor Agent loses connectivity until the node recovers.

Node Failure Remediation

For multiple nodes

To achieve high availability with StatefulSet workloads, your Kubernetes cluster must have node failure remediation in place. When a node fails, StatefulSet pods enter a Terminating state that cannot complete without kubelet confirmation from the dead node. Kubernetes will not create a replacement pod until the old one is removed, leaving the workload unavailable indefinitely.

For on-premises or bare-metal clusters, you must configure an automated remediation mechanism such as Cluster API MachineHealthCheck, Rancher's node health management, or a custom controller that applies the node.kubernetes.io/out-of-service taint to failed nodes. Without one of these mechanisms, recovery from node failures requires manual intervention and cannot be considered highly available.

For single node

When a node fails, it will need to be manually recovered.

Resource Consumption per Node

Disk Space: 100 GB
CPU: 4 cores
RAM: 2 GB

Network Services

The following host services are not strictly required but are recommended for reliable operation:

DNS resolver — Required if endpoints are configured using FQDNs to connect to PCA Analytics, OCSP servers, or monitored network devices. If DNSSEC validation is enabled in the.env configuration file (RR_DNSSEC_ENABLE=true), Sensor Collector runs a local Unbound resolver that performs cryptographic validation of DNS responses. In VPN or corporate network environments, explicitly configure upstream nameservers via RR_DNSSEC_NAMESERVERS since containers cannot automatically detect host VPN DNS settings. Without DNSSEC enabled, the container uses standard DNS resolution from the host machine's /etc/resolv.conf.

NTP client — Sensor Collector timestamps all collected metrics using the container's system clock, which inherits from the host. Clock accuracy affects the validity of time-series data and correlation with other data sources. Use any standard NTP client on the host (chrony recommended).

HTTP/HTTPS proxy — In environments without direct internet access, pass proxy settings to the container via the .env configuration file with options: HTTP_PROXY, HTTPS_PROXY, NO_PROXY. The proxy is used for outbound connections to PCA Analytics APIs and certificate validation endpoints (OCSP/CRL).

Firewall Rules

If a firewall is active on the host or in the network path, ensure the following traffic is permitted: