Capabilities
What the KubeMQ Kafka connector supports — every implemented Kafka API, from Produce/Fetch and consumer groups to transactions and share groups (preview).
This reference lists every Kafka API key the KubeMQ Kafka connector advertises, the version range it accepts, and how complete that support is. ✅ Full means "point a stock Kafka client at KubeMQ; it works." 🟡 Partial states the exact scope — read it before relying on the capability. 🔵 Preview means the wire protocol is implemented and advertised, but the multi-client conformance matrix hasn't run yet — it is not a GA guarantee.
Every key's advertised [min, max] version window comes from one source table inside the
connector that both the ApiVersions(18) response and the per-request bounds check read, so
the two can never drift apart. A request whose version falls outside a key's window is
answered UNSUPPORTED_VERSION, encoded at
that key's max version, so the client renegotiates instead of decoding garbage.
Produce, fetch, and metadata
| Key | API | Versions | Status | Notes |
|---|---|---|---|---|
| 0 | Produce | 3–9 | ✅ Full | RecordBatch v2 only; acks 0/1/all; strict per-partition ordering |
| 1 | Fetch | 4–12 | ✅ Full | Long-poll (fetch.max.wait.ms); serves RecordBatch v2 |
| 2 | ListOffsets | 1–7 | ✅ Full | earliest/latest/by-timestamp; earliest tracks the live retention floor |
| 3 | Metadata | 0–13 | ✅ Full | v13 carries a deterministic TopicID (KIP-516); Fetch deliberately stays name-based (v12), not UUID-keyed |
| 23 | OffsetForLeaderEpoch | 0–4 | ✅ Full | Real KIP-320 leader-epoch fencing for log-truncation detection on consumer resume |
Consumer groups (classic protocol)
| Key | API | Versions | Status | Notes |
|---|---|---|---|---|
| 10 | FindCoordinator | 0–3 | ✅ Full | scalar SELF shape only |
| 11 | JoinGroup | 0–5 | ✅ Full | includes the static-membership InstanceID field (v5+) |
| 14 | SyncGroup | 0–3 | ✅ Full | |
| 12 | Heartbeat | 0–4 | ✅ Full | |
| 13 | LeaveGroup | 0–4 | ✅ Full | single- and batch-member leave shapes |
| 15 | DescribeGroups | 0–5 | ✅ Full | authz-gated; a denied group never leaks membership |
| 16 | ListGroups | 0–4 | ✅ Full | |
| 42 | DeleteGroups | 0–2 | ✅ Full | |
| 8 | OffsetCommit | 0–8 | ✅ Full | durable, per-group, leader-linearized |
| 9 | OffsetFetch | 2–7 | ✅ Full | |
| 47 | OffsetDelete | 0–0 | ✅ Full |
Static membership (KIP-345) is Full. A consumer that sets group.instance.id joins as a
static member: a static rejoin within the session timeout skips a rebalance entirely, and a
second connection presenting the same instance.id — a displaced or duplicate instance —
is fenced with FENCED_INSTANCE_ID(82)
across Join/Sync/Heartbeat/OffsetCommit/Leave.
There is no separate API key for KIP-848's next-generation consumer-group protocol — see Not supported.
Handshake and authentication
| Key | API | Versions | Status | Notes |
|---|---|---|---|---|
| 18 | ApiVersions | 0–3 | ✅ Full | A request above v3 is answered at v0 with UNSUPPORTED_VERSION (KIP-511) |
| 17 | SASLHandshake | 0–1 | ✅ Full | negotiates PLAIN vs. the modern separate-authenticate flow |
| 36 | SASLAuthenticate | 0–2 | ✅ Full | carries PLAIN, SCRAM-SHA-256/512, and OAUTHBEARER (TLS listener only) |
Admin
| Key | API | Versions | Status | Notes |
|---|---|---|---|---|
| 19 | CreateTopics | 0–7 | ✅ Full | auto-create on Metadata/Produce also applies |
| 20 | DeleteTopics | 0–6 | ✅ Full | |
| 37 | CreatePartitions | 0–3 | 🟡 Partial | increase-only — same-count, decrease, or over the 256-partition cap all reject INVALID_PARTITIONS |
| 21 | DeleteRecords | 0–2 | 🟡 Partial | low-end log truncation only (advances the log start; never renumbers offsets) |
| 32 | DescribeConfigs | 0–4 | ✅ Full | leader-authoritative overlay read |
| 44 | IncrementalAlterConfigs | 0–1 | 🟡 Partial | recognizes a subset of configs; several are accepted but no-op |
| 60 | DescribeCluster | 0–2 | ✅ Full | self-as-broker-and-controller |
| 75 | DescribeTopicPartitions | 0–0 | 🟡 Partial | optional API; tooling can safely fall back to Metadata |
Transactions and exactly-once semantics
| Key | API | Versions | Status | Notes |
|---|---|---|---|---|
| 22 | InitProducerId | 0–4 | ✅ Full | idempotent-producer PID allocation and KIP-360 epoch bump |
| 24 | AddPartitionsToTxn | 0–3 | 🟡 Partial | V1 flat, non-batched wire shape only |
| 25 | AddOffsetsToTxn | 0–3 | 🟡 Partial | |
| 26 | EndTxn | 0–4 | 🟡 Partial | writes a real in-log COMMIT/ABORT marker; no per-EndTxn epoch bump |
| 28 | TxnOffsetCommit | 0–3 | 🟡 Partial | single-group shape only |
Transactions are exactly-once at the V1 wire scope: (PID, epoch) fencing,
read_committed isolation, and staged-offset materialization on commit all work like real
Kafka's coordinator. KIP-890 transaction protocol V2 is not shipped — there is no
per-EndTxn epoch bump — and WriteTxnMarkers(27), the broker-internal marker RPC, is never
advertised to clients (see Not supported).
Access control (ACLs)
ACL enforcement is Full, independent of the three management keys below — every Produce/Fetch/group dispatch is authorization-gated at the first hop. The management keys only reflect configuration; they don't drive enforcement. Write is coarse-grained, though — a topic's Write permission authorizes both produce and destructive admin operations on that topic; there is no separate admin-only permission tier. This is a documented limitation, not a roadmap gap.
| Key | API | Versions | Status | Notes |
|---|---|---|---|---|
| 29 | DescribeACLs | 0–3 | 🟡 Partial | returns an honest empty view (or SECURITY_DISABLED) — no fabricated bindings |
| 30 | CreateACLs | 0–3 | 🟡 Partial | |
| 31 | DeleteACLs | 0–3 | 🟡 Partial |
Quotas and SCRAM credential admin
| Key | API | Versions | Status | Notes |
|---|---|---|---|---|
| 48 | DescribeClientQuotas | 0–1 | 🟡 Partial | per-principal produce/fetch token-bucket baseline; full multi-tenant quotas are a later continuation |
| 49 | AlterClientQuotas | 0–1 | 🟡 Partial | |
| 50 | DescribeUserScramCredentials | 0–0 | 🟡 Partial | reflects configured users' mechanisms and iteration counts from server config (never salt or keys) |
| 51 | AlterUserScramCredentials | 0–0 | 🟡 Partial | honestly rejects every mutation with SECURITY_DISABLED — SCRAM credentials are config-managed, not runtime-mutable |
Share groups (KIP-932) — preview
Preview, not GA. Share groups are implemented and advertised — acquire,
Accept/Release/Reject acknowledgements, multi-record batches, and follower-to-leader
forwarding are all wired and validated against a real franz-go share consumer. The full
multi-client share-group conformance matrix — the share-group analogue of the transactions
exit gate — has not run yet. Never read this as "fully supported." See
Share Groups for what to expect today.
| Key | API | Versions | Status | Notes |
|---|---|---|---|---|
| 76 | ShareGroupHeartbeat | 0–1 | 🔵 Preview | join/leave for a share-group member |
| 78 | ShareFetch | 1–1 | 🔵 Preview | acquire; advertised atomically with 76/79 — a client needs all three |
| 79 | ShareAcknowledge | 1–1 | 🔵 Preview | standalone acknowledge outside a ShareFetch round-trip |
| 77 | ShareGroupDescribe | 0–1 | 🔵 Preview | read-only member roster and group state |
| 90 | DescribeShareGroupOffsets | 0–1 | 🔵 Preview | read-only per-partition start offset and lag |
| 91 | AlterShareGroupOffsets | 0–0 | 🔵 Preview | resets an empty group's start offset |
| 92 | DeleteShareGroupOffsets | 0–0 | 🔵 Preview | resets an empty group's start offset to the log start |
The data-plane trio (76/78/79) is advertised as a unit — a franz-go share consumer needs all
three to make any progress. kcat, confluent-kafka, kafkajs, Confluent.Kafka, and
rdkafka (Ruby and Rust) have no share-consumer API today; only franz-go (Go) and
Java's preview KafkaShareConsumer can drive this surface.
Not supported
- KIP-848 next-generation consumer groups (
ConsumerGroupHeartbeat/ConsumerGroupDescribe, keys 68/69) — never advertised; classic groups (group.protocol=classic) are the only supported path. A client that requestsgroup.protocol=consumerfails client-side before sending a single heartbeat — there is no server-side fallback. - KIP-714 client telemetry (
GetTelemetrySubscriptions, key 71) — never advertised; clients simply run without broker-side telemetry collection. WriteTxnMarkers(key 27) — broker-internal only; real Kafka clients never call it directly, and this connector never advertises it.- Schema Registry server — the hosted REST API and its
_schemas-backed storage aren't embedded. The wire-level magic-byte prefix passes through untouched, so Schema-Registry-aware serializers work unchanged. The real, external Confluent Schema Registry service does run against KubeMQ, though — its_schemastopic is just a compacted topic on thenextengine like any other; only the embedded/hosted SR REST API isn't built in. See the Fitness Matrix for the proof tier. - ksqlDB — a separate stream-processing runtime; out of scope as an embedded engine.
- MirrorMaker 2 — cross-cluster mirroring isn't offered as a hosted tool; migration is start-fresh (see Migrate from Kafka).
- Kerberos / GSSAPI SASL — no KDC integration; use SASL/SCRAM, SASL/PLAIN, OAUTHBEARER, or mTLS instead.
- Delegation tokens —
CreateDelegationToken/RenewDelegationToken/ExpireDelegationToken/DescribeDelegationToken(keys 38–41) aren't implemented; any delegation-token request is answeredDELEGATION_TOKEN_AUTH_DISABLED(61) — switch those principals to SASL/SCRAM or mTLS instead.
Related
Error Codes
Every Kafka protocol error code the connector returns and what triggers it.
Fitness Matrix
Per-workload drop-in / caveat / roadmap / unsupported verdicts, with proof tiers.
Kafka settings reference
Field-by-field Connectors.Kafka.* settings, ports, and TLS/SASL options.
Share Groups
Queue-style consumption with KIP-932 share groups, in preview.
Was this page helpful?
Migrate from Kafka
Assess fit with kmq assess kafka, then move topics and consumer-group offsets to KubeMQ with the kmq migrate tool.
Configuration reference
The Kafka connector settings at a glance — the opt-in flag, the 9092/9093 ports, and TOML/environment/Docker examples, plus the full settings reference.