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

Вот шаги:

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

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


postgresql google-cloud-platform google-cloud-sql google-cloud-networking
person straimis    schedule 11.10.2018    source источник

Ответы (2)


arrow_upward
4
arrow_downward

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

person Vadim    schedule 12.10.2018
comment
Спасибо @Vadim. Итак, какие у нас есть варианты доступа к Cloud SQL из сети B (вспоминая мой пример)? Я не хочу использовать общедоступный IP-адрес, но мне нужен доступ к Cloud SQL из нескольких сетей GCP, даже из разных проектов GCP. заранее спасибо - person straimis; 14.10.2018
comment
Я не думаю, что в настоящее время есть отличное решение, если вы хотите использовать частный IP в сетях. Вам нужно будет настроить какой-то прокси в сети A для прокси-запросов из сети B. - person Vadim; 15.10.2018
comment
Хорошо, @Vadim, удалось создать Internal Load Balancer для созданного прокси-контейнера. Теперь у меня есть другая проблема: к внутреннему LB можно получить доступ из одноранговой сетевой виртуальной машины, но нельзя получить доступ из однорангового сетевого кластера кубернетов. Как можно разрешить эту ситуацию? - person straimis; 04.03.2019

arrow_upward
4
arrow_downward

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

Получить доступ к прокси-серверу SQL в сети «A» из одноранговой сети «B» виртуальной машины будет просто.

Что касается доступа из кластера 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/.

person Edgarz    schedule 05.03.2019
comment
Привет, пожалуйста, не публикуйте ответы только по ссылкам. Пожалуйста, отредактируйте свой ответ, включив в него соответствующие части ссылки. - person grooveplex; 05.03.2019