Capabilities
What the KubeMQ Kafka connector supports — every implemented Kafka API, from Produce/Fetch and consumer groups to transactions and share groups.
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.
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–5 | ✅ Full | v5 honors the classic/share type filter and reports each group's type; lists share groups too. Capped at v4 while CONNECTORS_KAFKA_SHARE_FEATURE_VERSION is 1 |
| 42 | DeleteGroups | 0–2 | ✅ Full | also deletes a share group once no consumer is attached (NON_EMPTY_GROUP while one is) |
| 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; also reads a share group's configuration (GROUP resource) |
| 44 | IncrementalAlterConfigs | 0–1 | 🟡 Partial | recognizes a subset of configs; several are accepted but no-op. Also sets a share group's configuration (GROUP resource) — see Share Groups |
| 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)
Generally available. Share groups are certified with Java's KafkaShareConsumer
(kafka-clients 4.3) and the Kafka 4.3 console tools on a single node and on three-node
clusters, including a killed share coordinator with nothing lost and nothing accepted twice.
Every key except DescribeShareGroupOffsets is 🟡 Partial because a few behaviors deliberately
differ from Apache Kafka 4.3 — each row names its difference, and
the full list has all of them.
See Share Groups for how to use them.
| Key | API | Versions | Status | Notes |
|---|---|---|---|---|
| 76 | ShareGroupHeartbeat | 0–1 | 🟡 Partial | join/leave for a share-group member; every member is assigned every partition (share.assignment.interval.ms is refused) |
| 78 | ShareFetch | 1–2 | 🟡 Partial | acquire and acknowledge; v2 adds share.acquire.mode=record_limit and lock renewal. Answers at once instead of waiting up to the client's maximum wait; fetch sizes count stored batches, not records. Advertised together with 76/79 — a client needs all three |
| 79 | ShareAcknowledge | 1–2 | 🟡 Partial | standalone acknowledge (v2 adds renew); a late acknowledgement for a record nobody holds is not refused |
| 77 | ShareGroupDescribe | 0–1 | 🟡 Partial | member list and group state (Stable with a member, Empty when idle); a group that never existed answers Dead |
| 90 | DescribeShareGroupOffsets | 0–1 | ✅ Full | per-partition start offset and lag; reports an idle group's offsets even when the request names no topics |
| 91 | AlterShareGroupOffsets | 0–0 | 🟡 Partial | moves a group's start offset while no consumer is attached, and creates it where the group has none; refuses a group id no consumer could join |
| 92 | DeleteShareGroupOffsets | 0–0 | 🟡 Partial | resets an empty group's start offset to the log start (Kafka 4.3 re-applies share.auto.offset.reset) |
While CONNECTORS_KAFKA_SHARE_FEATURE_VERSION is 1 — a setting used only during a rolling
upgrade — ShareFetch and ShareAcknowledge are capped at v1 and ListGroups at v4. Java's
KafkaShareConsumer, the Kafka console tools and franz-go drive this surface; librdkafka's
share consumer is an upstream preview. kcat, kafkajs, Confluent.Kafka, and the Ruby and
Rust rdkafka bindings do not expose a share consumer yet.
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 as a hosted service — KubeMQ does not run MirrorMaker for you. Moving
an existing workload does not need it:
kmq migratecopies topics, records and consumer-group offsets, and for very large histories you can run your own MirrorMaker 2 against KubeMQ as a target (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 — clients, settings, admin tools, and upgrades.
Was this page helpful?
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.
Configuration reference
Kafka connector settings at a glance — the on-by-default enable flag, the 9092/9093 ports, TOML/environment/Docker examples, and the full settings reference.