简体   繁体   中英

GKE cross cluster pod-to-pod communication

Simplified project diagram: 简化项目图:

My goal is to allow connection from eu-cluster-b pod micro-service-pod-a send and receive http calls to eu-cluster-a pod micro-service-pod-b. I read about VPC connections (subnets), but I'm not sure exacly what to to in this situation and I would like not to f*** up whole network.

You could use istio for Multi Cloud Burst ( https://codelabs.developers.google.com/codelabs/istio-multi-burst/#0 )

Also if they are on the same project, you would need to make sure that they have different IP ranges and that the range of one subnetwork is routable to the other subnetwork, then use something like https://github.com/kubernetes-sigs/external-dns ,

This will allow you to bring up Internal Load Balancers that will create services of type: Load Balancer but not the public facing one you are probably familar with, but an internal one (subject to quotas of type backend-services), I'll use mongodb service as an example, it would look something like this.

kind: Service
metadata:
  name: "mongodb"
  annotations:
    cloud.google.com/load-balancer-type: "Internal"
    external-dns.alpha.kubernetes.io/hostname: "db.mongodb.myinternaldns.test"
    external-dns.alpha.kubernetes.io/ttl: "10"
  labels:
    app: mongodb
spec:
  ports:
    - name: tcp-mongodb
      port: 27017
      protocol: TCP
      targetPort: 27017
  clusterIP: None
  selector:
    app: mongodb


In the annotations you specify what's the DNS address that you want this service to have, and this is the dns address that will be reachable from both clusters, it will create an A and TXT records on Cloud-DNS with the IP of the Internal Load Balancer, if you make sure that you have the correct route settings traffic will flow between clusters. Hope this helps!

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM