Minimum and recommended Kubernetes specs
Hybrid Manager runs on Kubernetes and relies on it to provide a scalable, resilient platform for managing database services and platform components. Choosing appropriate Kubernetes cluster specifications is critical for ensuring reliable performance and capacity when running Hybrid Manager.
This guide provides minimum and recommended Kubernetes specs specifically for supporting Hybrid Manager and EDB-managed Postgres database services.
For background, see Kubernetes in Hybrid Manager.
Minimum supported Kubernetes version
Hybrid Manager requires a certified Kubernetes distribution (such as EKS, GKE, AKS, OpenShift, or upstream Kubernetes) that meets the following:
- Kubernetes version: Follow Hybrid Manager release notes for supported versions (typically N-1 or N-2 of current upstream).
- Control plane must support:
- RBAC
- NetworkPolicies (or equivalent)
- CSI storage drivers
- Ingress controller (ALB, Nginx, OpenShift Route, etc.)
- Support for PodSecurityStandards or equivalent security controls
Minimum node specs
| Node role | Minimum | Recommended |
|---|---|---|
| General node (Hybrid Manager UI, API services, operators) | 2 vCPU, 8 GiB RAM | 4 vCPU, 16 GiB RAM |
| Database node (managed Postgres StatefulSets) | 4 vCPU, 16 GiB RAM | 8 vCPU, 32 GiB RAM |
- Database workloads benefit from higher memory and faster CPU.
- Consider storage throughput and IOPS when sizing nodes — see Kubernetes storage best practices.
- Use multi-AZ node pools where supported for availability.
Recommended cluster sizing
| Cluster size | Minimum nodes | Recommended nodes |
|---|---|---|
| Small test/dev cluster | 3 nodes | 3 nodes (multi-AZ if possible) |
| Small production cluster | 3 nodes | 4-6 nodes (multi-AZ) |
| Medium production cluster | 6 nodes | 8-12 nodes (multi-AZ) |
| Large production cluster | 12+ nodes | Size based on workload demands |
Notes:
- Hybrid Manager runs multiple platform components (UI, API, Operators, backup agents, observability stack).
- Database Pods (StatefulSets) require dedicated capacity → avoid co-scheduling them on heavily loaded nodes.
- Plan for horizontal scaling — it is better to start with conservative sizing and add node capacity as needed.
Networking considerations
- Plan for cluster IP address space large enough to accommodate:
- Hybrid Manager services
- Database services
- Monitoring, logging components
- Any additional workloads you deploy
- Enable multi-AZ networking where supported (e.g. EKS VPC CNI, OpenShift SDN, GKE VPC-native).
- Apply NetworkPolicies to control traffic as needed — see Managing Kubernetes networking.
Storage considerations
- Use dedicated StorageClasses for database PersistentVolumeClaims (PVCs):
- Volume type: SSD-backed block storage (e.g. gp3, io2 on AWS; pd-ssd on GCP; Azure Premium Disk)
- VolumeBindingMode: WaitForFirstConsumer
- Filesystem: ext4 or xfs
- Plan for volume expansion → StorageClasses should support allowVolumeExpansion.
See detailed guidance in Kubernetes storage best practices.
Summary recommendations
| Component | Recommendation |
|---|---|
| Kubernetes version | As per Hybrid Manager release notes (certified Kubernetes distro) |
| Nodes | Multi-AZ, mixed node pools for DB vs. non-DB workloads |
| Node sizing | See table above; prioritize memory and IOPS for DB nodes |
| Networking | Multi-AZ support, NetworkPolicies in place |
| Storage | SSD-backed block storage, expansion-capable StorageClasses |
Related topics
Could this page be better? Report a problem or suggest an addition!