Skip to content

RKE2 Self-Hosted Location Requirements#

A self-hosted Ametnes Data Service Location (ADSL) can be deployed on an RKE2 Kubernetes cluster running in your own environment. This page outlines the infrastructure requirements for a production-grade RKE2 cluster used as a data service location.

Virtual Machines#

The cluster requires three server nodes.

Requirement Specification
Operating System Ubuntu 24.04 LTS
CPU Minimum 8 vCPUs per node
RAM Minimum 16 GB per node
Storage Minimum 50 GB per node (SSD preferred)

Networking#

IP Addresses#

All three nodes must be on the same Layer-2 VLAN/subnet with static IPs (not DHCP-assigned) reachable internally. Outbound internet access is required for pulling container images.

Load Balancing#

The cluster uses Cilium in L2-aware mode for Kubernetes LoadBalancer service IPs (recommended). MetalLB in L2 mode is also supported if preferred. Both operate via ARP on the existing VLAN and do not require BGP or upstream router configuration.

IP pool required: A contiguous block of 10 dedicated IPs reserved for Kubernetes LoadBalancer services. These IPs must be outside the DHCP range of the VLAN.

Example: 10.0.0.100 – 10.0.0.109

The networking team must ensure:

  • The VLAN allows gratuitous ARP (standard on most switches)
  • Firewall rules permit inbound traffic to the reserved VIPs on required ports (or allow all ports for simplicity)

Maintenance#

Unattended Upgrades#

Automatic/unattended upgrades must be disabled on all nodes. All OS and security patches are applied manually during scheduled maintenance only.

Scheduled Maintenance#

Regular maintenance - such as OS, kernel, and security patches - is recommended on a scheduled basis (e.g., once a month). However this must be done with care to avoid data loss or service disruption. Instead of kubectl drain - which evicts all pods generically regardless of workload - maintenance uses Ametnes service lifecycle management. Each service has different lifecycle management requirements and the Ametnes platform handles the correct shutdown sequence for each, ensuring there is no data loss. The platform shuts down each service resource gracefully through its application-aware plugin (flushing connections, persisting state, and scaling workloads to zero cleanly) and restores them with full readiness verification after the node is back online.

Procedure#

  1. Stop all Ametnes service resources - Use the Ametnes Cloud console or API to send a STOP command to every service resource in the data service location. Each resource transitions through STOPPING → STOPPED as its plugin handles graceful shutdown.

  2. Rolling node maintenance - For each node, one at a time:

  3. Apply OS and kernel updates
  4. Reboot the node

  5. Verify the node rejoins the cluster and is healthy

  6. Start Ametnes service resources incrementally - As nodes come back online, use the Ametnes Cloud console or API to send a START command to service resources. Starting services incrementally ensures compatibility with any new OS or kernel patches applied during the maintenance cycle. Each resource transitions through STARTING → READY as the plugin restores the workload and verifies readiness.

All patches (including kernel updates) are applied exclusively during this maintenance window.

Agent Compatibility#

The Ametnes Cloud Agent and associated OSS tools are validated on Ubuntu 24.04 LTS before production use.

Prerequisites for the Ametnes Cloud Agent#

Once the RKE2 cluster meets the requirements above, see the Data Service Location guide for installing and configuring the Ametnes Cloud Agent on the cluster.