CODEWITHSUNDEEP
network-programmingkubernetesgoogle-kubernetes-engine
blits
blits

Reputation: 310

Setting up a VPN with access to multiple GKE k8s pods&services clusters

I want to set up a WireGuard (but Wireguard is not relevant) VPN to make GKE pods&services accessible via that VPN. We have a few clusters, which we want to be accessible via the same VPN connection. E.g.:

In that case, I'll have to create DNS which will rewrite hosts, but I'm just not there yet.

I'm currently stuck because I can't access IPs of those clusters' services and pods (I create an instance with Ubuntu 16 and execute curl http://<some-k8s-service-ip>:<port of that service>/) because of the timeout.

It appears that every cluster is isolated and I basically can't access it outside via Internal IP, even if GCE VPN instance is in the same network as a cluster. For example, I can do, curl http://10.0.26.219:4000/ (this address resolves to a specific k8s service) from inside of a cluster, but I can't do it from the random GCE instance I create (it's in the same network as GKE clusters).

I have set up a firewall rule allowing all ingress&egress traffic to any ports, but it didn't do the trick.

To clarify, everything is located in the same network (eu-north-4) and VPC.

Perhaps anyone had experience with setting such a VPN? Please, let me know if there's information I could provide because there are so many things to consider. Shortly, it's all the defaults except it's private clusters.

Upvotes: 2

Views: 967

Answers (1)

Patrick W
Patrick W

Reputation: 4909

clusterIPs are never accessible from outside a cluster. The reason for this is the clusterIP only exists as a rule in the iptables of the various GKE nodes.

You will need to use either NodePort or LoadBalancer service (the LB would use an internal IP address) to expose your workloads outside the cluster.

You can also reach pod IPs directly, though this is not recommended since pod IPs are not static and will change if the pod is rescheduled for any reason.

Unfortunately, this will not leverage the built in cluster DNS using cluster.local as you mentioned you'd like to do. Instead, you can configure your DNS to resolve specific workloads to specific internal LoadBalancer IPs which will be static.

Upvotes: 3

Related Questions