Array APV vs MetalLB

Array APV is an application delivery controller series for managing application availability, scalability, performance, security, and traffic. It balances server traffic across Layers 2, 3, 4, and 7, with health checks, persistence, clustering, and failover. Administrators can configure Layer 7 policies in the WebUI or CLI and combine them for customized traffic management. APV includes SSL/TLS acceleration and offloading, connection multiplexing, caching, and compression, along with certificate and key management. The x850 datasheet describes WebWall web application security and DDoS protection. Listed integrations include OpenStack Load Balancing-as-a-Service, VMware Cloud Orchestrator, and Microsoft System Center standards. Deployment options include physical or virtual appliances, hyper-converged infrastructure, and cloud platforms; vAPV documentation names VMware ESXi, Hyper-V, KVM, Citrix XenServer, Nutanix, AWS, Azure, and Google Cloud Platform. Management options include secure CLI, WebUI, SSH remote management, role-based administration, and real-time monitoring. Array identifies banking, healthcare, manufacturing, government, education, and service providers among the sectors it serves. Pricing is on request.

MetalLB provides network load balancing for Kubernetes clusters that do not run on a cloud provider. It assigns service IP addresses from operator-configured pools and announces them through ARP, NDP, or BGP, depending on the chosen mode. In layer 2 mode, one cluster machine announces an address using ARP for IPv4 or NDP for IPv6. In BGP mode, cluster machines peer with nearby routers, which can distribute traffic across multiple nodes. The recommended FRR-K8s mode supports BFD, IPv6, and merging additional FRR configuration. MetalLB is open source, with no paid plans listed. Installation options include Kubernetes manifests, Kustomize, Helm, and an Operator on OperatorHub. After installation it remains idle until configured with resources such as an IPAddressPool in its deployment namespace. Requirements include Kubernetes 1.13.0 or later, a compatible cluster network, and IPv4 addresses. The project lists AWS, Azure, DigitalOcean, and Google Cloud as unsupported and says it is generally incompatible with cloud providers. MetalLB describes itself as a beta project and cautions that its configuration format may change incompatibly as development continues.