Google PCNE: Архитектура VPC, подсети и планирование адресного пространства — Руководство по подготовке

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Часть Google Professional Cloud Network Engineer — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Google, или пройдите тесты на время на ExamRoll.io.

Обзор

Virtual Private Cloud (VPC) — это глобальная, логически изолированная сеть, охватывающая все регионы Google Cloud. Подсети — это региональные ресурсы в составе VPC, которые содержат диапазоны IP-адресов для Compute Engine, GKE и других ресурсов. Продуманная архитектура VPC обеспечивает баланс между эффективным использованием адресного пространства, возможностью роста и операционным контролем, а также гарантирует низкую задержку и экономичную связность для рабочих нагрузок внутри одного и между несколькими проектами, а также для доступа к Google API.

Область действия VPC, архитектура подсетей и режимы

• Глобальная VPC, региональные подсети

  • Одна VPC охватывает все регионы. Подсети создаются для каждого региона и определяют основные диапазоны IPv4 в нотации CIDR, а также необязательные вторичные диапазоны. Экземпляры получают IP-адреса из региональных подсетей, но по умолчанию могут обмениваться данными между регионами в пределах одной VPC по приватным каналам.
  • Режим динамической маршрутизации
    • Региональный (Regional): Cloud Routers обмениваются маршрутами только с подсетями в своем регионе.
    • Глобальный (Global): Cloud Routers в одном регионе анонсируют изученные маршруты во все регионы. Глобальный режим предпочтителен, когда требуются межрегиональные рабочие нагрузки или высокодоступный (HA) исходящий трафик.

• Режим Auto и пользовательский режим (custom)

  • Режим Auto создает по одной подсети в каждом регионе с предопределенными CIDR-диапазонами. Он удобен для быстрого старта, но негибок при масштабировании. Его можно преобразовать в пользовательский режим; преобразование является односторонним.
  • Пользовательский режим (Custom mode) предоставляет полный контроль над созданием подсетей и выбором CIDR-диапазонов. Это рекомендуемый подход для планирования адресного пространства в производственных средах, для Shared VPC, пиринга и дальнейшего роста.
  • Примечание по миграции: после преобразования из режима auto в custom артефакты или шаблоны, которые были рассчитаны на подсети режима auto, часто перестают работать до тех пор, пока их явно не обновят для использования пользовательских подсетей.

• Неизменяемость и расширение подсетей

  • Регион подсети неизменяем; переместить подсеть между регионами невозможно.
  • Основные диапазоны IPv4 можно расширять на месте (уменьшая длину префикса), но нельзя сужать. Они не должны пересекаться с другими диапазонами в VPC и любых подключенных сетях.
  • Вторичные диапазоны можно добавлять или удалять (если они не используются), и они также не должны пересекаться с другими диапазонами.

Планирование адресного пространства: основные/вторичные диапазоны, IP-псевдонимы, IPv6 и частное пространство

• Основные и вторичные диапазоны IPv4

  • Основной диапазон (Primary range): назначает адреса интерфейсам ВМ (по умолчанию nic0). Для него создается системный маршрут подсети, и он используется для большей части внутреннего трафика.
  • Вторичные диапазоны (Secondary ranges): связывают с подсетью дополнительные CIDR-диапазоны и необходимы для кластеров GKE в режиме VPC-native. Системные маршруты для вторичных диапазонов обеспечивают внутреннюю связность (east-west) для подов (Pods) и сервисов (Services).

• IP-псевдонимы (Alias IPs)

  • IP-псевдонимы позволяют сетевому интерфейсу (NIC) ВМ иметь несколько IP-адресов из основного или вторичных диапазонов подсети. Это обеспечивает возможность применения строгих политик на основе IP, выделение IP-адресов для подов в GKE (VPC-native) и эффективное использование IP-пространства.
  • Для GKE планируйте большие непрерывные вторичные CIDR-диапазоны, чтобы минимизировать фрагментацию и избежать изменения размера в будущем. Пример: для 100 узлов с 200 подами на узел и 1500 сервисами выделите вторичный диапазон для подов не менее /17 и для сервисов — /21, чтобы оставить запас для роста.

• Проектирование частного пространства RFC 1918 и управление IP-адресами

  • Выбирайте непересекающиеся блоки адресов для всех текущих и планируемых VPC, локальных сетей (on-premises) и сетей партнеров. Резервируйте крупные родительские блоки для каждой среды, а затем выделяйте из них предсказуемые подблоки для каждого региона и функционального назначения.
  • Резервируйте емкость для роста, вторичных диапазонов, буферов миграции (временный dual-stack/double NAT) и конечных точек инфраструктуры (VIP-адреса ILB, конечные точки PSC).
  • Избегайте использования самых распространенных корпоративных блоков адресов, если вероятны подключения к сетям партнеров; в противном случае используйте сегментацию с помощью NAT для разрешения конфликтов.

• Планирование IPv6

  • Внешний IPv6 (External IPv6): используйте глобальные внешние IPv6-адреса на глобальных балансировщиках нагрузки для клиентского доступа и доступности по технологии anycast.
  • Внутренний IPv6 (Internal IPv6): там, где это возможно, включайте подсети с двумя стеками (dual-stack), чтобы назначать внутренние IPv6-адреса виртуальным машинам, и соответствующим образом корректируйте правила брандмауэра. Планируйте DNS-записи типа AAAA и обеспечивайте паритет с политиками для IPv4.
  • Сохраняйте IPv4 для управления внутри облака и интеграции со сторонними системами; внедряйте IPv6 постепенно через балансировщики нагрузки и подсети с двумя стеками.

Маршрутизация: неявные маршруты, пользовательские маршруты, приоритеты, теги и следующие переходы

• Неявные (сгенерированные системой) маршруты

  • Маршруты подсетей: по одному на основную подсеть и на каждый дополнительный диапазон; назначение равно CIDR-диапазону, следующий переход — сама подсеть.
  • Маршрут по умолчанию: маршрут 0.0.0.0/0 к шлюзу интернета по умолчанию создается автоматически; для исходящего трафика в интернет требуется внешний IP-адрес или NAT.

• Пользовательские маршруты и логика выбора

  • Выбирается маршрут с самым длинным совпадающим префиксом. Если у нескольких маршрутов одинаковая длина префикса, выбирается маршрут с наименьшим значением приоритета (приоритет по умолчанию — 1000).
  • Теги и сервисные аккаунты
    • Маршруты без тегов применяются ко всем ВМ. Маршруты, ограниченные тегами, применяются только к экземплярам с соответствующими сетевыми тегами.
    • Правила брандмауэра на основе идентификаторов могут сопоставляться с сервисными аккаунтами; используйте их для более гранулярного контроля, чем теги, где это возможно.

• Следующие переходы (Next hops)

  • Поддерживаемые следующие переходы для пользовательских маршрутов включают:
    • Шлюз интернета по умолчанию (0.0.0.0/0 или более специфичные исходящие префиксы)
    • Экземпляр (требует включения IP forwarding для маршрутизации трафика для других; используется для виртуальных устройств)
    • Туннель Cloud VPN (статические маршруты)
    • Региональный внутренний балансировщик нагрузки в качестве следующего перехода (для масштабируемых паттернов с виртуальными устройствами)
  • Нельзя установить в качестве следующего перехода пиринговое соединение VPC; пиринг самостоятельно управляет обменом маршрутами.

• Пример управления трафиком (виртуальное устройство)

  • Создайте более специфичный маршрут, чем маршрут подсети, со следующим переходом на экземпляр с включенным IP forwarding, ограниченный тегами на исходных ВМ.
  • Пример:
    • gcloud compute routes create app-egress –network=prod-vpc –destination-range=0.0.0.0/0 –next-hop-instance=fw-appliance –next-hop-instance-zone=us-west1-a –priority=800 –tags=egress-via-fw

• Исходящий трафик к Google API без внешних IP-адресов

  • Вариант 1: Включите Private Google Access (PGA) в подсетях, затем добавьте пользовательские маршруты для VIP-адресов Google API к шлюзу интернета по умолчанию, чтобы при необходимости обойти сторонний путь для исходящего трафика по умолчанию.
  • Вариант 2: Используйте Cloud NAT с PGA, чтобы обеспечить исходящий трафик для частных ВМ к сервисам Google.
  • Вариант 3: Используйте Private Service Connect для Google API для доступа без использования интернета; трафик остается в сети Google и использует частную конечную точку (RFC1918) в вашей VPC.
  • Для ограниченного доступа направьте клиентов на VIP-адреса ограниченного доступа Google API и примените средства контроля исходящего трафика.

Shared VPC, пиринг, делегированное администрирование и сервисные аккаунты

• Shared VPC

  • Хост-проект владеет одной или несколькими централизованно управляемыми сетями VPC и подсетями. Сервисные проекты подключают рабочие нагрузки к выбранным общим подсетям.
  • Делегированное администрирование
    • Администратор Shared VPC (Shared VPC Admin) настраивает подключения и совместное использование подсетей.
    • Сетевые администраторы (Network Admins) управляют маршрутами, подсетями и брандмауэром в хост-проекте.
    • IAM на уровне проекта в сервисных проектах контролирует развертывание рабочих нагрузок; вы можете предоставлять доступ только к необходимым подсетям, чтобы ограничить радиус поражения (blast radius) и видимость маршрутов.
  • Сервисные аккаунты
    • Предпочитайте политики брандмауэра на основе сервисных аккаунтов для детерминированного контроля на основе идентификаторов между командами.
    • Используйте выделенные сервисные аккаунты для каждого уровня и среды с ролями с минимальными привилегиями для доступа к данным (например, предоставьте роль Storage Object Viewer сервисному аккаунту, который читает данные из Cloud Storage).

• VPC Network Peering

  • Ограничения
    • Нетранзитивность: соединение A↔B и B↔C не означает наличие соединения A↔C. При необходимости создайте полносвязную топологию (full mesh).
    • В пиринговых сетях не должно быть пересекающихся IP-диапазонов.
    • Обмен ограничен маршрутами подсетей (включая дополнительные диапазоны); управление трафиком через следующий переход (next-hop steering) через пиринг не поддерживается.
  • Используйте пиринг для частного внутриорганизационного подключения с низкой задержкой и минимальными операционными издержками, когда отдельные сети VPC должны оставаться административно разделенными.

• Гибридное подключение

  • Централизуйте Dedicated Interconnect и Cloud Router в хост-проекте Shared VPC, чтобы предоставить высокопроизводительное подключение сервисным проектам подразделений.
  • Используйте высокодоступные подключения VLAN (HA VLAN attachments), географически распределенные точки подключения (edge locations), два Cloud Router и глобальную динамическую маршрутизацию для обеспечения отказоустойчивости и распространения маршрутов во все необходимые регионы.

Операции: расширение, высокая доступность, частный доступ, проверка и устранение неполадок

• Ограничения на расширение и миграцию подсетей

  • Расширяйте на месте, когда подсеть приближается к исчерпанию ёмкости; проверьте все подключенные сети на отсутствие пересечений и убедитесь, что зависимые вторичные диапазоны GKE остаются достаточными.
  • Если диапазоны пересекаются между организациями или партнерами, используйте NAT или поэтапную перенумерацию. Нельзя устанавливать пиринговое соединение между пересекающимися VPC или устанавливать пересекающиеся динамические маршруты.

• Региональное размещение и высокая доступность

  • Размещайте подсети в регионах, ближайших к пользователям и данным. Для пользователей по обе стороны Атлантики единая VPC с региональными подсетями в us-east1 и europe-west1 обеспечивает прямое частное подключение с оптимальной задержкой и нулевой платой за исходящий трафик внутри VPC.
  • Распределяйте рабочие нагрузки по зонам; используйте региональные группы управляемых экземпляров и региональные внутренние/внешние балансировщики нагрузки для отказоустойчивости на уровне зон.
  • Для гибридной среды развертывайте по два Cloud Router и подключения на регион или пограничную точку; включайте BFD, где это поддерживается; используйте глобальную динамическую маршрутизацию для аварийного переключения.

• Частный доступ к Google и ограниченные эндпоинты

  • Включите PGA на подсетях, где размещены экземпляры без внешних IP-адресов.
  • Чтобы запретить общий исходящий трафик в интернет, но разрешить доступ к Google API:
    • Направьте трафик по умолчанию на ваш NGFW.
    • Добавьте более конкретные статические маршруты для VIP-адресов Google API к шлюзу интернета по умолчанию или разверните эндпоинты PSC для Google API.

  • Пример:

undefined

• Проверка топологии и устранение неполадок
  • Используйте Network Intelligence Center:
    • Connectivity Tests для проверки доступности и симуляции решений по маршрутизации, брандмауэру и шлюзам.
    • Performance Dashboard и Topology для визуализации путей и состояния работоспособности.
  • Логи и телеметрия:
    • VPC Flow Logs для наблюдения за разрешенными/запрещенными соединениями и задержкой на каждом интерфейсе.
    • Firewall Rules Logging для подтверждения срабатывания правил.
    • Логи и состояние работоспособности Cloud NAT для проблем с исходящим трафиком без внешних IP.
    • Логи балансировщика нагрузки и проверок работоспособности для определения готовности бэкендов.

  • Проверки через CLI:

undefined

и

undefined

для подтверждения действующей политики. -

undefined

и

undefined

с тестовых ВМ; используйте Packet Mirroring для глубокого анализа, когда это необходимо.

Практический сценарий проблемы

Acme Retail Group требуется многорегиональная сеть Google Cloud с низкой задержкой, централизованным управлением, доступом к Google API для частных экземпляров без выхода в интернет и строгой изоляцией между отделами, которым не требуется взаимодействовать. Некоторые команды используют GKE с высокой плотностью подов. Acme также направляет общий исходящий трафик через сторонний брандмауэр, но хочет, чтобы трафик к Google API обходил этот брандмауэр.

1. Создайте единую Shared VPC в хост-проекте в пользовательском режиме с глобальной динамической маршрутизацией и создайте региональные подсети в us-east1 и europe-west1 с зарезервированными вторичными диапазонами для GKE.

• Обоснование: Одна VPC обеспечивает частное, бесплатное, межрегиональное подключение по адресам RFC1918 для оптимальной эффективности. Пользовательский режим и глобальная динамическая маршрутизация поддерживают точное планирование IP-адресов и распространение маршрутов между регионами.

2. Предоставьте совместный доступ только к необходимым подсетям для сервисного проекта каждого отдела; создайте три сервисных проекта (Sales, Finance, Marketing) и откройте доступ каждому только к требуемым подсетям.

• Обоснование: Совместное использование на уровне отдельных подсетей ограничивает радиус поражения и видимость маршрутов, обеспечивая изоляцию и позволяя централизованно управлять операциями. Делегированный IAM позволяет центральным сетевым администраторам управлять брандмауэрами и маршрутами, в то время как команды приложений развертывают рабочие нагрузки независимо.

3. Для отделов, которые должны взаимодействовать, установите пиринговое соединение между их выделенными VPC или разместите их в одних и тех же подсетях Shared VPC; для изолированных отделов воздержитесь от пиринга и не предоставляйте доступ к пересекающимся подсетям.

• Обоснование: Пиринг обеспечивает частное подключение с низкой задержкой и минимальными операционными издержками. Нетранзитивность требует явных соединений по типу «сетка» (mesh) только там, где это необходимо, что по умолчанию сохраняет изоляцию.

4. Включите Private Google Access на всех общих подсетях и разверните эндпоинты Private Service Connect для Google API; сохраните маршрут по умолчанию к стороннему брандмауэру, а также добавьте более конкретные статические маршруты для VIP-адресов Google API к шлюзу интернета по умолчанию.

• Обоснование: PGA и PSC обеспечивают использование API с частных ВМ без выхода в интернет. Более конкретные маршруты гарантируют, что трафик к API обходит NGFW, в то время как остальной исходящий трафик в интернет продолжает идти по пути проверки.

5. Выделите первичные и вторичные CIDR с запасом для роста: для GKE выделите вторичный диапазон для подов (например, /17) и вторичный диапазон для сервисов (/21) для каждого загруженного региона; используйте alias IP для подов и сервисов и создайте VPC-нативные кластеры, привязанные к этим диапазонам.

• Обоснование: Вторичные диапазоны и alias IP предотвращают исчерпание IP-адресов узлов и позволяют плотное размещение. Задание размеров с учетом будущего спроса позволяет избежать разрушительного изменения размеров и перенумерации вторичных диапазонов.

6. Реализуйте высокую доступность для гибридного трафика и трафика через виртуальные устройства: разверните по два Cloud Router и HA VPN или Interconnect по мере необходимости; там, где требуется направление трафика через виртуальное устройство, используйте более конкретный пользовательский маршрут со следующим переходом (next hop), установленным на региональный внутренний балансировщик нагрузки или на экземпляр с включенной IP-пересылкой и областью действия, ограниченной тегами.

• Обоснование: Высокая доступность на границе сети обеспечивает непрерывность работы во время сбоев. Ограничение области действия маршрутов по тегам позволяет избежать случайного «заворачивания» трафика (hairpinning) и разрешает только выбранным экземплярам проходить через виртуальное устройство.

7. Проверяйте и управляйте с помощью Connectivity Tests в Network Intelligence Center, VPC Flow Logs и Firewall Rules Logging; применяйте политики брандмауэра на основе идентификаторов, используя сервисные аккаунты, и ведите учет IP-адресов (IPAM) с зарезервированными буферами для каждого региона и функции.

• Обоснование: Проактивная проверка предотвращает сбои во время изменений. Политики на основе идентификаторов более надежны, чем подходы, основанные только на тегах. Дисциплина в управлении IP-адресами (IPAM) предотвращает пересечения, которые могут заблокировать пиринг или подавить полученные маршруты.

Все домены · Политики брандмауэра →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →

Просмотреть Google →