I don’t think the status listen will work–as best I recall, the issue is that the GKE ingress controller essentially ignores readiness/liveness configuration entirely, and performs its check against
/ on all services.
It’s possible to work around this for the proxy by initially spawning Kong with an admin API listen only and configuring a route matching it with the request-terminator plugin, but I still wouldn’t recommend it. Doing so requires that you duplicate configuration in some fashion, either by creating the Ingress resource for GKE and then configuring Kong routes manually or creating two sets of Ingresses, one for GKE which points to Kong and one for Kong’s controller which points to the actual Service. Using our controller only is preferable in the majority of circumstances.
What do you want to use the GKE controller for? The most common reason I’ve encountered is that users want to use Google’s WAF, which requires using their HTTP load balancer. For those cases we’ve recommended using our controller to spawn a TCP load balancer at the K8S level and then spawning a GCP HTTP load balancer outside of K8S, targeting it at the TCP load balancer address.
Spawning an HTTP load balancer to satisfy Kong’s LoadBalancer Service directly would be preferable, but as best we know GKE doesn’t provide this option.