{"id":82827,"date":"2026-09-21T09:27:19","date_gmt":"2026-09-21T03:57:19","guid":{"rendered":"https:\/\/tothenewco.pro\/blog\/?p=82827"},"modified":"2026-09-29T13:11:00","modified_gmt":"2026-09-29T07:41:00","slug":"getting-traffic-into-kubernetes-aws-vs-gcp","status":"publish","type":"post","link":"https:\/\/tothenewco.pro\/blog\/getting-traffic-into-kubernetes-aws-vs-gcp\/","title":{"rendered":"Getting traffic into Kubernetes: AWS vs GCP"},"content":{"rendered":"

Why a GKE Ingress can look fine in kubectl and still have no IP \u2014 and how that differs from EKS and ALB<\/h2>\n

If you have used EKS, HTTP Ingress usually means an Application Load Balancer. Someone installs the AWS Load Balancer Controller, you set ingressClassName: alb<\/code>, and AWS creates an ALB. Certificates often come from ACM. HTTP and HTTPS are listeners on that ALB.<\/p>\n

GKE can look the same in YAML (kind: Ingress<\/code>) and behave totally differently. On GKE, external Ingress with class gce<\/code> is handled by GLBC<\/span> (the GCE L7 \/ Ingress controller). It does not create an AWS-style ALB. It creates a Google HTTP(S) load balancer: forwarding rules, a URL map, backends, and often NEGs<\/span> (network endpoint groups) instead of instance groups.<\/p>\n

Same Kubernetes API. Different cloud object.<\/strong> That is why copying an EKS Ingress into GKE and hoping is a bad idea. We learned that the hard way: Ingress objects applied fine, Helm said success (or timed out), and there was still no IP.<\/p>\n

The one-line map<\/h2>\n

HTTP(S) to pods<\/p>\n\n\n\n
AWS \/ EKS<\/strong>
\nALB plus target groups<\/td>\n		GCP \/ GKE<\/strong>
\nGCE Ingress plus URL map plus backends<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Ingress class<\/p>\n\n\n\n
AWS \/ EKS<\/strong>
\nalb<\/code> \u2014 controller you install<\/td>\n		GCP \/ GKE<\/strong>
\ngce<\/code> \u2014 GLBC; the class must exist<\/strong> in the cluster<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

TLS certificate<\/p>\n\n\n\n
AWS \/ EKS<\/strong>
\nACM ARN on the Ingress or annotations<\/td>\n		GCP \/ GKE<\/strong>
\nPre-shared Google cert name<\/strong> on the Ingress<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

HTTPS only<\/p>\n\n\n\n
AWS \/ EKS<\/strong>
\nNo HTTP listener, or redirect 80 to 443<\/td>\n		GCP \/ GKE<\/strong>
\nAnnotation so GLBC does not create HTTP port 80<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

TLS strength<\/p>\n\n\n\n
AWS \/ EKS<\/strong>
\nALB SSL policy<\/td>\n		GCP \/ GKE<\/strong>
\nGCP SSL policy via FrontendConfig, not only an annotation<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Point at pods<\/p>\n\n\n\n
AWS \/ EKS<\/strong>
\nTarget group to instances or IPs<\/td>\n		GCP \/ GKE<\/strong>
\nNEG on the Service (ingress: true<\/code>)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Internal only<\/p>\n\n\n\n
AWS \/ EKS<\/strong>
\nInternal ALB or NLB<\/td>\n		GCP \/ GKE<\/strong>
\nClass gce-internal<\/code> (regional IP)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Nginx is a third option.<\/strong> A controller Deployment plus its own LoadBalancer Service can show CLASS <none> and still work. That is not GCE Ingress. Mixing them in your head is how you debug the wrong IP.<\/p>\n

What we had<\/h2>\n

Each app Helm chart could create its own Ingress. Every CD run did helm upgrade<\/code>. So:<\/p>\n

    \n
  • The load balancer was the same Google LB family, not a fresh one each time.<\/li>\n
  • SSL settings we fixed in Console vanished on the next deploy.<\/li>\n
  • Port 80 stayed up even though we only wanted HTTPS.<\/li>\n
  • Path routing (\/api<\/code>, \/mobile<\/code>) lived in the UI chart. Two charts owning one hostname caused conflicts.<\/li>\n<\/ul>\n

    We moved hosts, certs, HTTPS-only settings, and SSL policy into a shared ingress repo<\/span>. App charts only ship Deployment and Service. On the Service we kept:<\/p>\n

    cloud.google.com\/neg: ‘{“ingress”: true}’<\/p>\n

    On AWS that is closer to \u201cthis Service should be a target group for the ALB.\u201d On GKE it means \u201cuse container-native load balancing.\u201d It is not an Ingress. Leave it on the app Service.<\/p>\n

    Failure 1: Ingress in the cluster, no address<\/h2>\n

    kubectl get ingress -n app-ns<\/code> showed the resource. No IP in status.loadBalancer<\/code>.<\/p>\n

    On AWS, if the ALB controller is not installed, you notice quickly. On GKE the controller is usually already running, but it only binds Ingresses whose IngressClass it owns.<\/p>\n

    kubectl get ingressclass<\/p>\n

    If gce<\/code> is missing, ingressClassName: gce<\/code> is a dangling pointer. No VIP.<\/p>\n

    We used a Helm option like ensureGceIngressClass: true<\/code> on the cluster that had no gce<\/code> class. It creates:<\/p>\n

      \n
    • IngressClass named gce<\/code><\/li>\n
    • controller k8s.io\/ingress-gce<\/code> (the official GCE IngressClass controller string)<\/li>\n
    • helm.sh\/resource-policy: keep<\/code> so uninstall does not delete a cluster-wide class<\/li>\n<\/ul>\n

      Do not enable that flag<\/strong> on a cluster where gce<\/code> already exists. You will fight apply conflicts. Also do not mix gce<\/code> and gce-internal<\/code> on one Ingress \u2014 that is like putting internet-facing and internal scheme on the same ALB.<\/p>\n

      Failure 2: TLS policy reset after Helm<\/h2>\n

      On AWS you set an SSL policy on the ALB listener. Terraform or Helm usually owns it.<\/p>\n

      On GKE we set an SSL-policy annotation on the Ingress. It looked right in Console, then fell back after the next Helm upgrade. Google\u2019s supported way to keep the policy is a FrontendConfig, not that annotation alone. What stuck:<\/p>\n

      apiVersion: networking.gke.io\/v1beta1
      \nkind: FrontendConfig
      \nmetadata:
      \nname: example-app-frontend
      \nspec:
      \nsslPolicy: example-tls-policy<\/p>\n

      Hook that FrontendConfig on the Ingress. The policy itself is a GCP resource in the same project<\/strong> as the load balancer. Same idea as ACM and ALB in the same account and region.<\/p>\n

      Failure 3: HTTP still listening<\/h2>\n

      On AWS: no HTTP listener, or a listener that only redirects to 443.<\/p>\n

      GKE default is still to create HTTP port 80 unless you set:<\/p>\n

      kubernetes.io\/ingress.allow-http: “false”<\/p>\n

      Then it is HTTPS only. There is no magic redirect on port 80 if port 80 is not there.<\/p>\n

      Failure 4: certificates<\/h2>\n

      AWS: ACM cert ARN, often alb.ingress.kubernetes.io\/certificate-arn<\/code>.<\/p>\n

      GKE (our setup): Google-managed or pre-shared cert resource name:<\/p>\n

      ingress.gcp.kubernetes.io\/pre-shared-cert: “<cert-resource-name>”<\/p>\n

      The cert must exist in that project. The hostname on the Ingress must be on the cert. dev.app.example.com<\/code> is not the same as test.app.example.com<\/code>. Changing a string in YAML does not create a cert.<\/p>\n

      First create of cert plus Google HTTPS LB is slow. Helm --wait<\/code> can hit context deadline exceeded<\/span> while the Deployment is fine. Check the Ingress IP before you blame the app. Same class of problem as waiting for an ALB to become active, except Google\u2019s first LB is often slower.<\/p>\n

      Helm –atomic made a mess<\/h2>\n

      We pulled Ingress out of the app chart. A failed upgrade rolled back to an old revision that still had an Ingress with class gce<\/code>. The cluster had no IngressClass named gce<\/code>, so rollback failed with: no IngressClass with the name “gce”<\/span>. The first error was often just a wait timeout. Fix the class (or do not roll back onto old Ingress YAML) before you chase Helm.<\/p>\n

      How we run it now<\/h2>\n\n\n\n
      APP REPO<\/strong>
      \nDeployment, Service, NEG annotation, secrets. No Ingress.<\/td>\n      		INGRESS REPO<\/strong>
      \nHostname, cert, HTTPS-only, SSL policy, paths.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

      IngressClass gce<\/code>: once per cluster, if missing. App CD should not render Ingress. A leftover template that reads .Values.ingress.version<\/code> when ingress<\/code> is not set will fail Helm with a nil pointer. Delete the template or default the value.<\/p>\n","protected":false},"excerpt":{"rendered":"

      Why a GKE Ingress can look fine in kubectl and still have no IP \u2014 and how that differs from EKS and ALB If you have used EKS, HTTP Ingress usually means an Application Load Balancer. Someone installs the AWS Load Balancer Controller, you set ingressClassName: alb, and AWS creates an ALB. Certificates often come […]<\/p>\n","protected":false},"author":1502,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":3,"footnotes":""},"categories":[2348],"tags":[4333,248,825,1916,1891,1892,5301,8968,6362,8427,8966,6259,1220,8965,8969,3965,6200,1898,7723,824,8967],"class_list":["post-82827","post","type-post","status-publish","format-standard","hentry","category-devops-technology","tag-alb","tag-aws","tag-certificates","tag-cloud","tag-containers","tag-devops","tag-eks","tag-frontendconfig","tag-gcp","tag-gke","tag-glbc","tag-helm","tag-https","tag-ingress","tag-ingressclass","tag-kubernetes","tag-loadbalancing","tag-networking","tag-sre","tag-ssl","tag-tls"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t