Applications processing a continuing stream of events need somewhere to retain messages and let consumers read them at their own pace. Redpanda provides that streaming platform with a Kafka-compatible API, making it an option for workloads using Kafka clients. Compatibility still needs checking against the actual client features and operations involved. On Kubernetes, teams can use its broker chart or operator-based deployment, with storage, broker placement and client-visible network addresses central to a workable design.
Chart ownership
Redpanda publishes charts through charts.redpanda.com. Its production deployment guide distinguishes deploying the broker chart directly from installing the Redpanda Operator and declaring a Redpanda custom resource. Decide which controller owns changes; the operator and application charts are separate artifacts. The guide also documents namespace and cluster scopes for the operator.
Before adoption
Validate storage performance, broker placement, disk capacity and client-visible addresses. Configure authentication, TLS and certificate renewal before exposing listeners. Check the license requirements of the features you intend to use. Test broker failure and recovery with representative traffic, including consumer lag. When changing an existing installation, preserve persistent volumes and review chart migration guidance; reinstalling a release can reuse old data and configuration rather than create an empty cluster.
Sources & further reading
Spotted something that needs another look?
Help improve this page →