|
|
|
|
|
|
by inscrutable
2353 days ago
|
|
|
On GKE, you don't need to define node-pools if you tick enable node-autoprovisioning. This is effectively an EKS fargate profile without any of the limitations (discrete node size, inability to mount volumes etc)
On GKE there's no need for bastion hosts, you can connect to private nodes automatically by tunneling through identity-aware-proxy
On GKE, there's no faffing about with aws-auth-configmap, nodes automatically join the cluster
On GKE, you can use regional persistent disks if you need to store state rather than single zone EBS
On GKE, you can use a single static ip for your nginx-ingress load balancer without needing to faff about with AWS global accelerator (which in any case gives you multiple ips)
On GKE, managed node pools are automatically repaired and upgraded with the choice of google's OS or ubuntu unlike Amazon Linux which is currently the only choice for EKS' managed node pools. GKE can automatically use spot instances unlike the farce on AWS with a 3rd party (spotinst) charging a premium for the same functionality
On GKE, managed istio is ticking a box versus a self-install on EKS
On GKE you need to worry much less about ip exhaustion as they use alias ips vs dedicated ENIs for EKS
Associating IAMs with kuberenetes service accounts is much easier with GKE workload identity than with EKS' oidc webhook
GKE has several features which EKS doesn't (calico, vertical pod autoscaling, binary authorisation, export of cluster data to bigquery)
https://www.reddit.com/r/googlecloud/comments/ejxxn5/has_any... |
|
|