La extensión multicluster de Linkerd resuelve uno de los problemas clásicos de las arquitecturas Kubernetes distribuidas en varias regiones: que un clúster entero caiga sin que la copia idéntica del servicio en otra región absorba el tráfico de forma automática. Lo habitual acaba siendo un runbook manual de failover, con restauración y repintado de DNS, justo lo que se pretendía evitar. La extensión permite presentar varios clústeres como un único endpoint balanceado, y admite tres modos combinables por servicio mediante etiquetas: jerárquico o gateway, que replica el servicio como - y enruta el tráfico a través de una pasarela accesible por IP; plano o pod-a-pod, con la misma nomenclatura pero tráfico directo entre pods, que requiere una red plana con IPs de pod enrutables; y federado, que unifica todos los servicios con el mismo nombre en -federated y balancea la carga entre clústeres, también sobre red plana.
El artículo describe una implementación completa sobre Google Kubernetes Engine: tres clústeres GKE en us-central1, us-east1 y europe-west1, enlazados en malla completa mediante peering de VPC con rangos de pods y servicios no solapados, lo que proporciona red plana de forma nativa en GCP. Sobre esa base despliega tres servicios de demostración: un frontend federado en los tres clústeres que reparte carga entre nueve pods, una API replicada en modo plano entre dos regiones y un servicio de analytics exportado solo por gateway. Incluye los prerrequisitos de herramientas, el plan de direccionamiento, la generación de un trust anchor compartido para mTLS entre clústeres, el anclaje de un nodo por zona para contener costes, y un repositorio con scripts automatizados. La pieza incorpora además una prueba de caos que apaga un clúster entero para verificar que el frontend federado sigue atendido por los pods restantes sin cambios en la aplicación. La guía termina apuntando a la parte de instalación de Linkerd y la generación de certificados por clúster, que se desarrolla en una continuación.