Edge Delta on Kubernetes

The setup process for deploying Edge Delta within a Kubernetes cluster natively leverages the Kubernetes APIs and other components to provide a seamless onboarding, and automated monitoring experience.

Many of the commonly used Kubernetes Services are supported by Edge Delta:

• Amazon EKS
• Azure AKS
• Google GKE
• OpenShift Enterprise Kubernetes
• Bare Metal Kubernetes

Kubernetes Requirements

The Edge Delta fleet uses eBPF to collect network metrics. Therefore, the following Kubernetes environment configuration is required for Kubernetes network metrics and eBPF to work:

• Linux kernel version 5.8 or later.
• Linux kernel built with the CONFIG_DEBUG_INFO_BTF=y and CONFIG_DEBUG_INFO_BTF_MODULES=y flags.

To check for the flag:

docker run -it --rm --privileged --pid=host ubuntu nsenter -t 1 -m -u -n -i sh -c 'cat /proc/config.gz | gunzip | grep CONFIG_DEBUG_INFO_BTF'

The output should show CONFIG_DEBUG_INFO_BTF=y and CONFIG_DEBUG_INFO_BTF_MODULES=y.

In the case of minikube, the agent can run on minikube with the Docker driver. Docker must be at least v26.0.0 (Docker Desktop v4.29.0) and it is started as follows:

minikube start --driver docker

Kubernetes Source

Once the Edge Delta fleet is running within a Kubernetes cluster, telemetry data (logs and metrics) generated by other pods in the cluster are automatically monitored and analyzed by the Edge Delta Fleet in real time. The Edge Delta Fleet is aware of the Kubernetes components of the cluster (pods, namespaces, deployments, etc.) natively by utilizing the Edge Delta Kubernetes source.

Version 0.1.70 and older agents use the v2 configuration’s Kubernetes source. See Agent Configuration for more information about agent and configuration versions.

Kubernetes Deployment Overview

There are a number of different ways to deploy an Edge Delta fleet in a Kubernetes environment: kubectl apply commands, using Helm, or via Terraform.You can also automate deployments with using a tool such as ArgoCD.

Automated Kubernetes Monitoring

Once Edge Delta is running within your Kubernetes environment, it automatically begins analyzing and monitoring telemetry data locally from the active pods within the cluster. The incoming data is enriched with detailed metadata from the environment and analyzed.

Without any custom configuration, Edge Delta will begin analyzing data, generating patterns, findings, and statistics, as well as baselining the behavior to provide automated Anomaly Detection with Machine Learning.

Insights, Statistics, Patterns, and Findings generated by Edge Delta are streamed in real time to streaming destination nodes (or Streaming Destinations for v0.1.70 and older agents). Additionally, these insights are exposed by default in the Edge Delta UI, with flexible filtering, aggregation, and other commonly used investigation tools.

Kubernetes Manifest

The Edge Delta fleet manifest contains the following sections:

• Namespace: Establishes the edgedelta namespace as the dedicated environment for all Edge Delta components, assisting in organization and isolation from other services in the cluster.
• ServiceAccount: Generates a service account named edgedelta for authentication purposes, which is utilized by the various Edge Delta components to securely interact with the Kubernetes cluster API.
• ClusterRole and ClusterRoleBinding: Configures the necessary permissions for the edgedelta service account, allowing it to access and manage specific Kubernetes resources crucial for Edge Delta’s operations. The defined roles include permissions to get, list, watch, create, update, patch, and delete resources such as namespaces, pods, events, nodes, services, daemonsets, deployments, StatefulSets, jobs, cronjobs, and leases.
• DaemonSet: Sets up a DaemonSet to deploy the Edge Delta Processor Agent on every node within the cluster, ensuring comprehensive coverage for data collection and processing. The agent is granted extensive system privileges to gather metrics and logs, with its configuration defined through environment variables. Host-level permissions (such as hostPID and hostNetwork) are incorporated to allow extensive system interaction, while volume mounts are utilized for persistent storage and system paths necessary for monitoring.
• Services: Defines two distinct Kubernetes services, ed-compactor-svc and ed-rollup-svc, which expose the Compactor Agent and rollup components, respectively. These services facilitate stable network communication to the corresponding back end processing units of Edge Delta, with designated ports for each service (9199 and 9200).
• StatefulSets: Creates two StatefulSets, edgedelta-compactor and edgedelta-rollup, which deploy the back end processing components for Edge Delta. The edgedelta-compactor processes log data, whereas the edgedelta-rollup aggregates metric data. Each StatefulSet specifies container images, resource requests, and limits, and mounts dedicated storage volumes for persistent data handling. Environment variables further configure the roles and behavior of these components, with particular emphasis on inter-component communication through service endpoints.

Related Content