This page describes the resource requirements, compatibility with different Kubernetes-based software, Cluster Agent distribution, licensing, and performance specifications.

Hardware Requirements

The default requirement for the hardware is as following:

  • CPU: 1250m
  • Memory: 300Mi

For every 100 pods, the memory requirement increases by 50Mi and CPU requirement increases by 100m.

For Example, If 500 pods are instrumented through the Cluster Agent, you require 550Mi (300Mi + 250Mi) memory limit and 1750m (1250m+500m) CPU limit.

These values are applicable when you use Cluster Agent with or without auto-instrumentation. 

In a large cluster environment that requires multiple Cluster Agents to monitor a single cluster, you can use the Target Allocator to auto-scale the Cluster Agent replicas or configure the number of replicas based on your requirements. For example, if there are 10,000 pods in your cluster, and you want to monitor 5000 pods per Cluster Agent replica, you will need two replicas with 6250m CPU and 2800Mi memory. However, with auto-scaling, the replicas are automatically created with a specific profile. Currently, the Default profile is supported. Therefore, when you specify the profile as Default, the replicas are created with 1550mi memory and 3750m CPU to monitor 2500 pods.

Software Requirements

The Cluster Agent is designed to run on Linux and deployed using the Splunk AppDynamics Operator.

The Cluster Agent requires:

  • Splunk AppDynamics On-Premises Controller >= 20.3.0.
  • Kubernetes versions >=1.19, with the Kubernetes metrics-server deployed and enabled on the cluster. 
  • A cluster that you can access and monitor.

  • Sufficient Server Visibility licenses. The Cluster Agent consumes one Server Visibility license. See License Management.

  • Access to Docker Hub or Red Hat Container Registry to pull the Cluster Agent Operator and Cluster Agent images, or access to an internal repository where these images are maintained. See Install the Cluster Agent.

If you deploy the Cluster Agent to monitor your Kubernetes Cluster, it does not monitor worker nodes. To monitor worker nodes, you must install the Machine Agent which consumes additional Server Visibility licenses (one Machine Agent per node). See Install Infrastructure Visibility with the Kubernetes CLI

The Cluster Agent is compatible with these cloud platforms:

Cloud PlatformVersion
Rancher Kubernetes Engine (RKE)
  • 1.2.1 with Kubernetes 1.19.3
  • 1.3.1 with kubernetes 1.21.5
  • 1.3.9 with kubernetes 1.22
  • 1.3.12 with Kubernetes 1.23.7
  • 1.3.14 with Kubernetes 1.24.4
  • 1.4.1 with Kubernetes 1.24.8
  • 1.4.6  with Kubernetes 1.26.4
  • 1.4.10 with Kubernetes 1.26.8
  • 1.5.3 with Kubernetes 1.27.8 
  • 1.5.10 with Kubernetes 1.28.10
Red Hat Enterprise Linux (RHEL)8.x and 9.x
Red Hat OpenShift

Azure: 4.6, 4.7, 4.8, 4.9, 4.10, 4.11, 4.12, 4.13, 4.14, and 4.15

AWS: 4.11, 4.12, and 4.13

The metrics-server is not shipped with OpenShift, you must deploy it separately. The CRI-O container runtime is supported on >=4.2.7.

RKE Government (RKE2)     1.26, 1.27, 1.28, 1.29 and 1.30
Kubernetes1.19, 1.20, 1.21, 1.22, 1.23, 1.24, 1.25, 1.26, 1.28, 1.29, and 1.30 with the Kubernetes metrics-server deployed
Amazon EKS
  • AMD: 1.19, 1.20, 1.21, 1.22, 1.23, 1.24, and 1.25, 1.26, 1.27, 1.28, 1.29, and 1.30 with the Kubernetes metrics-server deployed

  • ARM: 1.27, 1.28, 1.29, and 1.30 with the Kubernetes metrics-server deployed

    Auto-instrumentation is not supported on ARM platform.

     

Azure AKS 1.19, 1.20, 1.21, 1.22, 1.23, 1.24, 1.25, 1.26, 1.27, 1.29, and 1.30  with the Kubernetes metrics-server deployed
Google GKE 1.19, 1.20, 1.21, 1.22, 1.23, 1.24, 1.25, 1.26, 1.27, 1.28, 1.29 and 1.30
kubectl>=1.19
Tanzu Kubernetes Grid Integrated Edition (TKGI)1.14.4 1.16, 1.17, 1.18 and 1.19

Installing Splunk AppDynamics On-Premises to test or evaluate involves verifying system requirements, preparing the host, and then installing the Controller. See Install the Controller Using the CLI.

Cluster Agent Distribution

You can download the Cluster Agent from the Download Portal  as a zip archive. The archive also contains distribution-specific configuration files for the deployment.

Licensing

The Cluster Agent requires a Server Visibility license. To get started, see Enable Server Visibility. If you already have a Server Visibility license, see Install the Cluster Agent for installing Cluster Agent on a Kubernetes cluster.

Cluster Agent Performance Certification

 

Cluster Agent VersionPerformance Certification
<=20.10

You can monitor the certified stable limit of 750 pods and 1500 containers

>=20.11
  • Cluster Agent Vertical Scaling:
    This is the certified stable limit:
    If you run one container per pod then you can monitor 2250 pods and 2250 containers.
    If you run two containers per pod, then you can monitor 1500 pods and 3000 containers.

Cluster Agent and Pod Limits

You can configure the number of Cluster Agents based on the overall controller capacity. To configure the limit, see the sim.cluster.agent.limit description under Controller Settings for the Cluster Agent. 

You must specify a unique name for each Cluster Agent that reports to a specific Controller. To specify the name, use the appName parameter during installation. See Configure the Cluster Agent.

If your Cluster has more pods than can be monitored, the Cluster Agent ensures that the group of pods being monitored remains the same over time. If any of the reported pods are terminated in the future, then the Cluster Agent replaces the terminated pods with previously unreported pods and starts monitoring the newly included pods.
The total pods metric displayed on the Pods List page reflects only the number of pods up to the configured limit. See the sim.cluster.pod.limit description under Controller Settings for the Cluster Agent.