System Requirements Guide

Overview

This document specifies the hardware, operating system, and networking requirements for deploying the AgileTV CDN Manager (ESB3027). Requirements vary based on deployment type and node role within the cluster.

Cluster Sizing

Production Deployments

Production deployments require a minimum of three nodes to achieve high availability. The cluster architecture employs distinct node roles:

Server nodes can be deployed in either Control Plane Only or Combined role configurations. The choice depends on your deployment requirements:

• Control Plane Only: Dedicated control plane nodes with lower resource requirements; requires separate Agent nodes for workloads
• Combined: Server nodes run both control plane and workloads; minimum 3 nodes required for HA

Why Use Control Plane Only Nodes?

Dedicated Control Plane Only nodes provide several benefits for larger deployments:

• Resource Isolation: Control plane components (etcd, API server, scheduler) run on dedicated hardware without competing with application workloads for CPU and memory
• Stability: Application workload spikes or misbehaving pods cannot impact control plane performance
• Security: Smaller attack surface on control plane nodes; fewer containers and services running
• Predictable Performance: Control plane responsiveness remains consistent regardless of application load
• Flexible Sizing: Control Plane Only nodes can use lower-specification hardware (2 cores, 4 GiB) since they don’t run application workloads

For most small to medium deployments, Combined role servers are simpler and more cost-effective. Control Plane Only nodes are recommended for larger deployments with significant workload requirements or where control plane stability is critical.

High Availability Considerations

Production deployments require 3 nodes running control plane (etcd) and 3 nodes capable of running workloads. These can be the same nodes (Combined role) or separate nodes (CP-Only + Agent).

Node Role Combinations:

Any combination works as long as you have 3 control plane nodes and 3 workload-capable nodes.

Note: Regardless of the deployment configuration, a minimum of 3 nodes capable of running workloads is required for production deployments. This ensures both high availability and sufficient capacity for application pods.

For detailed fault tolerance information and data replication strategies, see the Architecture Guide.

Hardware Requirements

Single-Node Lab Deployment

Lab deployments are intended for acceptance testing, demonstrations, and development only. These configurations are not suitable for production workloads.

Production Cluster - Server Node (Control Plane Only)

Server nodes dedicated to control plane functions have modest resource requirements:

These nodes run only control plane components and require separate Agent nodes to run application workloads.

Production Cluster - Server Node (Control Plane + Workloads)

Combined role nodes require resources for both control plane and application workloads:

Production Cluster - Agent Node

Agent nodes execute application workloads and require the following resources:

Swap

Swap may stay on: deploy leaves it as it is, and the cluster runs with or without it. Size memory so that swap is not used in normal operation. Swap in use is a sign of memory pressure.

Storage Notes

* Disk Space: All disk space values must be available in the /var/lib/longhorn partition. It is recommended that /var/lib/longhorn be a separate partition on a fast SSD for optimal performance, though SSD is not strictly required.

Longhorn Capacity: Longhorn storage requires an additional 30% capacity headroom for internal operations and scaling. If less than 30% of the total partition capacity is available, Longhorn may mark volumes as “full” and prevent further writes. Plan disk capacity accordingly.

Storage Performance

For optimal performance, the following storage characteristics are recommended:

• Disk Type: SSD or NVMe storage for Longhorn volumes
• Filesystem: XFS or ext4 with default mount options
• Partition Layout: Dedicated /var/lib/longhorn partition for persistent storage

Virtual machines and bare-metal hardware are both supported. Nested virtualization (running multiple nodes under a single hypervisor) may impact performance and is not recommended for production deployments.

Operating System Requirements

Supported Operating Systems

The CDN Manager supports Red Hat Enterprise Linux and compatible distributions:

Compatible Clones

The following RHEL-compatible distributions are supported at release 9.4 or later:

• Oracle Linux 9
• AlmaLinux 9
• Rocky Linux 9

A minimal installation is enough. Keep firewalld and NetworkManager installed and running: deploy configures the firewall and network through them.

Air-Gapped Deployments

Important: deploy installs a few packages from the operating system’s repositories on every node. For air-gapped deployments (no internet access), make the OS installation media available to dnf on all nodes first. See Air-Gapped Installation.

Oracle Linux UEK Kernel

On Oracle Linux 9 running Unbreakable Enterprise Kernel 8 (UEK 8), install the netfilter kernel modules that K3s and Longhorn need on every node before running the installer:

dnf install kernel-uek-modules-extra-netfilter-$(uname -r)

The package comes from Oracle’s UEK 8 repository, ol9_UEKR8. If dnf cannot find it, check that the repository is enabled, and enable it if not:

dnf repolist
dnf config-manager --enable ol9_UEKR8

Without internet access, that repository is not available. Make the package available to dnf from a local repository first, as for the other packages in Air-Gapped Installation, and check that dnf finds it:

dnf -q repoquery kernel-uek-modules-extra-netfilter-$(uname -r)

SELinux

SELinux is supported in any mode, “Enforcing” included. The installation process installs the SELinux policy for the cluster automatically.

Networking Requirements

Network Interface

Every cluster node needs an IPv4 default route on its public interface, the interface that clients reach it on. The route does not need to lead to the internet: on an isolated network, use your site’s router or any gateway address on that subnet. deploy uses this route to find each machine’s public interface and address, and stops with [ACD-NO-DEFAULT-ROUTE] without one.

A second interface on a backplane network, separate from the public network, is optional but recommended for production. All node-to-node traffic then uses the backplane, and every node must be reachable on it. Other hosts may share it. See Configuring Segregated Networks.

Port Requirements

The cluster requires the following network connectivity:

By default, deploy configures the host firewall for the inter-node and external ports itself. The host firewall does not filter the Kafka ports: restrict them to your CDN Directors on your network’s own firewall. See Kafka Ports. The same applies to the two ingress NodePorts, chosen at installation: see Ingress NodePorts.

Important: Complete port requirements, network ranges, and firewall configuration procedures are provided in the Networking Guide. Do not expose VictoriaMetrics (8428, 8429), Grafana (3000), or PostgreSQL (5432) directly—access these services only through the secure HTTPS ingress (port 443).

Resource Planning

Calculating Cluster Capacity

When planning cluster capacity, consider the following factors:

1. Base Overhead: Kubernetes system components consume approximately 1-2 cores and 2-4 GiB memory per node
2. Application Workloads: Refer to individual component resource requirements in the Architecture Guide
3. Headroom: Maintain 20-30% resource headroom for workload spikes and automatic scaling

Scaling Considerations

The CDN Manager supports horizontal scaling for most components. The Horizontal Pod Autoscaler (HPA) can automatically adjust replica counts based on resource utilization. Detailed scaling guidance is available in the Architecture Guide.

Example Production Deployment

A minimal production deployment with 3 server nodes (combined role) and 2 agent nodes would require:

This configuration provides:

• High availability (survives loss of 1 server node)
• Capacity for application workloads across all nodes
• Headroom for horizontal scaling

Next Steps

After verifying system requirements:

1. Review the Installation Guide for deployment procedures
2. Consult the Networking Guide for firewall configuration
3. Examine the Architecture Guide for component resource requirements