Как сделать службы GKE видимыми для другого кластера GKE, работающего в другом VPC
Я изо всех сил пытаюсь сделать Сервисы видимыми через пиринг VPC.
У меня есть два кластера GKE (cluster-A а также cluster-B) каждый из них в отдельном VPC.
Я создал пиринг сети VPC, соединяющий оба VPC.
Я следовал инструкциям, чтобы включить ip-masquerade-agent и разрешить кластерам получать доступ к каждому модулю ( https://cloud.google.com/kubernetes-engine/docs/how-to/ip-masquerade-agent)
Дело в том, когда я пытаюсь из cluster-A свернуть стручок в cluster-B это работает, но когда я делаю curl Сервис это не работает.
От стручка, бегущего в cluster-A:
$ curl http://10.132.0.13:8080 # cluster-B Pod
Hello World
$ curl http://10.134.145.111:8080 # cluster-B Service
curl: Connection timed out
Как сделать службы видимыми в обоих кластерах?
Некоторая важная информация, которая может помочь:
Кластер-А
servicesIpv4Cidr: 10.30.0.0/18
clusterIpv4Cidr: 10.32.0.0/11
ip-masq-agent ConfigMap:
apiVersion: v1
kind: ConfigMap
data:
  config: |
    nonMasqueradeCIDRs:
    - 10.32.0.0/11
    - 10.30.0.0/18
    resyncInterval: 60s
    masqLinkLocal: true
metadata:
  name: ip-masq-agent
  namespace: kube-system
Кластер-Б
servicesIpv4Cidr: 10.134.0.0/16
clusterIpv4Cidr: 10.132.0.0/16
ip-masq-agent ConfigMap:
apiVersion: v1
kind: ConfigMap
data:
  config: |
    nonMasqueradeCIDRs:
    - 10.132.0.0/16
    - 10.134.0.0/16
    resyncInterval: 60s
    masqLinkLocal: false
metadata:
  name: ip-masq-agent
  namespace: kube-system
2 ответа
Доступ к одной службе кластера из другого кластера невозможен напрямую, для этого можно использовать балансировщик нагрузки.
Ссылка, которая объясняет это, находится в разделе документации по кластерам и псевдонимам VPC, где говорится:
"IP-адреса кластера для внутренних служб остаются доступными только изнутри кластера. Если вы хотите получить доступ к службе Kubernetes изнутри VPC, но извне кластера (например, из экземпляра Compute Engine), используйте внутренний балансировщик нагрузки ".
Даже если пример ссылается на один и тот же VPC, это также относится к различным VPC, использующим пиринг VPC (поскольку они рассматриваются как "одинаковые" VPC с некоторыми исключениями в качестве транзитивности:
"Только одноранговые сети могут обмениваться данными. Транзитивный пиринг не поддерживается. Другими словами, если сеть N1 VPC одноранговая с N2 и N3, но N2 и N3 также не связаны напрямую, сеть N2 VPC не может обмениваться данными с сетью N3 VPC через всматриваясь ".
не поддерживается Google. GKE всегда создает VPC с «дополнительным переходом», эффективно нарушая любые связи с другими VPC, ни один клиент не имеет к этому никакого отношения, проголосуйте за запрос функции:https://issuetracker.google.com/issues/244483997?pli=1