Google ACE: Контейнеры, хостинг приложений и бессерверные платформы — Руководство по подготовке

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

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

Обзор

Google Cloud предлагает целый спектр платформ для запуска контейнеров и приложений: от полностью управляемых бессерверных решений до настраиваемых кластеров Kubernetes. Выбор и эксплуатация подходящей платформы требуют понимания плоскостей управления, моделей масштабирования, механизмов выпуска релизов, сетевых взаимодействий и безопасности. В этом разделе собраны практические рекомендации по работе с Google Kubernetes Engine (GKE), Artifact Registry, Cloud Run, App Engine и Cloud Functions, а также паттерны для работы с секретами, безопасного развертывания и диагностики.

Kubernetes Engine: Кластеры, рабочие нагрузки и сеть

Кластеры GKE предоставляют управляемую плоскость управления Kubernetes с пулами узлов, которые вы настраиваете по размеру и безопасности. Выбирайте режим Autopilot для минимальных операционных издержек и стандартных настроек по умолчанию, или Standard для детального контроля над узлами, сетью и дополнениями. Используйте каналы обновлений (release channels) и автоматическое обновление узлов для предсказуемых и безопасных обновлений; включите автоматическое восстановление узлов (node auto-repair). Предпочитайте Container-Optimized OS для защищенных узлов, если только для конкретных пакетов не требуется Ubuntu.

• Пулы узлов и планирование

  • Разделяйте пулы узлов по классу рабочей нагрузки (например, general, GPU, spot) и используйте taints/tolerations для направления подов.
  • Включите cluster autoscaler и настройте min/max для каждого пула. Помните, что PodDisruptionBudgets и запросы ресурсов могут блокировать уменьшение масштаба (scale-in) или оставлять поды в состоянии ожидания (pending), если запросы превышают доступные типы узлов.
  • Спотовые/прерываемые (spot/preemptible) узлы снижают стоимость, но несут риск вытеснения (eviction); для отказоустойчивости комбинируйте их с бюджетами surge для Deployment и ограничениями топологии подов (Pod topology constraints).

• Пространства имен и многопользовательский режим (multi-tenancy)

  • Используйте пространства имен для разделения квот, политик и RBAC. Применяйте NetworkPolicies для ограничения east-west трафика. Принудительно применяйте стандарты Pod Security на уровне пространства имен, чтобы избежать привилегированных рабочих нагрузок.

• Рабочие нагрузки

  • Deployments управляют подами без состояния (stateless) с помощью плавающих обновлений (rolling updates), бюджетов surge/unavailable и быстрых откатов. Используйте проверки готовности (readiness probes) для управления трафиком и проверки жизнеспособности/запуска (liveness/startup probes) для самовосстановления. Неправильно настроенные readiness probes могут привести к “черной дыре” для трафика (blackhole); тестируйте перед использованием в продакшене.
  • StatefulSets обеспечивают стабильные идентификаторы и упорядоченное масштабирование для баз данных и систем на основе кворума. Используйте headless Service и StorageClass с поддержкой динамического выделения ресурсов (dynamic provisioning); планируйте с учетом зональной принадлежности PV (zonal PV locality).
  • DaemonSets размещают по одному поду на каждом узле (например, для агентов логирования/мониторинга). Они учитывают события автомасштабирования и осушения (drain) узлов и идеально подходят для сбора телеметрии со всего узла.

• Сервисы и Ingress

  • ClusterIP предоставляет внутрикластерный DNS и балансировку нагрузки. NodePort используется в основном для отладки. LoadBalancer создает внешний или внутренний TCP/UDP балансировщик нагрузки Google Cloud; используйте внутренний для приватных сервисов.
  • GKE Ingress настраивает глобальную HTTP(S) балансировку нагрузки с управляемыми сертификатами, картами URL и Cloud Armor. Для современного управления трафиком предпочитайте нативную для контейнеров балансировку нагрузки (NEG) для проверок состояния каждого пода и более быстрой сходимости. Убедитесь, что эндпоинты готовности (readiness endpoints) отражают реальное состояние приложения; в противном случае бэкенд станет неработоспособным, что вызовет ошибки 502.

• Автомасштабирование

  • Horizontal Pod Autoscaler (HPA) масштабирует количество реплик на основе метрик, таких как CPU, или пользовательских метрик через Cloud Monitoring; убедитесь, что Metrics Server исправен. Vertical Pod Autoscaler (VPA) может подбирать оптимальные запросы ресурсов (right-size); избегайте конфликтов с HPA, используя VPA в режиме рекомендаций (“recommendation” mode) для нагрузок, управляемых HPA, или осторожно используйте совместимый режим HPA+VPA.
  • Cluster autoscaler добавляет/удаляет узлы для размещения подов. Если поды запрашивают больше ресурсов, чем может предоставить любой из типов узлов, они никогда не будут запланированы; согласовывайте запросы/лимиты (requests/limits) с типами узлов в пуле.

Краткие примеры:

• Откатить неисправный релиз:

undefined

• Быстро просмотреть другой контекст:

undefined

Управление артефактами, безопасность цепочки поставок и безопасные релизы

Artifact Registry хранит образы контейнеров в разрезе регионов с поддержкой VPC Service Controls. Используйте отдельные репозитории (или префиксы) для разных сред и применяйте неизменяемые теги (immutable tags); развертывайте по дайджесту (digest), чтобы избежать неоднозначности. Интегрируйте Cloud Build или вашу CI-систему для сборки и отправки образов с метаданными о происхождении (provenance).

• Управление уязвимостями

  • Включите Artifact Analysis для сканирования образов на наличие уязвимостей (CVE) в ОС и языковых пакетах. Прерывайте сборки или блокируйте продвижение (promotion) при обнаружении находок с высоким уровнем серьезности. Комбинируйте это с Binary Authorization, чтобы требовать подписи/аттестации (например, прохождение политики уязвимостей, происхождение SLSA) перед допуском в GKE.

• Продвижение образов

  • Продвигайте образы, копируя дайджест образа из dev-репозитория в staging/prod репозитории или переназначая тег в репозитории для продвижения; избегайте изменяемого тега “latest”. Автоматизируйте с помощью триггеров Cloud Build, срабатывающих по результатам тестов и сканирования.

• Секреты и конфигурация

  • Предпочитайте Secret Manager с доступом по принципу наименьших привилегий. В GKE используйте драйвер Secret Manager CSI с Workload Identity, чтобы узлы никогда не имели доступа к долгоживущим секретам. Для конфигураций KRM отделяйте ConfigMap (не секретные данные) от Secret (конфиденциальные данные) и монтируйте их в режиме только для чтения.
  • Для бессерверных платформ монтируйте секреты через прямые привязки Secret Manager; избегайте встраивания секретов в переменные окружения, если это не является абсолютно необходимым.

• Паттерны отката и выпуска релизов

  • Kubernetes: используйте плавающие обновления (rolling updates) с maxUnavailable=0 для развертывания без простоя и maxSurge, настроенным под вашу емкость; для канареечного развертывания используйте два Deployment за одним Service или Service mesh для постепенного переключения трафика в процентах. Защищайте критически важные рабочие нагрузки с помощью PodDisruptionBudgets и minReadySeconds.
  • Cloud Run и App Engine: используйте ревизии/версии и разделение трафика для канареечных и сине-зеленых (blue/green) развертываний. Держите предыдущие ревизии в “прогретом” состоянии, чтобы уменьшить задержку при откате.
  • Режимы сбоя: дрейф изменяемых тегов, пробелы во времени сканирования и неверно указанные readiness probes являются частыми причинами сбоев. Используйте дайджесты образов, проверки перед развертыванием и синтетические проверки состояния.

Бессерверные платформы для приложений

Cloud Run предоставляет вычислительные ресурсы, ориентированные на контейнеры и управляемые запросами, с автоматическим масштабированием до нуля и применением идентификации для каждого запроса.

• Сервисы и задания Cloud Run

  • Сервисы обрабатывают HTTP; параметр concurrency (одновременные подключения) контролирует количество одновременных запросов на экземпляр (настраивается для баланса между задержкой и эффективностью). Задания обрабатывают пакетные/cron-задачи, не связанные с HTTP, и могут выполняться параллельно.
  • Ревизии (Revisions) — это неизменяемые снимки состояния. Разделение трафика позволяет выполнять canary-развертывание по процентам. Установите минимальное количество экземпляров (min instances), чтобы сократить холодные старты; используйте выделение CPU в режиме простоя (CPU allocation during idle), если требуется фоновая работа.
  • Идентификация: назначайте выделенный сервисный аккаунт для каждого сервиса/ревизии с минимальными необходимыми правами. Ограничивайте вызов через IAM (роль Cloud Run Invoker) или делайте сервис общедоступным при необходимости. Для аутентификации конечных пользователей используйте подписанные токены IAP или встроенную аутентификацию Cloud Run с Identity Platform.

• Сетевое взаимодействие

  • Используйте коннекторы Serverless VPC для доступа к частным ресурсам VPC. Выберите режим исходящего трафика (egress): весь трафик через коннектор или только частные диапазоны RFC1918. Помните о квотах на пропускную способность коннектора; масштабируйте размер коннектора и размещайте его в том же регионе, что и сервис. Для исходящего доступа в интернет с ресурсов, имеющих только частные IP-адреса, используйте комбинацию с Cloud NAT.
  • Private Service Connect позволяет приватно использовать сервисы-производители или предоставлять доступ к внутренним эндпоинтам. Для приема входящего трафика по внешнему HTTP(S) используйте Cloud Load Balancing с серверными группами Serverless NEG.

App Engine предлагает две среды выполнения:

• Standard
  • Изолированная среда («песочница»), быстро масштабируется, поддерживает автоматическое, базовое или ручное масштабирование. Автоматическое масштабирование с параметром min_idle_instances обеспечивает предварительно прогретые ресурсы. Быстрый холодный старт и простая модель развертывания; ограниченные возможности кастомизации на уровне ОС и фиксированный набор сред выполнения.
• Flexible
  • Запускает Docker на виртуальных машинах Compute Engine с большим контролем над системными библиотеками и сетевыми настройками. Более медленный жизненный цикл экземпляра и более высокая базовая стоимость; подходит, когда требуются кастомные среды выполнения или нативные библиотеки.
• Сервисы и версии
  • Разделяйте трафик по версиям (случайно, по cookie или по IP). Каждый сервис может масштабироваться независимо. Используйте постепенное развертывание (gradual rollouts) и сохраняйте предыдущую версию для мгновенного отката (rollback).

Cloud Functions предоставляет одноцелевые функции, управляемые событиями.

• Триггеры: Pub/Sub, Cloud Storage, HTTP, Eventarc для множества источников. Делайте обработчики идемпотентными; некоторые триггеры выполняют повторные попытки при сбое, что приводит к дублированию обработки.
• Конфигурация среды выполнения: переменные окружения, привязки Secret Manager, максимальное количество экземпляров (max instances), память/CPU. Контролируйте одновременные подключения (concurrency) для HTTP-функций, чтобы сбалансировать задержку и стоимость.
• Распространенные ошибки: неограниченное количество одновременных подключений или неидемпотентные побочные эффекты вызывают дублирование данных; убедитесь в наличии DLQ для Pub/Sub; устанавливайте соответствующие тайм-ауты.

Выбор платформы, организация сети и операционная ответственность

Выбирайте платформу в зависимости от требуемого уровня контроля, характеристик масштабирования, потребностей в переносимости и бюджета на эксплуатацию.

• Контроль в сравнении с операционными издержками

  • Максимальный контроль: GKE Standard (ОС узлов, сеть, дополнения для безопасности) с соответствующими операционными издержками.
  • Сбалансированный вариант: GKE Autopilot (без управления узлами, предустановленные настройки безопасности).
  • Минимальные издержки: Cloud Run, App Engine, Cloud Functions (без узлов, управляемое масштабирование), но с ограничениями по среде выполнения и моделям обработки запросов.

• Масштабирование и соответствие рабочей нагрузке

  • Нагрузки с резкими всплесками запросов: отлично подходят Cloud Run/App Engine Standard; Functions — для обработчиков, управляемых событиями.
  • Сервисы с отслеживанием состояния (stateful) или с особыми требованиями к сети: GKE со StatefulSets и возможностями CNI.
  • Переносимость: контейнеры в GKE/Cloud Run; Functions менее переносимы из-за модели FaaS.

• Сеть для бессерверных вычислений, исходящий трафик и частные сервисы

  • Используйте коннекторы VPC для доступа к частным ресурсам; отслеживайте утилизацию коннекторов, чтобы избежать троттлинга. Устанавливайте исходящий трафик (egress) в режим «all» только при необходимости; в остальных случаях ограничивайте его частными диапазонами для снижения затрат и рисков.
  • Для частного входящего трафика (ingress) рассмотрите внутренний балансировщик нагрузки HTTP(S) с Serverless NEG или Private Service Connect.
  • Для контроля утечки данных используйте VPC Service Controls (где это поддерживается) и ограничивайте маршруты исходящего трафика с помощью правил брандмауэра и Cloud NAT.

• Диагностика и операционная ответственность

  • Стандартизируйте использование Cloud Logging со структурированными логами (JSON) и идентификаторами трассировки/спанов (trace/span ID) для корреляции данных между сервисами. Используйте дашборды Cloud Monitoring, проверки времени безотказной работы (uptime checks), SLO и политики оповещений.
  • Для GKE: включите Cloud Ops for GKE, собирайте метрики приложений через Prometheus или Cloud Monitoring и используйте DaemonSets для сбора телеметрии на уровне узлов.
  • Для бессерверных платформ: используйте встроенные логи запросов, Error Reporting, Trace и Profiler. Настройте SLO для каждого сервиса и оповещения по задержке, частоте ошибок и насыщению (одновременные подключения, загрузка ЦП экземпляра).
  • Модель ответственности: определите, кто отвечает за параметры среды выполнения (масштабирование, одновременные подключения), IAM и конвейеры развертывания. Регулярно тестируйте сценарии отката и аварийного восстановления.

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

Компания Acme Retail планирует запустить новый API для оформления заказов и одновременно модернизировать внутренние сервисы. Требования: публичный API с низкой задержкой и возможностью канареечных развертываний, частный доступ к внутренней базе данных инвентаря в VPC, контроль цепочки поставок ПО и понятный механизм отката с минимальными операционными издержками.

1. Выбрать Cloud Run для публичного API и GKE Autopilot для внутреннего сервиса инвентаризации.

• Обоснование: Cloud Run минимизирует операционные издержки для stateless HTTP-сервисов, поддерживает ревизии и разделение трафика; GKE Autopilot предоставляет возможности Kubernetes для stateful/внутренних сервисов без необходимости управлять узлами.

2. Собирать, сканировать и хранить образы в Artifact Registry с данными о происхождении (provenance).

• Обоснование: Cloud Build создает образы контейнеров; Artifact Analysis сканирует их на наличие CVE. Хранение дайджестов и данных о происхождении позволяет с помощью Binary Authorization гарантировать запуск только просканированных и подписанных образов.

3. Применять политики допуска (admission policies).

• Обоснование: Включить Binary Authorization в кластере GKE, чтобы требовать подписи и подтверждения соответствия политикам (attestations). Для Cloud Run настроить автоматизацию развертывания так, чтобы переход на новую версию был возможен только после успешной проверки на соответствие политике уязвимостей.

4. Настроить сеть с помощью Serverless VPC connector и Cloud NAT.

• Обоснование: API на Cloud Run должен иметь частный доступ к сервису инвентаризации и Cloud SQL. Коннектор VPC обеспечивает исходящий трафик в частные сети (RFC1918); Cloud NAT предоставляет доступ в интернет для загрузки зависимостей без назначения внешних IP-адресов частным ресурсам. Размещайте коннектор и сервисы в одном регионе и подбирайте его пропускную способность в соответствии с нагрузкой.

5. Обеспечить безопасность идентификационных данных и разрешений.

• Обоснование: Назначить сервису Cloud Run выделенный сервисный аккаунт с минимальными необходимыми правами (например, Cloud SQL Client, права на вызов внутренних эндпоинтов). Для GKE использовать Workload Identity, чтобы поды могли использовать сервисные аккаунты без учетных данных на уровне узлов.

6. Реализовать безопасное развертывание и откат.

• Обоснование: Развернуть API как новую ревизию Cloud Run и направить 5% трафика для канареечного тестирования. Отслеживать задержку, частоту ошибок и насыщение; затем плавно увеличить трафик до 100% или мгновенно выполнить откат, вернув трафик на предыдущую ревизию. В GKE использовать плавающие обновления (rolling updates) для Deployment с проверками готовности (readiness probes) и небольшой канареечный Deployment за тем же Service для валидации перед полным развертыванием.

7. Настроить наблюдаемость (observability) и SLO.

• Обоснование: Отправлять структурированные JSON-логи с идентификаторами трассировки из обеих платформ в Cloud Logging. Создать SLO для 95-го перцентиля задержки и частоты 5xx ошибок; привязать к ним политики оповещений. Использовать Error Reporting и Trace для анализа первопричин. Для GKE развернуть DaemonSet для сбора метрик узлов и включить Cloud Ops for GKE.

8. Проверить сценарии сбоев и производительность.

• Обоснование: Провести нагрузочное тестирование для проверки пропускной способности коннектора VPC, количества одновременных подключений в Cloud Run и поведения HPA в GKE. Убедиться в точности проверок готовности (readiness probe), чтобы избежать «черных дыр» трафика. Протестировать сценарии отказа Binary Authorization и откат образа по дайджесту, чтобы гарантировать восстанавливаемость при действующих ограничениях цепочки поставок.

Такой подход обеспечивает создание безопасного публичного API с низкими операционными затратами, контролируемых внутренних сервисов, частной сети, принудительного контроля безопасности цепочки поставок и быстрого отката в соответствии с лучшими практиками эксплуатации Google Cloud.

← Compute Engine и операции с виртуальными машинами · Все домены · Сети VPC →

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

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