Google PCNE: GKE, контейнеры и сетевое взаимодействие приложений — Руководство по подготовке

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

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

Обзор

Google Kubernetes Engine (GKE) тесно интегрирован с сетевыми возможностями Google Cloud. Проектирование с учётом надёжности и безопасности требует понимания VPC-native IP-адресации, частных плоскостей управления, исходящего трафика (egress), трафика север-юг и восток-запад, применения политик и многокластерных конструкций. В этом разделе представлены рекомендации по проектированию, операционные обоснования и распространённые сценарии сбоев для контейнеров и сетевого взаимодействия приложений в Google Cloud.

IP-архитектура GKE и частные кластеры

Кластеры VPC-native

• Используют дополнительные IP-адреса (alias IPs) с двумя дополнительными диапазонами в подсети VPC: один для подов (PodCIDR) и один для сервисов (ServiceCIDR). Это позволяет избежать SNAT на основе iptables на узлах, обеспечивает нативную для контейнеров балансировку нагрузки с помощью NEG и лучше масштабируется по сравнению с кластерами на основе маршрутов.
• Рекомендации по определению размеров:
  • Поды: выделите PodsPerNode × MaxNodes, плюс запас (20–30%). Например, текущие 10 узлов × 20 подов + рост до 100 × 200 предполагает диапазон для подов /17; для сервисов часто достаточно диапазона /21 для 2000+ сервисов.
  • Сервисы: каждый ClusterIP потребляет один IP-адрес; учтите запас для миграций с headless на ClusterIP и для дополнений (add-ons).
• Сценарии сбоев:
  • Исчерпание IP-адресов для подов: поды остаются в состоянии Pending или появляются ошибки CNI/IPAM; расширьте дополнительный диапазон для подов или уменьшите максимальное количество подов на узел, затем пересоздайте узлы.
  • Исчерпание IP-адресов для сервисов: новые сервисы не могут получить ClusterIP; расширьте дополнительный диапазон для сервисов.
  • Пересечение диапазонов alias IP: создание кластера завершается сбоем или возникают «чёрные дыры» в маршрутизации; убедитесь в отсутствии пересечений с другими подсетями или сопряжёнными (peered) VPC.

Частные кластеры, доступ к плоскости управления и исходящий трафик узлов

• Частные кластеры ограничивают конечную точку плоскости управления частным адресом из диапазона RFC1918, доступным только из вашей VPC через producer peering. Узлам не требуются внешние IP-адреса.
• Для операторов доступны следующие варианты:
  • Только частная конечная точка (private endpoint): плоскость управления доступна из подсетей VPC и подключённых сетей. Для доступа используйте bastion-хост или Cloud Shell с Private Service Connect.
  • Публичная конечная точка с авторизованными сетями (Authorized Networks): плоскость управления доступна по публичному IP-адресу, доступ к которому ограничен определёнными исходными CIDR. Это удобно, но увеличивает поверхность атаки; используйте только с жёстким ограничением CIDR и строгим контролем идентификации администраторов.
• Исходящий трафик узлов (egress):
  • Для узлов без внешних IP-адресов обеспечьте исходящий трафик в интернет через Cloud NAT. Это позволяет обновлять ОС, загружать образы контейнеров из внешних реестров и получать доступ к API партнёров, сохраняя узлы приватными.
  • Для доступа к Google API, а также Artifact/Container Registry без внешних IP-адресов, включите Private Google Access (PGA) в подсетях узлов. PGA разрешает и направляет трафик к Google API/реестрам на пограничные узлы Google без использования публичных исходных IP-адресов. PGA является предпочтительным способом для загрузки образов; комбинируйте его с Cloud NAT, если также требуется исходящий трафик к ресурсам не от Google.
  • Если вы направляете трафик 0.0.0.0/0 через сторонний межсетевой экран, всё равно включите PGA и добавьте статические маршруты для VIP-диапазонов Google API к шлюзу интернета по умолчанию, чтобы обойти межсетевой экран для сервисов Google.

Масштабирование и устранение проблем с IP-адресацией

• Отслеживайте потребление alias IP на уровне дополнительных диапазонов подсети. Если нагрузка на IP-адреса растёт:
  • Увеличьте размеры дополнительных диапазонов (добавьте более крупные диапазоны, при необходимости пересоздайте кластер или мигрируйте рабочие нагрузки).
  • Настройте max-pods-per-node, чтобы сбалансировать использование IP-адресов на узел и фрагментацию при планировании.
  • Удаляйте заброшенные сервисы; headless-сервисы не выделяют ClusterIP, но их преобразование в ClusterIP потребует IP-адресов.
• Планируйте рост в нескольких регионах с использованием непересекающихся дополнительных диапазонов, чтобы избежать переназначения IP-адресов (re-IP) при использовании Shared VPC, VPC Peering или многокластерных сервисов.

Ingress, Gateway API, Services и политики

Services и балансировщики нагрузки

• Типы Service:
  • ClusterIP: доступ только внутри кластера; трафик восток-запад использует kube-proxy или dataplane v2.
  • NodePort: выделяет порт на каждом узле; используется многими балансировщиками нагрузки в качестве бэкенда, но не рекомендуется для прямого доступа из интернета.
  • LoadBalancer: создает облачный балансировщик нагрузки. Внешние или внутренние балансировщики нагрузки L4 поддерживают TCP/UDP; привязка сессии (session affinity) ClientIP обеспечивает постоянство сессий для нескольких протоколов при необходимости.
• Контейнерная балансировка нагрузки использует Network Endpoint Groups (NEGs), чтобы балансировщик нагрузки направлял трафик напрямую на IP-адреса и порты подов, что улучшает передачу сигналов о работоспособности и сокращает количество переходов между узлами. Для GKE используйте GKE Pod NEGs (GCE_POD). Другие типы NEG включают VM_IP_PORT, Internet FQDN и PSC.
• GKE Ingress и Gateway API:
  • Ingress является стабильным решением для трафика север-юг по HTTP(S) с использованием глобального внешнего или регионального внутреннего балансировщика нагрузки HTTP(S) от Google. Контроллер автоматически настраивает проверки работоспособности и правила брандмауэра для стандартных сценариев.
  • Gateway API предлагает более выразительную модель с ресурсами Gateway, HTTPRoute и TCPRoute. Он поддерживает многопользовательские конфигурации, расширенную маршрутизацию и единую спецификацию для разных сред. Выбирайте Gateway API для обеспечения совместимости с будущими технологиями; используйте Ingress, когда важны простота и совместимость.

Ограничение доступа клиентов и проверки работоспособности

• Ограничение доступа клиентов по диапазонам исходных IP-адресов можно выполнить на уровне L4 с помощью правил брандмауэра VPC, нацеленных на экземпляры бэкенда, или на уровне L7 с помощью политик Cloud Armor для балансировщиков нагрузки HTTP(S).
• Всегда разрешайте доступ с диапазонов IP-адресов систем проверки работоспособности Google к целевым бэкендам или подам, чтобы проверки проходили успешно.
• В некоторых развертываниях GKE автоматически создает правила k8s-fw; если вы добавляете ограничивающие правила, сохраняйте явные разрешающие правила для диапазонов IP-адресов систем проверки работоспособности.
• Пример подхода для бэкендов L4: пометьте узлы тегом «application» и создайте разрешающее правило брандмауэра для tcp:NodePort от разрешенных CIDR клиентов и диапазонов проверки работоспособности Google, а также более высокоприоритетное запрещающее правило для всех остальных источников с включенным логированием для отслеживания отброшенных пакетов.

Сетевые политики и dataplane v2

• Включите Kubernetes NetworkPolicy и используйте GKE Dataplane V2 для принудительного применения политик на основе eBPF, что повышает производительность и точность по сравнению с механизмами на базе iptables.
• Базовая конфигурация безопасности:
  • По умолчанию запретите весь исходящий (egress) и входящий (ingress) трафик для пространств имен; явно разрешайте потоки трафика между подами (Pod-to-Pod) и от подов к сервисам (Pod-to-Service).
  • Используйте селекторы пространств имен (namespace) и подов (podSelectors) для создания уровней сервисов (frontend, backend, data) и разрешайте только минимально необходимые направления и порты.
• Безопасное взаимодействие сервисов:
  • Для реализации концепции «нулевого доверия» (zero trust) внутри кластера лучше всего подходит mTLS, предоставляемый service mesh; NetworkPolicy работает на уровнях L3/L4 и не может аутентифицировать идентификаторы.
  • Для трафика север-юг подключите Cloud Armor к балансировщикам нагрузки HTTP(S) для использования WAF, ограничения частоты запросов (rate limiting) и режима предварительного просмотра (preview mode), чтобы протестировать запрещающие правила для подозрительных злоумышленников без прерывания работы пользователей.

Сценарии сбоев и компромиссы

• Слишком большое количество или чрезмерно широкие NetworkPolicies могут вызывать неожиданные отбросы трафика; проверяйте их с помощью поэтапного развертывания, логирования и инструментов для анализа политик.
• Использование NodePort в связке с внешними правилами брандмауэра — хрупкое решение; предпочитайте управляемые балансировщики нагрузки и Pod NEG.
• Gateway API предоставляет более богатый функционал, но требует зрелости контроллера и знакомства с ним команды; проверяйте такие функции, как маршрутизация на основе заголовков или сквозная передача mTLS (mTLS passthrough), для каждого канала выпуска (release channel).

Мультикластерность, сервисная сетка и идентификация

Мультикластерные сервисы и сетевое взаимодействие во флите

• Зарегистрируйте кластеры во флите, чтобы использовать Multi-Cluster Services (MCS) для обнаружения сервисов и балансировки нагрузки между кластерами. Экспортируйте сервисы из каждого кластера; клиенты будут разрешать единое DNS-имя, за которым стоят эндпоинты из разных кластеров.
• Паттерны межкластерного трафика:
  • Один VPC, разные подсети: трафик идет по частным адресам RFC1918 с оптимальной стоимостью и задержкой.
  • Разные VPC: используйте VPC Peering для простого частного соединения без транзитивности или Cloud VPN/Cloud Router, если организации разные или требуется шифрование через интернет. Для централизованного администрирования Shared VPC предоставляет сервисным проектам только необходимые подсети.
• Режимы отказа:
  • Пересекающиеся диапазоны CIDR блокируют маршрутизацию; убедитесь, что PodCIDR и ServiceCIDR не пересекаются перед настройкой пиринга или VPN.
  • Проблемы с DNS split-horizon могут нарушить разрешение имен между кластерами; проверьте пути поиска (search paths) и заглушечные домены (stub domains).

Сервисная сетка, трафик “восток-запад” и наблюдаемость

• Разверните сервисную сетку, например Anthos Service Mesh, для:
  • mTLS с надежной идентификацией рабочих нагрузок, политик трафика (повторные попытки, тайм-ауты, обнаружение выбросов) и разделения трафика.
  • Единообразных политик для трафика “восток-запад” между кластерами с помощью федерации сеток или топологий multi-primary.
  • Богатой телеметрии: “золотые сигналы” для каждой рабочей нагрузки, трассировки запросов и аудиты политик.
• Компромиссы:
  • Сайдкар-контейнеры увеличивают потребление ресурсов; режимы ambient или sidecarless могут снизить затраты, но требуют проверки паритета функциональности.
  • Сервисная сетка добавляет зависимости от уровня управления; проектируйте высокодоступные уровни управления и плавную деградацию.

Идентификация рабочих нагрузок, секреты и принцип минимальных привилегий

• Используйте Workload Identity для сопоставления сервисных аккаунтов Kubernetes (KSA) с сервисными аккаунтами Google (GSA), что избавляет от долгоживущих ключей. Аннотируйте KSA email-адресом GSA и предоставьте GSA минимально необходимые роли IAM.
• Управление секретами:
  • Предпочтительно использовать Secret Manager с драйвером CSI для монтирования секретов во время выполнения; удалите обычные Kubernetes Secrets для чувствительных данных или зашифруйте их в состоянии покоя с помощью CMEK, если они сохраняются.
  • Предоставляйте GSA доступ к секретам и бакетам по принципу минимальных привилегий. Избегайте ролей на уровне проекта; используйте роли на уровне ресурсов, такие как storage.objectViewer, где это применимо.

Вопросы отказоустойчивости и безопасного проектирования платформы

• Региональные кластеры для высокой доступности; распределяйте узлы по зонам. Для трафика “север-юг” используйте глобальную HTTP(S) балансировку нагрузки для минимальной задержки для пользователей по всему миру.
• Подключение к уровню управления: выбирайте частные уровни управления; избегайте публичного доступа, если это не является абсолютно необходимым, с использованием Authorized Networks.
• Исходящий трафик (Egress): узлы без внешних IP-адресов в сочетании с Cloud NAT и PGA обеспечивают баланс между безопасностью и функциональностью.
• Наблюдаемость: включите логирование брандмауэра, VPC Flow Logs и телеметрию сервисной сетки для быстрой диагностики отброшенных политиками пакетов или всплесков задержки.

Практический сценарий

Компания Contoso Retail управляет двумя частными региональными кластерами GKE в регионах us-east1 и europe-west1. Требования: отсутствие внешних IP-адресов у узлов, безопасный входящий трафик, ограниченный корпоративными CIDR, глобальная доступность для сервиса витрины, загрузка образов без доступа в интернет и межкластерное аварийное переключение для уровня API. Ранее они столкнулись с исчерпанием IP-адресов для подов во время всплеска нагрузки.

Подход

1. Спроектировать VPC-native подсети с щедрыми вторичными диапазонами.

   • Обоснование: Выделить диапазон /17 для подов и /21 для сервисов в каждом регионе, чтобы покрыть 100 узлов × 200 подов/узел и 1500 сервисов с запасом в 20–30%. Это предотвратит повторное исчерпание IP-адресов для подов и позволит избежать переназначения IP-адресов при росте.

2. Создать частные кластеры с частными эндпоинтами уровня управления.

   • Обоснование: Ограничивает доступ к уровню управления только из VPC. Операторы подключаются через бастионный хост в подсети управления. Это уменьшает поверхность атаки по сравнению с публичными эндпоинтами с Authorized Networks.

3. Включить Cloud NAT и Private Google Access в подсетях узлов.

   • Обоснование: Узлы не имеют внешних IP-адресов, но им все равно нужно загружать образы из Artifact Registry и обращаться к зеркалам ОС/пакетов. PGA обеспечивает доступ к Google API без публичных исходных IP-адресов; Cloud NAT обрабатывает исходящий трафик к ресурсам вне Google по мере необходимости.

4. Реализовать глобальный HTTP(S) ingress с помощью Gateway API и Pod NEG.

   • Обоснование: Единый глобальный anycast VIP снижает задержку для пользователей по всему миру. GKE Pod NEG отправляют проверки работоспособности напрямую подам и улучшают обнаружение сбоев. Gateway API обеспечивает четкое разделение между инфраструктурными Gateway и принадлежащими приложениям Route.

5. Ограничить доступ клиентов и разрешить проверки работоспособности.

   • Обоснование: Применить политику Cloud Armor, разрешающую доступ только с корпоративных CIDR, с правилом “запретить по умолчанию” и режимом предварительного просмотра для безопасной оценки новых блокировок. Кроме того, убедиться, что правила брандмауэра VPC разрешают трафик с исходных диапазонов Google для проверок работоспособности к бэкенд-группам NEG, чтобы проверки оставались успешными.

6. Применить NetworkPolicy с GKE Dataplane V2.

   • Обоснование: Запретить по умолчанию входящий и исходящий трафик для каждого пространства имен; разрешить только трафик с фронтенда на бэкенд и с бэкенда на базу данных по нужным портам. Dataplane V2 эффективно применяет политики с помощью eBPF, уменьшая радиус поражения для скомпрометированных подов.

7. Включить Multi-Cluster Services во всем флите.

   • Обоснование: Экспортировать сервис API в обоих регионах и опубликовать единое DNS-имя. Клиенты автоматически переключаются на работоспособные эндпоинты в других кластерах при сбое. Поскольку оба кластера находятся в одном VPC с региональными подсетями, межрегиональный трафик остается частным и несет минимальные накладные расходы.

8. Внедрить сервисную сетку для безопасности трафика “восток-запад” и наблюдаемости.

   • Обоснование: Принудительно использовать mTLS между сервисами, добавить бюджеты на повторные попытки/тайм-ауты и получать метрики и трассировки для каждого маршрута. Политики на уровне сетки дополняют NetworkPolicy: NetworkPolicy контролирует доступность на уровнях L3/L4; сетка аутентифицирует и авторизует идентификаторы сервисов на уровне L7.

9. Усилить безопасность идентификаторов рабочих нагрузок и секретов.

   • Обоснование: Сопоставить KSA с GSA с узко ограниченными правами через Workload Identity; предоставлять только необходимые роли, такие как storage.objectViewer для сервисов, получающих отчеты. Доставлять учетные данные через Secret Manager CSI, чтобы избежать статических секретов в манифестах.

10. Внедрить механизмы контроля емкости и логирования.

    • Обоснование: Продуманно установить max-pods-per-node для балансировки использования IP-адресов. Мониторить утилизацию вторичных диапазонов и VPC Flow Logs. Создать явное высокоприоритетное правило брандмауэра “запретить все” с логированием для тега приложения, чтобы выявлять непреднамеренный клиентский трафик, сохраняя при этом разрешенные пути.

Такая архитектура обеспечивает создание кластеров, которые по умолчанию являются частными, с контролируемым доступом “север-юг”, отказоустойчивым мультикластерным переключением, принципом минимальных привилегий для идентификации и уровнем данных, который масштабируется без повторного исчерпания IP-адресов.

← Маршрутизация · Все домены · Наблюдаемость сети →

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

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