# Deploy Ecosystem Components on a Multi-Tenant PKC This page describes how each component fits into a multi-tenant Physical Kafka Cluster (PKC). Multi-Tenancy is supported starting in Confluent Platform 8.4, and in Confluent for Kubernetes (CFK), starting in the 3.4 release. ![Multi-tenant PKC architecture showing shared brokers, per-tenant Logical Kafka Clusters, per-LKC Kafka Connect and ksqlDB instances, and shared Control Center and MDS](images/private-cloud-multi-tenancy-architecture.png) Each component uses one of three deployment models: - **Multi-tenant-aware**: Kafka, Confluent Control Center, and Metadata Service (MDS) run as a single shared instance per PKC, enforcing isolation or scoping views per LKC through role-based access control (RBAC) instead of deploying separate infrastructure per Logical Kafka Cluster (LKC). - **Shared per PKC**: deploy a single shared Schema Registry instance per PKC. You can achieve schema isolation between LKCs using [Schema Registry contexts](../../schema-registry/schema-contexts-cp.md#work-with-schema-contexts), if required. - **Dedicated per LKC**: deploy a dedicated instance of Kafka Connect, ksqlDB, and REST Proxy for each LKC. Each instance binds to a single LKC as its backend, so one instance can’t serve multiple LKCs. ## Component deployment model | Component | Deployment model | Why | |--------------------------|-------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Kafka | Multi-tenant. Shared brokers, isolated per LKC | Each LKC gets its own advertised broker URLs, and broker-native
architecture enforces LKC boundaries and resource quotas directly, so you
don’t need an extra per-LKC instance.

| | Confluent Control Center | Shared per PKC, RBAC-scoped views per persona | RBAC scopes each persona’s console view to their own PKC or LKC,
so one shared instance can serve every LKC without exposing
others’ resources. Requires Confluent Control Center 2.7 or later and
`spec.authorization.type: rbac` on the `ControlCenter` custom
resource (CR).

For more information, see
[Configure RBAC for Control Center on Confluent
Platform](/control-center/current/security/c3-rbac.html).

| | MDS | Single instance bound to the Kafka brokers, supporting both
PKC-wide and LKC-scoped role bindings | LKC-scoped role bindings let one shared identity and
authorization foundation govern every LKC, without a separate
RBAC deployment per LKC.

For more information, see [Manage RBAC for Confluent Platform
Using Confluent for Kubernetes](https://docs.confluent.io/operator/current/co-manage-rbac.html).

| | Schema Registry | Shared per PKC | A single shared instance can serve every LKC. LKCs that
need schema isolation use a Schema Registry context to separate
their schemas from other LKCs’ without a dedicated instance.
Confluent recommends this approach.

For more information, see [Manage Schemas for Confluent Platform
Using Confluent for Kubernetes](https://docs.confluent.io/operator/current/co-manage-schemas.html).

| | Kafka Connect | Dedicated per LKC | Configures its own LKC bootstrap URL as its backend, so each
LKC needs its own dedicated instance to route to the right LKC.

For more information, see [Manage Connectors for Confluent
Platform Using Confluent for Kubernetes](https://docs.confluent.io/operator/current/co-manage-connectors.html).

| | ksqlDB | Dedicated per LKC | Configures its own LKC bootstrap URL as its backend, so each
LKC needs its own dedicated instance to route to the right LKC.

| | REST Proxy | Dedicated per LKC | Configures its own LKC bootstrap URL as its backend, so each
LKC needs its own dedicated instance to route to the right LKC.

For more information, see [Configure and Manage REST Proxy for
Confluent Platform Using Confluent for Kubernetes](https://docs.confluent.io/operator/current/co-configure-rest-proxy.html).

| For each LKC, point the dedicated Kafka Connect, ksqlDB, or REST Proxy CR at that LKC instead of the PKC’s own `Kafka` CR. Set `dependencies.kafka.discovery.kind` to `LogicalKafkaCluster` and `dependencies.kafka.discovery.name` to the LKC’s name. After discovery resolves the LKC’s bootstrap URL, Kafka Connect and ksqlDB register themselves in the MDS cluster registry, so Confluent Control Center can discover them by LKC. REST Proxy doesn’t register itself in the cluster registry, so Confluent Control Center can’t discover an LKC-scoped REST Proxy instance. ## Tiered storage Tiered storage works the same way on a multi-tenant PKC as on a single-tenant cluster. The broker archives eligible segments to remote object storage. The PKC accepts tiered-storage topic configurations, such as `confluent.tier.enable`, at topic-creation time. For more information about configuring tiered storage, see [Tiered Storage in Confluent Platform](../../clusters/tiered-storage.md#tiered-storage). ## Related content - [Multi-Tenancy Overview](overview.md#multi-tenancy-overview) - [Configure TLS Certificates and DNS for Multi-Tenant PKCs](tls-options.md#multi-tenancy-tls-options)