В документе упоминается «Каждый кластер GKE имеет сервер API Kubernetes, называемый master . Мастер находится в принадлежащем Google проекте, который отделен от вашего проекта. Он работает на виртуальной машине, которая находится в сети VP C в проекте, принадлежащем Google ». и «В частных кластерах сеть VP C мастера подключена к сети VP C вашего кластера с VP C пирингом сети . Ваша сеть VP C содержит узлы кластера, а отдельная сеть Google Cloud VP C содержит хозяина кластера. ”Вы можете получить доступ к частной конечной точке из ubuntu-vm-xyz, так как она находится в той же сети vp c.
Теперь также объясняется, почему ubuntu-vm-lmn не может достичь конечных точек в частных кластерах. Как уже упоминалось, ваш главный узел находится в управляемом Google проекте, поэтому у вас нет доступа к этому vp c. А в соответствии с документом пиринг vp c требуется три шага:
- Шаг 1: Peer network-a с сетью-b
- Шаг 2 : Peer network-b с network-a
- Шаг 3: VP C Сетевой пиринг становится ACTIVE
Таким образом, вы не можете завершить пиринг vp c с проектом, принадлежащим Google , Также VP C не поддерживает « Транзитивный пиринг ». Поэтому создание пиринга vp c между xyz и lmn не будет работать.
Теперь более простым решением является включение основных авторизованных сетей и добавление вашей сети в aster-авторизованных сетей с помощью документа.
В качестве альтернативы вы можете попытаться создать VM в качестве шлюза NAT между двумя vp c. Но, честно говоря, я не проверял это лично.
Примечание. Я хотел бы опубликовать это в качестве комментария, но из-за ограничения размера сообщения в качестве ответа. Пожалуйста, не стесняйтесь добавлять вопрос или комментарии по этому вопросу, я буду соответствующим образом изменять этот пост.