Multi-Cloud Kubernetes Cluster: Avengers, Assemble!

Using a simple natural language prompt, I asked AWS Kiro to assume the role of a Network Engineer transitioning into Cloud Native Network and Platform Engineering, and asked it to generate a Multi-cloud Kubernetes Cluster manifest. The AI agent got to work, and through a rigorous(but fun!) back-and-forth deploy and troubleshoot, I finally deployed the Kubernetes Cluster across my AWS and GCP accounts. Finally I tested connectivity by deploying a demo app for Pod-to-Pod, node-to-node and cross cloud load balancing. I used Hubble UI to visualize real-time traffic flow across the cross-cloud clusters. 

Platform — Ubuntu 24.04 running on WSL.

Kiro — Autonomous AI Agent. (kiro-cli on ubuntu)

Terraform — Infrastructure as Code orchestration tool.

Amazon Elastic Kubernetes Service(EKS) — Managed Kubernetes control plane on AWS.

Google Kubernetes Engine(GKE) — Managed Kubernetes control plane on GCP

Helm — Kubernetes Package Manager

Cilium ClusterMesh — (CNI + Service Mesh) eBPF-powered networking, security for both clusters

Hubble — (Observability) Real-time network flow visibility across both clusters.

Using the Kiro generated scripts and workflows, stored onto a local directory, I started by provisioning the infrastructure with Terraform — an EKS cluster on AWS (us-east-1) and a GKE cluster on GCP (us-central1-a), each with 2 worker nodes, dedicated VPCs, and subnets configured for Kubernetes pod/service CIDRs. 

After the clusters were up, I removed the default AWS CNI and kube-proxy from EKS, then installed Cilium v1.15.5 on both clusters via Helm with VXLAN overlay mode, unique cluster IDs (1 and 2), and ClusterMesh enabled. I then connected the clusters using cilium clustermesh connect, which deployed etcd-backed API servers exposed via LoadBalancers (NLB on EKS, standard LB on GKE) and exchanged TLS certificates between them.

 With the control plane connected, we(Kiro and I) discovered that the data plane couldn’t flow because the nodes’ private IPs weren’t routable across clouds — so we established a WireGuard VPN(in a Production environment, AWS Interconnect with GCP  would be ideal) mesh between all 4 nodes, making each cloud’s private node IPs reachable from the other. To test cross cloud cluster connectivity , I asked Kiro to deploy a demo app with the service.cilium.io/global: “true” annotation on both clusters. This caused Cilium’s eBPF load balancer to merge backends from both clusters into a single global service — delivering true cross-cloud load balancing with traffic alternating between EKS and GKE pods. 

By combining Agentic AI , Infrastructure as Code and Cloud-Native technologies, this project highlights how emerging technologies can be used to deliver well-architected and agile multi-cloud solutions.

Why Multi-cloud? — Because distributing workloads across AWS and GCP eliminates single-vendor lock-in, enables best-of-breed service selection, and provides true disaster resilience that no single cloud can offer alone.

Why Cloud-Native? — Because Kubernetes, Cilium, and Helm give you declarative, portable infrastructure that behaves identically regardless 
 of which cloud sits underneath — making the multicloud complexity manageable through abstraction.

Why Open Source? — Because Cilium, Terraform, and Kubernetes let you build production-grade cross-cloud networking without proprietary lock-in, with full visibility into every layer and global community support.

If you want to replicate or reference to this Project, refer to the README  in the published repository, which provides a comprehensive step-by-step implementation guide.

Github Repository — https://github.com/ansleyAA/multicloud-k8s