There are several options you can follow depending on what you are trying to do and your needs, but if you must use Kong inside each GKE cluster and handle your SSL certs yourself, then:
TCP Proxy LB
(optional) You can deploy GKE NodePorts instead of Load Balancer service for your Kong deployment, since you try to unify all your Kong services, having individual Load Balancer exposing to the public internet can work, but you will be paying for any extra external IP address you are using.
You can manually deploy a TCP Proxy Load Balancer that will use the same GKE Instance Groups and port as your NodePort / current Load Balancer (behind the scenes), you would need to setup each backend for each GKE cluster node pool you are currently using (across the all the GKE clusters that you are deploying your Kong service).
HTTP(S) LB
You can use NodePorts or take advantage (same thing as TCP Proxy LB) from your current Load Balancer setup to use as backends, with the addition of NEGs in case you want to use those.
You would need to deploy and maintain this manually, but you can also configure your SSL certificates here (if you plan to provide HTTPS connections) since client termination happens here.
The advantage here is that you can leave SSL cert renewal to GCP (once configured) and you can also use Cloud CDN to reduce latency and costs, this feature can only be used with HTTP(S) LB as per today.
