> For the complete documentation index, see [llms.txt](https://docs.lenses.io/latest/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lenses.io/latest/k2k/features.md).

# Features

K2K features enabled per pipeline.

K2K features are enabled per pipeline. Each one addresses a specific requirement when replicating between clusters.

For configuration steps and keys, see the [Configuration Reference](/latest/k2k/configuration-reference.md) guides. For architecture, see [Architecture](/latest/k2k/architecture.md).

For step-by-step operational procedures, see [Runbooks](/latest/k2k/runbooks.md).

## Key architectural features

* **Cloud-native deployment:** K2K is distributed as a lightweight Docker container with first-class Kubernetes support and an official Helm chart.
* **Horizontal scalability:** Run multiple K2K instances in parallel; they automatically coordinate to distribute the replication workload.
* **Self-contained and frameworkless:** Unlike Kafka Connect-based solutions, K2K is a standalone application with a smaller resource footprint and simpler operational model.
* **Declarative configuration:** All aspects of a replication pipeline are defined in a single YAML configuration file, managed as code and integrated into CI/CD workflows.

## Exactly once delivery

For pipelines where the target Kafka cluster must be a faithful copy of the source Kafka cluster, exactly once delivery guarantees that each record appears on the target Kafka cluster once and in the same order. Downstream consumers can treat the target Kafka cluster as equivalent to the source Kafka cluster without deduplicating.

See [Exactly once delivery](/latest/k2k/configuration-reference/exactly-once-delivery.md) and [Commit tuning](/latest/k2k/configuration-reference/commit-tuning.md).

## Offset mapping

Consumer offsets on one cluster have no meaning on another. Offset mapping keeps group positions on the target Kafka cluster aligned with the source Kafka cluster, so applications can fail over or complete a migration without starting over.

{% hint style="warning" %}
When `features.offsetMapping` is `enabled`, deploy and run both `k2k` and `k2k-offset-mapping`. Enabling the feature in the pipeline file does not translate consumer offsets by itself.
{% endhint %}

See [Offset mapping](/latest/k2k/configuration-reference/offset-mapping.md) and [Deployment](/latest/k2k/deployment.md#offset-mapping-both-applications-required).

## Bidirectional replication

Some environments need data flowing in both directions. Bidirectional replication keeps two clusters in sync without records cycling between them, as in active/active setups where both Kafka clusters produce and consume.

See [Bidirectional replication](/latest/k2k/configuration-reference/bidirectional-replication.md).

## Horizontal scaling

As data volume grows, replication may need more capacity than a single instance can provide. K2K can run multiple replicator or offset mapper instances that share the workload, increasing throughput to match demand.

See [Horizontal scaling](/latest/k2k/configuration-reference/horizontal-scaling.md).

## Record tracing

Every replicated record can carry a link back to its origin on the source Kafka cluster (topic, partition, and offset). Operators use this to debug issues, correlate data across clusters, and trace lineage.

See [Record tracing](/latest/k2k/configuration-reference/record-tracing.md).

## Topic creation

K2K can provision the topics it needs on the target Kafka cluster before replication begins, with the expected partition count and configuration. This reduces manual setup when bringing up a new cluster.

See [Topic creation](/latest/k2k/configuration-reference/topic-creation.md).

## Schema migration

Records that depend on Schema Registry need their schemas on the target Kafka cluster as well. Schema migration ensures the subjects applications rely on are available on the target Kafka cluster, so replicated data can be consumed immediately.

See [Schema migration](/latest/k2k/configuration-reference/schema-migration.md).

## Cross-cluster replication

The source Kafka cluster and target Kafka cluster do not need to run on the same platform or version. K2K replicates between on premise Kafka, managed cloud offerings, and mixed environments.

See [Kafka connectivity and authentication](/latest/k2k/configuration-reference/kafka-connectivity-authentication.md). For Schema Registry, see [Schema Registry connectivity and authentication](/latest/k2k/configuration-reference/schema-registry-connectivity-authentication.md).

## Configurability and tuning

Pipelines expose the settings operators need to match security policies, client behavior, and throughput requirements on each cluster. K2K defaults should cover most use cases; each configuration reference guide includes an Advanced section for environment-specific tuning.

See [Performance](/latest/k2k/performance.md), [Horizontal scaling](/latest/k2k/configuration-reference/horizontal-scaling.md), and [Replication performance tuning](/latest/k2k/configuration-reference/replication-performance-tuning.md).

## Metrics and visibility

K2K exports replication throughput, lag, partition assignment, and JVM metrics through Kafka (with Lenses HQ), OTLP, and Prometheus exporters.

Operators use these metrics to monitor pipeline health, spot bottlenecks, and alert on replication issues before they affect failover or migration timelines.

See [Observability](/latest/k2k/configuration-reference/observability.md).

## Admin UI and CLI

[k2k-tool](/latest/k2k/k2k-standalone-tool.md) provides a UI and CLI to inspect replication state and adjust consumer offsets. Operators reach for it during failover, migration cutover, or when investigating lag, without changing the pipeline configuration.

See [Web UI](/latest/k2k/k2k-standalone-tool/web-ui.md) and [CLI](/latest/k2k/k2k-standalone-tool/cli.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.lenses.io/latest/k2k/features.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.