Docs Self-Managed Deploy Kubernetes Requirements and Recommendations This is documentation for Self-Managed v23.3, which is no longer supported. To view the latest available version of the docs, see v24.3. Kubernetes Cluster Requirements and Recommendations This topic provides the requirements and recommendations for provisioning Kubernetes clusters and worker nodes for running Redpanda in production. Operating system Minimum version required of RHEL/CentOS: 8. Recommended: 9+ Minimum version required of Ubuntu: 20.04 LTS. Recommended: 22.04+ Recommendation: Linux kernel 4.19 or later for better performance. Kubernetes version Minimum required Kubernetes version: 1.21 Make sure to do the following: Install kubectl. Configure the kubeconfig file for your cluster. Helm version Minimum required Helm version: 3.10.0 Install Helm. Number of worker nodes Provision one physical node or virtual machine (VM) for each Redpanda broker that you plan to deploy in your Redpanda cluster. Each Redpanda broker requires its own dedicated worker node for the following reasons: Resource isolation: Redpanda brokers are designed to make full use of available system resources, including CPU and memory. By dedicating a worker node to each broker, you ensure that these resources aren’t shared with other applications or processes, avoiding potential performance bottlenecks or contention. External networking: External clients should connect directly to the broker that owns the partition they’re interested in. This means that each broker must be individually addressable. As clients must connect to the specific broker that is the leader of the partition, they need a mechanism to directly address each broker in the cluster. Assigning each broker to its own dedicated worker node makes this direct addressing feasible, since each worker node will have a unique address. See External networking. Fault tolerance: Ensuring each broker operates on a separate node enhances fault tolerance. If one node experiences issues, it won’t directly impact the other brokers. The Redpanda Helm chart configures podAntiAffinity rules to make sure that each Redpanda broker runs on its own worker node. Recommendations: Deploy at least three Pod replicas. CPU and memory Requirements: Two physical, not virtual, cores for each worker node. x86_64 (Westmere or newer) and AWS Graviton family processors are supported. 2 GB or more of memory per core. 4 MB of memory for each topic partition replica. You can enforce this requirement in the tunable topic_memory_per_partition property. Recommendations: Four physical cores for each worker node are strongly recommended. Set resource requests and limits for memory and CPU. Storage Requirements: An XFS or ext4 file system. The Redpanda data directory (/var/lib/redpanda/data) and the Tiered Storage cache must be mounted on an XFS or ext4 file system. For information about supported volume types for different data in Redpanda, see Supported Volume Types for Data in Redpanda. Avoid using NFS (Network File System) for the Redpanda data directory or the Tiered Storage cache. A default StorageClass that can provision PersistentVolumes with at least 20Gi of storage. Recommendations: Use an XFS file system for its enhanced performance with Redpanda workloads. For setups with multiple disks, use a RAID-0 (striped) array. It boosts speed but lacks redundancy. A disk failure can lead to data loss. Use local PersistentVolumes backed by NVMe disks. Security Recommendations: If you’re using a cloud platform, use IAM roles to restrict access to resources in your cluster. Secure your Redpanda cluster with TLS encryption and SASL authentication. External networking For external access, each worker node in your cluster must have a static, externally accessible IP address. Minimum 10 GigE (10 Gigabit Ethernet) connection to ensure: High data throughput Reduced data transfer latency Scalability for increased network traffic Recommendations: Use a NodePort Service for external access. Tuning Before deploying Redpanda to production, each worker node that runs Redpanda must be tuned to optimize the Linux kernel for Redpanda processes. See Tune Kubernetes Worker Nodes for Production. Object storage providers for Tiered Storage Redpanda supports the following storage providers for Tiered Storage: Amazon Simple Storage Service (S3) Google Cloud Storage (GCS), using the Google Cloud Platform S3 API Azure Blob Storage (ABS) Cloud instance types Recommendations: Use a cloud instance type that supports locally attached NVMe devices with an XFS file system. NVMe devices offer high I/O operations per second (IOPS) and minimal latency, while XFS offers enhanced performance with Redpanda workloads. Amazon EKS defaults to the ext4 file system. Use XFS instead where possible. General purpose: General-purpose instances provide a balance of compute, memory, and networking resources, and they can be used for a variety of diverse workloads. M5d M5ad M5dn M6gd M7gd Memory optimized: Memory-optimized instances are designed to deliver fast performance for workloads that process large data sets in memory. R5ad R5d R5dn R6gd R6id R6idn R7gd X2gd X2idn X2iedn z1d Storage optimized: Storage-optimized instances are designed for workloads that require high, sequential read and write access to very large data sets on local storage. They are optimized to deliver tens of thousands of low-latency, random IOPS to applications. I3 I3en Compute optimized: Compute-optimized instances deliver cost-effective high performance at a low price per compute ratio for running advanced compute-intensive workloads. C5d C5ad Azure AKS often defaults to the ext4 file system. Use XFS instead where possible. Memory optimized: Memory-optimized VM sizes offer a high memory-to-CPU ratio. Ebsv5 series (NVMe) Ebdsv5 series (NVMe) Storage optimized: Storage-optimized virtual machine (VM) sizes offer high disk throughput and IO. Lsv2 series Lsv3 series Lasv3 series Google GKE often defaults to the ext4 file system. Use XFS instead where possible. General purpose: The general-purpose machine family has the best price-performance with the most flexible vCPU to memory ratios, and provides features that target most standard and cloud-native workloads. C3 machine series with local SSD N2 machine series N2D machine series Memory optimized: The memory-optimized machine family provides the most compute and memory resources of any Compute Engine machine family offering. They are ideal for workloads that require higher memory-to-vCPU ratios than the high-memory machine types in the general-purpose N1 machine series. M3 machine series Compute optimized: Compute-optimized VM instances are ideal for compute-intensive and high-performance computing (HPC) workloads. C2D machine series C2 machine series Next steps Deploy Redpanda for Production in Kubernetes. Suggested reading Redpanda Helm Specification Redpanda CRD Reference Sizing Guidelines Resources for Kubernetes managed services: GKE EKS AKS Storage optimized virtual machine sizes About local SSDs for GKE Provision ephemeral storage with local SSDs Instance store volumes Choosing an Amazon EC2 instance type EKS Persistent Volumes for Instance Store AKS storage Using NVMe instances in Azure Kubernetes Service Suggested labs Set Up GitOps for the Redpanda Helm ChartSearch all labs Back to top × Simple online edits For simple changes, such as fixing a typo, you can edit the content directly on GitHub. Edit on GitHub Or, open an issue to let us know about something that you want us to change. Open an issue Contribution guide For extensive content updates, or if you prefer to work locally, read our contribution guide . Was this helpful? thumb_up thumb_down group Ask in the community mail Share your feedback group_add Make a contribution Deployment Workflow Tune Worker Nodes