Intuit’s Multi‑Cluster Management with Admiral and Istio Service Mesh

As cloud‑native adoption accelerates, large legacy applications are moving to micro‑services, and service decomposition becomes a major challenge. While Kubernetes automates many functions, connecting services across clusters remains difficult, and advanced service‑mesh platforms like Istio are essential to address these issues.

Intuit, founded in 1983 and known for personal finance software, operates about 160 Kubernetes clusters, 5,400 namespaces, and performs 1,300 daily deployments. The company separates clusters to provide business‑unit isolation, meet compliance audit scopes, and host legacy or multi‑region services.

Examples illustrate how API gateways, product information services, and payment services are placed in distinct clusters based on tenancy, ownership, and audit requirements.

Intuit’s six key requirements for multi‑cluster service management include global unique service identifiers, peer‑to‑peer authentication, end‑to‑end encryption, elimination of single points of failure, decoupled service discovery and management, and coordinated Istio‑Kubernetes configuration.

Initially, a shared control plane was considered, but it could not distinguish workloads across namespaces, coupled naming to namespaces, and introduced a single point of failure. The improved approach uses independent control planes per cluster, but synchronizing configurations across clusters remained manual and error‑prone.

Admiral, an open‑source project in the Istio ecosystem, provides automatic configuration and service discovery for multi‑cluster meshes. It defines custom resources for dependencies and global traffic policies, automatically generating ServiceEntries, VirtualServices, and DestinationRules across clusters, reducing operational complexity.

By integrating Admiral with a multi‑control‑plane architecture, Intuit achieves automated, fault‑tolerant configuration management, global unique service naming, and decoupled namespace‑service mapping. Admiral itself holds no runtime state; the actual mesh state resides in each cluster, ensuring resilience even if Admiral disappears.

Although Istio’s capabilities are powerful, domestic adoption is limited; a Chinese city‑bank example shows how a service‑mesh platform built on Istio, backed by a cloud provider, enables cloud‑native transformation, service governance, monitoring, and observability, allowing developers to focus on business logic and accelerate iteration.