Не удается получить доступ к Google Cloud SQL с частным IP-адресом из одноранговой сети VPC - PullRequest
0 голосов
/ 11 октября 2018

Это шаги:

  • В «Проекте А» у меня есть «сеть А» с частным IP-адресом postgresql.
  • Может получить доступ к postgresql из виртуальной машины, существующей в том же самом«сеть A» через частный IP.
  • Создайте новую «сеть B» в том же «Проекте A»
  • Создайте «одноранговый узел сети VPC» между «сетью A» и «сетью B»
  • Полностью открытый брандмауэр
  • Не удается связаться с postgresql из "сети B", хотя может пинговать виртуальную машину, существующую в "сети A"

Почему я не могудостичь postgresql?Это потому, что частный IP-адрес SQL находится в бета-режиме, или мне здесь чего-то не хватает?

Ответы [ 2 ]

0 голосов
/ 05 марта 2019

Да, прокси-сервер - это путь, упомянутый в предыдущем ответе, потому что пиринг не транзитивен.

Доступ к прокси-серверу SQL в сети "A" из одноранговой сети "B" будет простым.VM.

Что касается доступа из кластера Kubernetes в сети "B", то здесь возможен один подводный камень.По умолчанию Kubernetes не будет использовать трафик SNAT, предназначенный для 10.0.0.0/8, и попытается сохранить его локальным.Таким образом, вам нужно изменить правила iptables на экземплярах хоста, чтобы они могли выходить наружу.

Постоянное решение - настроить DaemonSet, но вы можете проверить эту теорию, сначала вручную изменив хост.Например:

iptables -A POSTROUTING -d 10.11.0.0/24 \
   -m addrtype ! --dst-type LOCAL -j MASQUERADE -t nat

Вот ссылка на превосходное, простое руководство https://blog.mrtrustor.net/post/iptables-kubernetes/.

0 голосов
/ 13 октября 2018

Облачный SQL Частный IP-доступ настраивается через пиринг, поэтому сеть А является пиринговой с сетью Z, которая содержит ваш экземпляр Cloud SQL.Когда вы просматриваете A с помощью B, B не имеет доступа к сети Z.

...