Cloud Native 7 min read

Intuit’s Multi‑Cluster Kubernetes Management with Admiral Service Mesh

The article explains how Intuit manages hundreds of Kubernetes clusters using multi‑control‑plane architectures and Admiral to automate Istio service‑mesh configuration, illustrating the challenges of large‑scale microservice deployment and sharing a domestic bank’s experience with similar cloud‑native adoption.

Cloud Native Technology Community
Cloud Native Technology Community
Cloud Native Technology Community
Intuit’s Multi‑Cluster Kubernetes Management with Admiral Service Mesh

As cloud‑native adoption accelerates, traditional large‑scale applications are moving to microservices, facing challenges in service decomposition and inter‑service connectivity; advanced service‑mesh platforms like Istio are emerging as key solutions.

Intuit, founded in 1983 and known for personal finance software, operates about 160 Kubernetes clusters across four business units, hosting roughly 5,400 namespaces and performing 1,300 daily deployments.

The company partitions clusters to achieve business‑unit isolation, meet compliance audit scopes, and host legacy or multi‑region services that require dedicated clusters.

For example, an API gateway serving multiple BUs is isolated in its own cluster, while product‑information and book‑order services share a cluster, and the payment service is placed separately for audit purposes.

Intuit’s six driving requirements are: a globally unique service identifier, mutual TLS authentication, end‑to‑end encryption, elimination of single points of failure, decoupled service discovery and management, and coordinated Istio‑Kubernetes configuration.

The initial solution of a shared control plane for all clusters suffered from inability to distinguish workloads across namespaces, tangled configuration management, and a critical single‑point‑of‑failure risk.

An improved approach introduced independent control planes per cluster, but required manual synchronization of configurations across clusters, making cross‑cluster routing cumbersome.

Admiral addresses these gaps by providing automatic configuration and service‑discovery across clusters; it defines custom resources such as Dependency and GlobalTrafficPolicy to generate ServiceEntries, VirtualServices, and DestinationRules, reducing operational complexity.

In practice, Admiral acts as a mediator controller, propagating configurations to all clusters, assigning globally unique names, decoupling namespaces from service definitions, supporting multiple service names, and enabling region‑specific routing, all without maintaining runtime state.

A domestic bank, as an early adopter in the financial sector, leveraged Istio service mesh on Lingque Cloud to build a comprehensive service‑governance platform that offers observability, decouples platform and business functions, and accelerates product iteration.

The article concludes with an invitation to join cloud‑native technical communities for further discussion and collaboration.

cloud nativemicroservicesKubernetesmulti-clusterIstioService MeshAdmiral
Cloud Native Technology Community
Written by

Cloud Native Technology Community

The Cloud Native Technology Community, part of the CNBPA Cloud Native Technology Practice Alliance, focuses on evangelizing cutting‑edge cloud‑native technologies and practical implementations. It shares in‑depth content, case studies, and event/meetup information on containers, Kubernetes, DevOps, Service Mesh, and other cloud‑native tech, along with updates from the CNBPA alliance.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.