Redpanda’s rpk CLI is your primary interface for managing and interacting with a Redpanda cluster, treating it much like a Kafka cluster but with a few key differences and added conveniences.
Let’s see rpk in action. Imagine you’ve just spun up a single-node Redpanda cluster and want to check its status.
rpk cluster info
This command will output something like:
Cluster Name: redpanda-cluster
Cluster ID: a1b2c3d4-e5f6-7890-1234-abcdef123456
Node ID: 0
API Version: 3
Advertised Listeners: PLAINTEXT://127.0.0.1:9092,TLS:127.0.0.1:9093
This tells you the cluster’s name, its unique identifier, the ID of the node you’re connected to, the API version it’s speaking, and how clients can reach it.
rpk isn’t just for getting information; it’s your tool for everything from creating topics to managing ACLs and even performing administrative tasks like schema registration. The core idea is to provide a unified, intuitive command-line experience for Redpanda operations.
Here’s how you’d create a topic named my-new-topic with 3 partitions and a replication factor of 1 (since it’s a single-node cluster):
rpk topic create my-new-topic -p 3 -r 1
And to list all topics:
rpk topic list
This would show:
NAME PARTITIONS REPLICATION FACTOR STATUS
my-new-topic 3 1 OK
rpk also excels at interacting with Redpanda’s built-in schema registry. To register a new Avro schema for a topic:
rpk topic schema register my-new-topic --type avro --schema '{"type": "record", "name": "MyRecord", "fields": [{"name": "name", "type": "string"}]}'
This command registers the specified Avro schema, making it available for producers and consumers. You can then query it:
rpk topic schema get my-new-topic
The mental model for rpk revolves around resource types (cluster, topic, group, acl, schema) and actions you can perform on them. For instance, rpk topic is the command group for topic operations, and create, list, delete, describe are actions within that group.
Beyond basic operations, rpk allows you to inspect and manage cluster resources at a granular level. You can fetch partition leadership information, check consumer group offsets, and even issue administrative commands directly to the Redpanda brokers.
One aspect that often surprises users is how rpk handles configuration and connection. By default, it tries to connect to localhost:9092. However, you can easily override this using environment variables or command-line flags. For example, to connect to a cluster running on a different host:
rpk --brokers=my-redpanda-host:9092 cluster info
This flexibility is crucial for managing distributed deployments or when Redpanda isn’t running on the default local setup.
The next logical step after mastering basic operations is delving into performance tuning and troubleshooting, which often involves using rpk to inspect internal metrics and broker states.