---
page_title: Create admin partitions
description: |-
  Admin partitions define boundaries between services managed by separate teams, enabling a service mesh across k8s clusters controlled by a single Consul server. Learn about their requirements and how to deploy admin partitions on Kubernetes.
---

# Admin partitions overview

This topic provides and overview of admin partitions, which are entities that define one or more administrative boundaries for single Consul deployments.

## Introduction

Admin partitions exist a level above namespaces in the identity hierarchy. They contain one or more namespaces and allow multiple independent tenants to share a Consul server cluster. As a result, admin partitions enable you to define administrative and communication boundaries between services managed by separate teams or belonging to separate stakeholders. They can also segment production and non-production services within the Consul deployment.

As of Consul v1.11, every _datacenter_ contains a single administrative partition named `default` when created. With Consul Enterprise, operators have the option of creating multiple partitions within a single datacenter.

-> **Preexisting nodes**: Admin partitions were introduced in Consul 1.11. Nodes existed in global scope prior to 1.11. After upgrading to Consul 1.11 or later, all nodes will be scoped to an admin partition, which will be the `default` partition when initially upgrading an existing deployment or for CE versions.

There are tutorials available to help you get started with admin partitions.

- [Multi-Tenancy with Administrative Partitions](/consul/tutorials/enterprise/consul-admin-partitions?utm_source=docs)
- [Multi Cluster Applications with Consul Enterprise Admin Partitions](/consul/tutorials/kubernetes/kubernetes-admin-partitions?utm_source=docs)

### Default Admin Partition

Each Consul cluster will have a default admin partition named `default`. The `default` partition must contain the Consul servers. The `default` admin partition is different from other partitions that may be created because the namespaces and resources in this partition are replicated between datacenters when they are federated.

Any resource created without specifying an admin partition will inherit the partition of the ACL token used to create the resource.

-> **Preexisting resources and the `default` partition**: Admin partitions were introduced in Consul 1.11. After upgrading to Consul 1.11 or later, the `default` partition will contain all resources created in previous versions.

### Naming Admin Partitions

Only characters that are valid in DNS names can be used to name admin partitions.
Names must also begin with a lowercase letter.

### Namespaces

When an admin partition is created, it will include the `default` namespace. You can create additional namespaces within the partition. Resources created within a namespace are not shared across partitions.

### Cross-datacenter Replication

Only resources in the `default` admin partition will be replicated to secondary datacenters (also see [Known Limitations](#known-limitations)).

### DNS Queries

When queried, the DNS interface returns results for a single admin partition.
The query may explicitly specify the admin partition to use in the lookup.
If you do not specify an admin partition in the query,
the lookup uses the admin partition of the Consul agent that received the query.
Server agents always exist within the `default` admin partition.
Client agents are configured to operate within a specific admin partition.

By default, Consul on Kubernetes uses [Consul dataplanes](/consul/docs/architecture/control-plane/dataplane) instead of client agents to manage communication between service instances. But to use the Consul DNS for service discovery, you must start a Consul client in client admin partitions.

### Service Mesh Configurations

The partition in which [`proxy-defaults`](/consul/docs/reference/config-entry/proxy-defaults) and [`mesh`](/consul/docs/reference/config-entry/mesh) configurations are created define the scope of the configurations. Services registered in a partition will use the `proxy-defaults` and `mesh` configurations that have been created in the partition.

### Cross-partition Networking

You can configure services to be discoverable by downstream services in any partition within the datacenter. Specify the upstream services that you want to be available for discovery by configuring the `exported-services` configuration entry in the partition where the services are registered. Refer to the [`exported-services` documentation](/consul/docs/reference/config-entry/exported-services) for details. Additionally, the requests made by downstream applications must have the correct DNS name for the Virtual IP Service lookup to occur. Service Virtual IP lookups allow for communications across Admin Partitions when using Transparent Proxy. Refer to the [Service Virtual IP Lookups for Consul Enterprise](/consul/docs/services/discovery/dns-static-lookups#service-virtual-ip-lookups-for-consul-enterprise) for additional information.

-> **Export mesh gateway **: When ACL is enabled in Consul-k8s and `meshgateway.mode` is set to `local`, the `mesh-gateway` service must be exported to their consumers for cross-partition traffic.

### Cluster Peering

You can use [cluster peering](/consul/docs/connect/cluster-peering/) between two admin partitions to connect clusters owned by different operators. Without Consul Enterprise, cluster peering is limited to the `default` partitions in each datacenter. Enterprise users can [establish cluster peering connections](/consul/docs/east-west/cluster-peering/establish/vm) between any two admin partitions as long as the partitions are in separate datacenters. It is not possible to establish cluster peering connections between two partitions in a single datacenter.

## Known Limitations

- Only the `default` admin partition is supported when federating multiple Consul datacenters in a WAN.
- Admin partitions have no theoretical limit. We intend to conduct a large-scale test to identify a recommended max in the future.