Kubernetes itself is largely cloud-agnostic. The cloud provider mainly supplies the infrastructure around Kubernetes.

We'll compare:

AWS EKS
GCP GKE
Azure AKS

and understand what actually changes when you move your application between clouds.

1. The big picture#

You already know this architecture:

Internet
   ↓
Load Balancer / Ingress
   ↓
Service
   ↓
Deployment
   ↓
Pods
   ↓
Containers

That architecture is Kubernetes.

It doesn't fundamentally change because you're using AWS, GCP, or Azure.

What changes is the surrounding infrastructure.

                Kubernetes
                    │
        ┌───────────┼───────────┐
        ↓           ↓           ↓
       AWS         GCP        Azure
       EKS         GKE         AKS
        │           │           │
       EC2        Compute      VMSS
       ECR        Artifact     ACR
       ALB        LB           Azure LB
       IAM        IAM          Entra ID
       RDS        Cloud SQL    Azure DB

2. The three major managed Kubernetes services#

So:

AWS     → EKS
Google  → GKE
Azure   → AKS

3. Why managed Kubernetes?#

You could theoretically install Kubernetes yourself on virtual machines.

For example:

VM 1 → Control Plane
VM 2 → Control Plane
VM 3 → Control Plane
 
VM 4 → Worker
VM 5 → Worker
VM 6 → Worker

But then you're responsible for a huge amount of operational work.

Managed Kubernetes services reduce that burden.

Conceptually:

Self-managed
────────────────
You manage Kubernetes
You manage control plane
You manage upgrades
You manage availability
You manage infrastructure
 
Managed Kubernetes
────────────────
Cloud provider manages much of the control-plane infrastructure
You focus more on workloads and platform configuration

The exact division of responsibility depends on the service and configuration.

4. GKE — Google Kubernetes Engine#

GKE is Google's managed Kubernetes service.

Architecture:

Google Cloud
     │
     ↓
    GKE
     │
     ↓
Node Pools
     │
 ┌───┼───┐
 ↓   ↓   ↓
Pod Pod Pod

Google has been deeply involved in Kubernetes since its origins, so GKE is an important Kubernetes platform to understand.

5. GKE control plane#

GKE provides a managed Kubernetes control plane.

You interact with it using:

kubectl

For example:

kubectl get nodes

or:

kubectl get pods

The commands are fundamentally the same as EKS.

This is the power of Kubernetes abstraction.

6. GKE node pools#

GKE uses node pools.

Think:

GKE Cluster
     │
     ├── Node Pool A
     │     ├── Node
     │     └── Node
     │
     └── Node Pool B
           ├── Node
           └── Node

Node pools are useful when workloads have different requirements.

For example:

General workloads
    ↓
general-purpose nodes

and:

AI / GPU workloads
    ↓
GPU node pool

7. GKE Autopilot#

GKE provides two important operating models:

GKE Standard#

You have more direct control over nodes and node pools.

GKE
 ↓
Node Pools
 ↓
Nodes
 ↓
Pods

GKE Autopilot#

Google manages more of the underlying infrastructure and node operations for you.

Conceptually:

GKE Autopilot
      ↓
You specify workloads
      ↓
Google manages more infrastructure
      ↓
Pods

This is similar in spirit to other cloud providers' more automated Kubernetes operating models.

8. GKE networking#

GKE integrates tightly with Google Cloud networking.

Your cluster can interact with:

VPC
Subnets
Load Balancers
Firewall rules
Cloud NAT
Cloud DNS

Conceptually:

GCP VPC
 │
 ├── Subnet
 │    ├── Node
 │    ├── Node
 │    └── Pod networking
 │
 └── Load Balancer

GKE commonly uses Google's VPC-native networking model.

9. GKE Load Balancer#

Suppose you create a Kubernetes Service of an appropriate type.

Google Cloud can provision a load-balancing resource.

Conceptually:

Internet
   ↓
Google Cloud Load Balancer
   ↓
Kubernetes Service
   ↓
Pods

For HTTP/HTTPS applications, you may also use Gateway API or Ingress-based solutions depending on the architecture.

10. GKE container registry#

You need a container registry.

Google Cloud provides:

Artifact Registry

Architecture:

Developer
    ↓
Docker build
    ↓
Artifact Registry
    ↓
GKE
    ↓
Pod

For example:

Artifact Registry
└── node-api
    ├── 1.0.0
    ├── 1.1.0
    └── 1.2.0

11. GKE + Cloud SQL#

Instead of running PostgreSQL inside Kubernetes:

PostgreSQL Pod

you can use:

Cloud SQL

Architecture:

Node.js Pods
     │
     ↓
Cloud SQL PostgreSQL

This is conceptually similar to:

EKS → RDS
GKE → Cloud SQL
AKS → Azure Database

12. GKE + Memorystore#

For Redis-like caching, Google Cloud offers:

Memorystore

Architecture:

Node.js
   │
   ├── Cloud SQL
   │
   └── Memorystore

So your Kubernetes cluster can focus primarily on application workloads.

13. GKE workload identity#

Suppose your application needs to access:

Cloud Storage
Secret Manager
Pub/Sub
BigQuery

You shouldn't put service-account keys inside your container.

Instead, Google provides workload identity mechanisms for associating Kubernetes workloads with Google Cloud identities.

Conceptually:

Pod
 ↓
Kubernetes ServiceAccount
 ↓
Workload Identity
 ↓
Google Cloud IAM
 ↓
Cloud Storage

This follows the same principle we discussed with EKS:

Give workloads identities rather than embedding long-lived credentials.

14. AKS — Azure Kubernetes Service#

Now let's move to Microsoft Azure.

AKS is:

Azure Kubernetes Service

Architecture:

Azure
 │
 ↓
AKS
 │
 ↓
Node Pools
 │
 ├── Node
 ├── Node
 └── Node
      │
      ↓
     Pods

Again:

kubectl
   ↓
AKS
   ↓
Pods

The Kubernetes commands remain familiar.

15. AKS node pools#

AKS also supports node pools.

Example:

AKS
 │
 ├── System Node Pool
 │
 └── User Node Pool
       ├── Node
       ├── Node
       └── Node

You can create specialized node pools.

For example:

CPU workloads
    ↓
CPU node pool
 
GPU workloads
    ↓
GPU node pool

Then Kubernetes scheduling concepts from Chapter 17 become useful:

nodeSelector
affinity
taints
tolerations

16. AKS networking#

AKS integrates with Azure networking.

Relevant components include:

Virtual Network
Subnets
Load Balancer
Network Security Groups
Azure DNS

Conceptually:

Azure VNet
 │
 ├── Subnet
 │    └── AKS nodes
 │
 └── Load Balancer

17. Azure Container Registry#

Azure provides:

Azure Container Registry — ACR

Architecture:

Developer
   ↓
Docker build
   ↓
ACR
   ↓
AKS
   ↓
Pods

So now you have:

AWS
ECR
 
GCP
Artifact Registry
 
Azure
ACR

18. AKS + Azure Database#

For PostgreSQL, you can use Azure's managed database services rather than running PostgreSQL yourself in Kubernetes.

Conceptually:

AKS
 │
 └── Node.js Pods
          │
          ↓
   Azure managed PostgreSQL

For Redis:

Node.js
   ↓
Azure managed Redis service

The exact Azure service offering and naming can evolve, so verify the current Azure product when designing a new deployment.

19. Microsoft Entra ID#

Azure's identity ecosystem uses:

Microsoft Entra ID

formerly known as Azure Active Directory.

This can integrate with Azure access control and AKS authentication/authorization workflows.

Conceptually:

Developer
    ↓
Entra ID
    ↓
Azure
    ↓
AKS

20. AWS vs GCP vs Azure#

Now let's compare the major building blocks.

The important part:

kubectl stays the same.

21. What stays the same?#

This is one of the most important lessons.

Your Deployment:

apiVersion: apps/v1
kind: Deployment
 
spec:
  replicas: 3

can generally work across:

EKS
GKE
AKS

Your Service:

apiVersion: v1
kind: Service

is still Kubernetes.

Your ConfigMap:

kind: ConfigMap

is still Kubernetes.

Your Secret:

kind: Secret

is still Kubernetes.

Your HPA:

kind: HorizontalPodAutoscaler

is still Kubernetes.

22. What changes?#

Cloud-specific infrastructure changes.

For example:

Container Registry

changes:

ECR
Artifact Registry
ACR

Load-balancer integration changes.

Identity integration changes.

Managed database changes.

Object storage changes.

Networking implementation changes.

Autoscaling integration can change.

So think:

Kubernetes layer
        +
Cloud layer

23. Cloud-agnostic application#

Suppose your Node.js application needs:

PostgreSQL
Redis
Object storage

If your application directly hardcodes:

aws.s3(...)

then you're more tightly coupled to AWS.

Instead, you can abstract your application interface.

For example:

await storage.upload(file);

Then the implementation can be:

AWS → S3
GCP → Cloud Storage
Azure → Blob Storage

The application interface remains stable.

24. Kubernetes abstraction#

The same idea applies to Kubernetes.

Your application doesn't need to know:

EKS
GKE
AKS

It simply runs inside:

Pod

and communicates through:

Service

This is one reason Kubernetes became so valuable.

25. But Kubernetes is not completely cloud-agnostic#

Be careful.

You can write:

kind: Deployment

and run it almost anywhere.

But this:

annotations:
  service.beta.kubernetes.io/aws-load-balancer-...

is cloud-specific.

Similarly, cloud-specific storage classes:

AWS EBS
GCP Persistent Disk
Azure Disk

can differ.

So:

Core Kubernetes
        ↓
Portable
 
Cloud-specific extensions
        ↓
Less portable

26. Storage portability#

Suppose your application uses:

kind: PersistentVolumeClaim

The PVC itself is Kubernetes-native.

But the underlying StorageClass might be cloud-specific.

Example conceptually:

AWS → EBS-backed StorageClass
GCP → Persistent Disk-backed StorageClass
Azure → Azure Disk-backed StorageClass

So the application YAML might need overlays.

This is where Kustomize from Chapter 26 becomes useful.

27. Multi-cloud with Kustomize#

You could have:

k8s/
│
├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── ingress.yaml
│
└── overlays/
    ├── aws/
    │   └── kustomization.yaml
    │
    ├── gcp/
    │   └── kustomization.yaml
    │
    └── azure/
        └── kustomization.yaml

Base:

Node.js Deployment
Service
ConfigMap

AWS overlay:

AWS-specific annotations
ECR image
AWS storage

GCP overlay:

GCP-specific annotations
Artifact Registry
GCP storage

Azure overlay:

Azure-specific annotations
ACR
Azure storage

This is a practical use of Kustomize.

28. Cloud-specific Ingress#

Your application might use:

kind: Ingress

but the implementation can differ.

For example:

AWS
 ↓
AWS Load Balancer Controller
 ↓
ALB

GCP:

GKE
 ↓
Google Cloud Load Balancing integration

Azure:

AKS
 ↓
Azure networking/load-balancing integration

Therefore, don't assume an Ingress manifest is automatically identical across clouds.

29. Gateway API#

You've already heard about Gateway API.

This is increasingly important for modern Kubernetes networking.

Conceptually:

Ingress
   ↓
Traditional HTTP routing
 
Gateway API
   ↓
More expressive Kubernetes networking API

It provides a richer model for:

Gateway
Routes
Traffic policies
Cross-team ownership

You don't need to master Gateway API yet.

We'll encounter it again as you move deeper into production architecture.

30. Autoscaling comparison#

All three clouds support Kubernetes autoscaling patterns, but the implementation details differ.

The conceptual architecture remains:

HPA
 ↓
Pods

and:

Node autoscaling
 ↓
Nodes

GKE, EKS, and AKS each provide cloud-specific integrations for scaling node capacity.

The exact tooling has evolved over time, so don't memorize one cloud-specific component as the universal answer.

31. GPU workloads#

This is especially relevant for your AI/LLM interests.

Suppose you want:

AI inference

You might have:

GPU Node Pool
      │
      ├── AI Pod
      ├── AI Pod
      └── AI Pod

Kubernetes can request GPU resources.

Example:

resources:
  limits:
    nvidia.com/gpu: 1

Then scheduling mechanisms can ensure the Pod lands on an appropriate GPU node.

This works conceptually across major cloud Kubernetes platforms, although the GPU instance types, drivers, device plugins, and cloud setup differ.

32. Kubernetes + AI architecture#

For an AI application:

                    Internet
                       │
                       ↓
                    Ingress
                       │
                       ↓
                API Deployment
                       │
              ┌────────┼────────┐
              ↓        ↓        ↓
            Redis     RAG      Model
                       │       Server
                       ↓
                    Vector DB

The model server might run on:

GPU node pool

while normal APIs run on:

CPU node pool

Scheduling separates the workloads.

33. EKS vs GKE vs AKS — mental model#

Don't try to memorize hundreds of cloud-specific commands.

Remember this:

             Managed Kubernetes
                    │
       ┌────────────┼────────────┐
       ↓            ↓            ↓
      AWS          GCP         Azure
       │            │            │
      EKS          GKE          AKS
       │            │            │
      ECR       Artifact Reg.    ACR
       │            │            │
      IAM       Cloud IAM       Entra

The Kubernetes concepts remain:

Pod
Deployment
Service
Ingress
ConfigMap
Secret
PVC
HPA
RBAC
NetworkPolicy

34. A powerful interview answer#

If an interviewer asks:

"How portable is Kubernetes across cloud providers?"

A strong answer is:

"Core Kubernetes resources such as Deployments, Pods, Services, ConfigMaps and HPA are largely portable because they're defined through the Kubernetes API. However, cloud-specific integrations such as load balancers, storage classes, IAM/workload identity, container registries and networking annotations can differ. We can isolate many of those differences using abstractions, Kustomize overlays, Helm values, or platform-specific infrastructure configuration."

That's a very strong answer.

35. Multi-cloud architecture#

Suppose your company uses:

AWS
 +
GCP

You could have:

                  Git
                   │
                   ↓
             CI/CD Pipeline
                   │
             ┌─────┴─────┐
             ↓           ↓
           AWS          GCP
            ↓             ↓
           EKS           GKE
            ↓             ↓
          Pods           Pods

The application manifests can share a common base.

Base
 │
 ├── AWS overlay
 │
 └── GCP overlay

36. Should every company use multi-cloud?#

Not necessarily.

Multi-cloud can provide certain organizational or resilience benefits, but it also increases:

Operational complexity
Monitoring complexity
Networking complexity
IAM complexity
Skill requirements
Deployment complexity
Cost-management complexity

So:

Multi-cloud ≠ automatically better

The architecture should match the business and operational requirements.

37. Important interview distinction#

Kubernetes#

Open-source orchestration platform

EKS#

AWS managed Kubernetes

GKE#

Google Cloud managed Kubernetes

AKS#

Azure managed Kubernetes

38. Your application across all three clouds#

Imagine this Node.js Deployment:

apiVersion: apps/v1
kind: Deployment
 
metadata:
  name: node-api
 
spec:
  replicas: 3
 
  selector:
    matchLabels:
      app: node-api
 
  template:
    metadata:
      labels:
        app: node-api
 
    spec:
      containers:
        - name: node-api
          image: node-api:1.0.0
          ports:
            - containerPort: 3000

The fundamental Kubernetes structure doesn't care whether the cluster is:

EKS
GKE
AKS

That's the abstraction.

39. But the image location changes#

AWS:

ECR
 ↓
node-api:1.0.0

GCP:

Artifact Registry
 ↓
node-api:1.0.0

Azure:

ACR
 ↓
node-api:1.0.0

So Kustomize/Helm can manage this difference.

40. Your Kubernetes journey so far#

Look how much you've covered:

Chapter 1
Kubernetes fundamentals
       ↓
Chapter 2
Docker
       ↓
Chapter 3
Architecture
       ↓
Chapter 4
kubectl
       ↓
Chapter 5
Pods
       ↓
Chapter 6
Deployments
       ↓
Chapter 7
Services
       ↓
Chapter 8
Namespaces
       ↓
Chapter 9
ConfigMaps/Secrets
       ↓
Chapter 10
Storage
       ↓
Chapter 11
Networking
       ↓
Chapter 12
Ingress
       ↓
Chapter 13
Resources
       ↓
Chapter 14
Probes
       ↓
Chapter 15
HPA
       ↓
Chapter 16
Cluster Autoscaling
       ↓
Chapter 17
Scheduling
       ↓
Chapter 18
Jobs/CronJobs
       ↓
Chapter 19
Security/RBAC
       ↓
Chapter 20
NetworkPolicy
       ↓
Chapter 21
Logging
       ↓
Chapter 22
Monitoring
       ↓
Chapter 23
Troubleshooting
       ↓
Chapter 24
Rollouts/Rollbacks
       ↓
Chapter 25
Helm
       ↓
Chapter 26
Kustomize
       ↓
Chapter 27
Local Kubernetes
       ↓
Chapter 28
AWS EKS
       ↓
Chapter 29
GKE + AKS

You are now moving into the CI/CD and GitOps portion.

🧠 Chapter 29 Cheat Sheet#

AWS
 ↓
EKS
 ↓
ECR
 ↓
IAM
 
GCP
 ↓
GKE
 ↓
Artifact Registry
 ↓
Cloud IAM
 
Azure
 ↓
AKS
 ↓
ACR
 ↓
Entra ID / Azure RBAC

Managed Kubernetes:#

EKS = AWS
GKE = Google Cloud
AKS = Azure

Container registries:#

ECR = AWS
Artifact Registry = GCP
ACR = Azure

Core Kubernetes remains:#

Pod
Deployment
Service
Ingress
ConfigMap
Secret
PVC
HPA
RBAC
NetworkPolicy

Key principle:#

Kubernetes gives you the common orchestration API; cloud providers supply compute, networking, identity, storage, load balancing, and managed services around it.

🚀 Next: Chapter 30 — Kubernetes + CI/CD#

This is a major chapter.

We'll build the complete pipeline:

Developer
    ↓
Git Push
    ↓
GitHub
    ↓
CI Pipeline
    ↓
Run Tests
    ↓
Build Docker Image
    ↓
Push Image to Registry
    ↓
Update Kubernetes
    ↓
Rolling Deployment
    ↓
Readiness Checks
    ↓
Production

We'll specifically build a Node.js + Docker + Kubernetes CI/CD pipeline, including GitHub Actions, image tagging, registries, deployment strategies, secrets, rollback, and production best practices.