Как сделать службы 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

Другие вопросы по тегам