Skip to content

Multi-Cloud Kubernetes Platform

EKS, AKS and GKE compared through one deployment model

Reference architectureImplemented & validated locally

Basis: Reference comparison. Based on hands-on EKS and GKE production work (CV) and AKS reference work. Not a cross-cloud failover design. Never applied against a real cluster on any cloud.

Overview

The same Helm-packaged service deployed to all three managed Kubernetes offerings, documenting where they genuinely differ: identity, networking, ingress, logging and cost.

Problem

Teams are asked to be 'cloud agnostic' without a clear view of what is portable and what is not.

Solution

Keep the workload portable (container + Helm chart) and accept that the platform layer — identity, networking, ingress — is cloud-specific. Abstract only where the abstraction is cheap.

Architecture

  1. Portable

    • Container image

    • Helm chart

      per-cloud values

    • ArgoCD

  2. Identity

    • EKS Pod Identity / IRSA

    • Entra Workload ID

    • GKE Workload Identity

  3. Clusters

    • EKS

    • AKS

    • GKE

Portable layer on top, cloud-specific platform layer underneath. No automatic cross-cloud failover is implied.

Technology stack

  • Amazon EKS
  • Azure AKS
  • Google GKE
  • Helm
  • Terraform
  • ArgoCD

Implementation

  • One Helm chart with a base values.yaml plus a values file per cloud for ingress class/annotations, the ServiceAccount's workload-identity annotation, and the storage class — a test suite proves the overlays never diverge on anything else (image, replicas, resources, probes, PodDisruptionBudget).
  • A Terraform identity-bindings module binds the same ServiceAccount name to each cloud's native workload identity (IRSA, Entra Workload ID, GKE Workload Identity) instead of building three more full cluster stacks, since this portfolio already has one for each cloud.
  • One ArgoCD ApplicationSet (a single list generator, one entry per cloud) deploys the chart to all three clusters — the 'one deployment model' the title promises.
  • A structured comparison doc, rendered and validated by a small script that raises if a cloud or dimension is ever missing a value, covering control plane pricing, upgrade cadence, networking mode and logging integration.

Security

  • Each cloud's native workload identity — IRSA on EKS, Entra Workload ID on AKS, GKE Workload Identity on GKE — never a static cloud credential in any pod.
  • IAM/identity trust policies scoped to the exact namespace/ServiceAccount subject, not a project- or account-wide grant.

Reliability

  • Each cluster is independently highly available; cross-cloud failover would need data replication that this project explicitly does not claim.

Cost

  • Control plane, egress and load balancer pricing differ — compare total cost for the workload, not node prices.
  • The identity-bindings Terraform creates only IAM-layer objects, none of which carry a runtime cost on any cloud.

Results

No quantified results are published for this project. Figures from client work are confidential, and this portfolio only shows numbers that can be verified or reproduced.

Code & documentation

View on GitHub

Lessons learned

  • Portability is cheapest at the workload layer and most expensive at the data layer.
  • Abstracting workload identity behind a unified broker is a false economy — it's one more thing to operate and one more place a subject-string mismatch fails opaquely; setting each cloud's real ServiceAccount annotation is simpler and more debuggable.
  • A comparison that can't go stale (validated by code) beats a comparison that's just prose.