Client versions
Which Kafka client versions work against KubeMQ, the floor and why it is there, and the clients that have been run against it.
Any Kafka client built for Kafka 0.11 (2017) or later works. That covers every client release of the last several years; the floor matters only for very old applications and for libraries whose defaults still pretend to be old.
The floor, and why
KubeMQ stores record batches in the format Kafka introduced in 0.11 and serves the protocol from there:
| Request | Oldest version served | Why |
|---|---|---|
| Produce | v3 | the first version carrying the 0.11 record-batch format — the only format stored |
| Fetch | v4 | the first version that returns that format; an older consumer would be handed bytes it cannot decode |
| OffsetFetch | v2 | the first version that can report an error; older versions would turn an error into a silent success |
| ListOffsets | v0 | every version, from next v1.2.0 — see below |
| Everything else | v0 |
A client older than the floor negotiates, finds no common version, and fails at connect time rather than misbehaving later. The full per-request table is in Capabilities.
librdkafka 1.7 and older (Confluent's cp-kcat:7.6.1 image, and Python, Go and .NET clients
built on that release) ask for ListOffsets v0 when a consumer starts from the earliest or latest
offset. From next v1.2.0 that is served. On next v1.1.0 and earlier the client fails every
consume locally with Failed to query logical offset END: Required feature not supported by broker — no request reaches the server, so nothing appears in its log. Upgrade the client or the
server.
Sarama chooses its protocol from Config.Version, not by negotiation. Set it to your real
target, sarama.V2_8_0_0 or later is a safe choice, or an old default can select a request version
below the floor.
Consumer group protocol
The next-generation consumer group protocol (KIP-848, group.protocol=consumer) is not served.
Clients default to the classic protocol, which is fully supported; an application that opted in to
the new one must set group.protocol=classic.
Clients that have been run against KubeMQ
| Client | Version | How |
|---|---|---|
Java kafka-clients | 3.7.1 | the application simulator: admin, idempotent and transactional producers, 3-member groups, all four codecs, on a 3-node cluster with the leader killed mid-traffic |
confluent-kafka (Python) / librdkafka | 2.6.1 | the same simulator |
librdkafka (kcat) | 1.7.0, 1.8.2 | produce, consume and consumer groups |
| Kafka Connect, Kafka Streams | 3.9.1 | see Kafka Connect and Kafka Streams |
| franz-go, Sarama, segmentio/kafka-go, the Kafka CLI tools | current | the conformance suite, compared request by request against Apache Kafka |
A client not in the table is not assumed broken — the protocol surface above is what decides — but
run your own application once against a test cluster before cutting over. The simulator in the
server repository (tests/kafka-app-sim) is built for exactly that: it runs an ordinary application
against Apache Kafka first, then against KubeMQ, and checks loss, duplicates, ordering and
exactly-once in between.
Was this page helpful?
Schema Registry
Use Confluent Schema Registry with KubeMQ — serializers work unchanged, and the registry service itself runs against KubeMQ as its storage.
Capabilities
What the KubeMQ Kafka connector supports — every implemented Kafka API, from Produce/Fetch and consumer groups to transactions and share groups (preview).