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