Skip to main content
Version: 23.1

Kubernetes Cluster Requirements

This topic is a checklist with the prerequisites and system requirements for installing production Redpanda in a Kubernetes cluster using the Helm chart.

Operating system

  • Minimum required version of the Linux kernel: 3.10.0-514 or 4.18
  • Minimum version of RHEL/CentOS: 7.9
  • Minimum version of Ubuntu: 21.1

CPU and memory

  • A minimum of three physical worker nodes or virtual machines are required.
  • Two physical (not virtual) cores are required. Four physical cores are strongly recommended.
  • x86_64 (Westmere or newer) and AWS Graviton family processors are supported.
  • 2 GB or more of memory per core is required.

Kubernetes

Minimum required Kubernetes version: 1.21

Make sure to do the following:

  1. Install kubectl.
  2. Configure the kubeconfig file for your cluster.

Helm

Minimum required Helm version: 3.6.0

Install Helm.

Number of worker nodes

You must provision one worker node for each Redpanda broker that you plan to deploy in your Redpanda cluster. Each Pod replica that runs a Redpanda broker requires its own dedicated worker node for the following reasons:

  • Redpanda brokers are designed to have access to all resources, such as CPU and memory, on their host machine.
  • External clients access Redpanda brokers using the address of a worker node. See External networking.
note

The Helm chart configures podAntiAffinity rules to make sure that each Redpanda broker runs on its own worker node.

Storage volumes

Redpanda brokers must store their data on disk. As a result, each Pod that runs a Redpanda broker must have its own storage volume.

For production, follow these requirements and recommendations:

  • Mount an XFS or ext4 file system on any storage volumes that host the data directory of Redpanda (/var/lib/redpanda/data) or the Tiered Storage cache. XFS is highly recommended. NFS is not supported.
  • Use locally-attached NVMe devices. RAID-0 is required if you use multiple disks.
  • Use ephemeral cloud instance storage only in combination with Tiered Storage or for Tiered Storage cache. Without Tiered Storage, attached persistent volumes (for example, EBS).

To learn what volumes Redpanda recommends, see the storage best practices. To learn how to configure storage, see Configure storage.

Object 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)

External networking

For external access, each worker node in your cluster must have a static, externally accessible IP address to allow clients to connect to the NodePort Service and access the Redpanda broker. Redpanda uses the following default ports:

Node portPurpose
30081Schema registry
30082HTTP Proxy
31092Kafka API
31644Admin API

Minimum 10 GigE.

Redpanda recommends using NodePorts instead of Loadbalancers. See the external networking best practices.

Tuning

Before deploying Redpanda to production, each worker node that runs Redpanda must be tuned to optimize the Linux kernel for Redpanda processes.

See Tuning Kubernetes Worker Nodes for Production.

Sizing

For help sizing your Kubernetes cluster, see Sizing Guidelines.

Next steps

Review the best practices.

What do you like about this doc?




Optional: Share your email address if we can contact you about your feedback.

Let us know what we do well: