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

Edge Delta Agents

A primary component of the Edge Delta deployment (in the context of Kubernetes) are the Edge Delta agents. The agents are an extremely lightweight, low-resource, Go-based process that run as a Daemonset in a Kubernetes cluster (1 pod per node).

Kubernetes Requirements

The Edge Delta agent uses eBPF to collect network metrics. Therefore, the following environment configurations are required for Kubernetes network and eBPF metrics to work:

• Linux kernel version 5.8 or later.
• Linux kernel built with the CONFIG_DEBUG_INFO_BTF=y flag.

To check for the flag, SSH into the node and examine the config, for example in minikube:

minikube sh
cat /proc/config.gz | gunzip | grep CONFIG_DEBUG_INFO_BTF

The output should show CONFIG_DEBUG_INFO_BTF=y.

In the case of minikube, the agent can run on minikube with the Docker driver. Docker must be at least v24.0.0 and it is started as follows:

minikube start --driver Docker

Edge Delta Kubernetes Input

Once the Edge Delta daemonset 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 agents in real time. The Edge Delta agents are aware of the Kubernetes components of the cluster (pods, namespaces, deployments, etc.) natively by utilizing the Edge Delta Kubernetes Input.

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

Edge Delta Kubernetes Deployment Overview

There are a number of different ways to deploy the Edge Delta service in a Kubernetes environment. The three most common approaches for deploying Edge Delta in Kubernetes are via direct kubectl apply commands, using Helm, or via Terraform.You can also automate deployments with using a tool such as ArgoCD.

Edge Delta Automated Kubernetes Monitoring

Once the Edge Delta service is running within your Kubernetes environment, it automatically begins analyzing and monitoring telemetry data locally from the active pods within the cluster using Edge and Stream Processing concepts. The incoming data is enriched with detailed metadata from the environment, and analyzed within the context of low level tags, as well as broader logical groups.

Without any custom configuration, or user-provided context of the environment, the Edge Delta service will begin analyzing the underlying data, generating patterns, findings, and statistics, as well as baselining the behavior to provide automated Anomaly Detection and Machine Learning capabilities.

Insights, Statistics, Patterns, and Findings generated by Edge Delta are streamed in real time to streaming output nodes (or Streaming Destinations for v0.1.70 and older agents), which typically push to the existing monitoring platforms you are used to using (i.e. Elastic, Splunk, Datadog, Sumo Logic, New Relic, etc.). Additionally, these insights are exposed by default in the Edge Delta UI, with flexible filtering, aggregation, and other commonly used investigation tools.

Edge Delta Agent Kubernetes Manifest

The Edge Delta agent 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 edgedelta-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 and rollup components, respectively. These services facilitate stable network communication to the corresponding backend 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 backend 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