А вообщее в виртуальные машины в этом проекте и в этой сети получается зайти? Может просто проблема в нехватке прав доступа или в настройках firewall?

Хм, перезагрузка была уже после увеличения диска? А что там за операционка?

да

убунта 18

все, через коннект сериал порта удалось подключиться и чуть чуть почистить. далее уже смог обычно подключиться. дальше чищу.  Всем большое спасибо!

)

Пытаюсь решить интересную задачу. Нужно дать доступ сервису, который запущен в GKE, к другому стороннему сервису через vpn тунель. Часть с тунелем решается с помощью Google Cloud VPN - там есть поддержка ipsec2 со всеми нужными настройками. В качестве теста я задеплоил в два разных проекта по одному vpn gateway и связал их тунелем. Сейчас tunel в established. Теперь нужно будет пробовать связать со сторонним сервисом(после подписания документов и обмена shared key для инициации подключения).  Возникли такие вопросы:
1. Правильно ли я сделал что подключил vpn gateway в туже сеть что используется для GKE кластера?
2. Как мне теперь пофильтровать чтобы подключения было разрешено инициировать только со стороны моего кластера?
3. Еще не совсем понимаю как работают forwarding rule, которые необходимы для vpn gateway. Без трех правил (udp:500, udp:4500, esp) тунель вообще не создавался. Мне теперь нужно какие-то правила сделать чтобы нормально форвардить трафик на сторонний сервис или для этого достаточно уже созданного роутинга удаленной подсети на vpn gateway?

Для чего нужны fw правила уже разобрался, пока оптимизировал terraform код

Другой сторониий сервис тоже находится в GCP или on-prem/other-cloud ?

хорошее чтиво: https://cloud.google.com/solutions/best-practices-vpc-design

Другой даже не в клауде

1. Лишь бы это не была default сеть. В принципе сойдет для начала, если у вас не планируется какого-то бурного роста и много других сервисов, которым в будущем также потребуется доступ к внешнему сервису.  
2.  запретить все исходящие соединения правилом с низким приоритетом, разрешить все исходящие с вашего кластера правилом с высоким приоритетом. Все входящие по умлочанию запрещены.
3. Если пакеты роутятся - этого д.б. достаточно

Если будете рассти дальше - копайте в сторону: https://cloud.google.com/vpc/docs/shared-vpc#hybrid_cloud_scenario и https://cloud.google.com/solutions/best-practices-vpc-design#scale-hub-spoke

Еще пожалуй выставить custom advertising на роутере: https://cloud.google.com/network-connectivity/docs/router/concepts/overview#custom

А группу на уровне проекта нельзя создать? Только на уровне организации?

заехать на shared vpc с существующим GKE кластером будет тяжело. придётся создавать новый кластер и мигрировать туда.

В связке GKE + L2 balancer + nginx-ingress чтобы увидеть внешний айпи поменял в сервисе ингрес контроллера externalTrafficPolicy на Local. Теперь получается мне нужно сделать чтобы под ингрес контроллера был запущен на каждой ноде в кластере? Еще что-то упускаю?

не обязательно на каждой ноде запускать. посмотри health checks у L2 и как он определяет можно ли отправлять трафик в pod или нет.

мы отказались от L2 XLB как раз из-за health checks. задать их нельзя, но можно вручную поменять. проблема в том, что HC делает несколько чеков раз в скольк-то секунд. и только если зафейлились все эти чеки трафик перестаёт идти в pod. а до этого L2 XLB будет отправлять трафик в мертвичину.

лучше использовать L7 CNLB -- он фактически использует readiness probe для отправки трафика в pod.

Но по сути чеки один раз после нового деплоймента пофейлятся и потом при нормально работе трафик будет правильно всегда идти. Опять же пока я nginx-ingress не передеплою и его под не попадет на другую ноду. Спасибо за ответ

ну, это если у тебя ещё node pool не скейлится. при up-scale всё хорошо. при down-scale будут проблемы.