Kubernetes architecture of the CXDOT Collector

The CXDOT Collector is a single container image that contains the cxdot-collector binary. When you install the CXDOT Collector in a Kubernetes cluster, the CXDOT Collector deploys several components that work in tandem to collect telemetry data and send that data to Palo Alto Networks Cortex XCOR. The CXDOT Collector deploys these components to collect telemetry data from your Kubernetes workloads:

• The node collector is a DaemonSet with one Pod on each eligible node.
• The cluster collector is a Deployment with one or more worker Pods.
• The API server provides cluster-wide services that support the node collector and cluster collector.

​

Node collector

The node collector is a DaemonSet with one Pod on each eligible node. It uses push-based collection when it listens for HTTP and UDP requests from application Pods on the same node. It uses pull-based collection when it queries Pods on the same node to collect data from infrastructure services, such as MySQL. The node collector also gathers information about the node itself through the kubelet API and through the container runtime. After it collects telemetry data, the node collector sends that data to Cortex XCOR through the Cortex XCOR OTLP Ingestion API.

​

Cluster collector

The cluster collector is a Deployment with one or more worker Pods. It handles cluster-wide collection tasks, like running the OpenTelemetry k8scluster receiver to gather data from the Kubernetes API. It also collects telemetry data from managed services that are accessible only from within your cloud environment. By default, the cluster collector deploys two replicas. You can change this behavior by setting the value of clusterCollector.replicas in your Helm values file. After it collects telemetry data, the cluster collector sends that data to Cortex XCOR through the Cortex XCOR OTLP Ingestion API.

​

API server

The CXDOT API server provides cluster-wide services that support the node collector and cluster collector. Its primary function is to cache the state of Kubernetes resources in your cluster, which helps determine which attributes to add to the telemetry data collected by the node collector and cluster collector. The API server does this by using watch streams to keep the cache current and by responding to queries from the node collector and cluster collector. The CXDOT API server also hosts a mutating admission controller webhook that, when enabled, returns a set of mutations to apply to new Pods before their creation. These mutations inject information into Pods for use by instrumentation SDKs.