Вопросы на собеседовании: GCP-инженер

Я бы начал с Autopilot, потому что эти нагрузки подходят для его управляемой модели и не требуют контроля над узлами.

• Google управляет узлами, масштабированием и многими настройками безопасности, но я все равно проверил бы нужные DaemonSets и admission policies на совместимость с ограничениями Autopilot.
• Для general-purpose workloads на стандартной платформе Autopilot или в ComputeClasses Balanced и Scale-Out действует Pod-based billing по resource requests, поэтому их нужно точно подобрать.
• Нагрузки с выбранными machine series или accelerators используют node-based billing за целые узлы плюс management premium Autopilot.
• Standard я бы выбрал для привилегированного доступа к хостам, специальной настройки узлов или более точного контроля времени обновлений.

Я бы использовал региональный кластер GKE с рабочими узлами как минимум в трех зонах.

• Control plane реплицируется между зонами, поэтому отказ одной зоны не лишает кластер доступа к Kubernetes API.
• Node pools я бы рассчитал так, чтобы после потери зоны оставшейся емкости хватало для requests критичных приложений.
• Число региональных узлов и квоты могут умножаться на количество зон, поэтому до создания я бы проверил итоговое число узлов и стоимость.
• Для приложений я бы также задал topology spread constraints и выбрал реплицируемое хранилище под требуемый уровень доступности.

Я бы разделил эти классы нагрузки по node pools с явными labels, taints и tolerations.

• Небольшой системный пул на обычных VM размещал бы DNS, метрики и контроллеры, чтобы batch-нагрузка не вытесняла сервисы кластера.
• Обычные API работали бы в general-purpose пуле на непрерываемых VM, подобранных под их профиль CPU и памяти.
• Batch-задачи допускали бы Spot VM и корректно обрабатывали остановку, снижая стоимость без ущерба для доступности API.
• У каждого пула были бы собственные границы автомасштабирования, настройки обновлений и типы машин, поскольку одна политика не подходит всем нагрузкам.

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

• Requests должны покрывать обычное потребление CPU и памяти, поскольку scheduler и cluster autoscaler используют их при размещении.
• Лимит памяти я бы установил выше рабочего набора, чтобы сдерживать утечки, понимая, что превышение приведет к OOM kill.
• Для чувствительного к задержке API я бы избегал жесткого CPU limit, поскольку CFS throttling ухудшает время ответа даже при свободном CPU на узле.
• Перед изменением значений я бы настроил алерты на throttling, OOM kills и отношение requests к фактическому потреблению.

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

• HPA мог бы учитывать CPU utilization и внешнюю метрику глубины очереди, чтобы реагировать до накопления запросов.
• Процент CPU считается относительно CPU requests, поэтому нереалистичные requests сделают поведение HPA таким же нереалистичным.
• Я бы не разрешал VPA автоматически менять тот же ресурс CPU или памяти, по которому масштабирует HPA, иначе два контура начнут конфликтовать.
• Изучив рекомендации, я бы обновлял requests через деплой или оставил VPA только для ресурса, который HPA не использует.

Я бы задал минимум и максимум узлов каждого пула с учетом резервной емкости, квот и размера самого крупного пода.

• Cluster autoscaler добавляет узлы, когда поды не размещаются из-за requests, а не просто при высоком среднем CPU узлов.
• В пуле должен быть тип машины, на котором помещается самый крупный под, иначе реплики останутся pending даже до достижения максимума узлов.
• Если запуск узла слишком медленный для всплеска, я бы оставил небольшой резерв или использовал overprovisioning-поды.
• Настройки scale-down должны учитывать PDB и долгие задачи, чтобы экономия не создавала лишних прерываний.

Я бы совместил PodDisruptionBudget с topology spread constraints по зонам и узлам.

• PDB с maxUnavailable: 1 сохраняет две реплики при добровольных прерываниях, например при drain узла.
• Ограничение по зонам с maxSkew: 1 не дает всем репликам попасть в один домен отказа.
• Ограничение по hostname снижает вероятность размещения двух реплик на одном узле.
• Я бы проверил наличие свободной емкости, поскольку строгий PDB защищает доступность, но блокирует drain, если новый под негде разместить.

Я бы использовал Workload Identity Federation for GKE и связал Kubernetes-нагрузку с IAM-идентичностью с минимальными правами.

• Под получает краткоживущие учетные данные через metadata path GKE вместо подключения JSON-ключа.
• Я бы выдал objectViewer только на нужный бакет, а не проектную роль для всего Cloud Storage.
• Namespace и Kubernetes service account были бы выделены этому приложению, чтобы граница principal оставалась ясной.
• Я бы проверил binding из пода и убедился, что legacy metadata access или секреты с ключами не остались резервным способом входа.

Я бы применил default-deny NetworkPolicies для ingress и egress, а затем добавил узкие разрешения для нужных путей.

• API и внутренний сервис выбирались бы по labels подов и namespace, а не по меняющимся IP подов.
• Отдельное egress-правило разрешало бы kube-dns по UDP и TCP 53, чтобы продолжал работать DNS.
• Доступ к Cloud SQL был бы ограничен путем через connector или private endpoint и необходимым портом.
• Я бы использовал enforcement через GKE Dataplane V2 и помнил, что VPC firewall rules продолжают управлять трафиком вне кластера.

Я бы выбрал Gateway API, потому что он лучше разделяет владение балансировщиком и маршрутами отдельных приложений.

• Платформенная команда может владеть Gateway и TLS policy, а команды приложений подключать HTTPRoutes в своих namespaces.
• Правила подключения маршрутов явно оформляют делегирование между namespaces вместо одного большого общего Ingress.
• GKE Ingress я бы сохранил для простого существующего приложения, если поддерживаемые annotations уже закрывают все требования.
• Перед миграцией я бы сравнил конкретные возможности GKE GatewayClass для сертификатов, redirects и backend policies.

Я бы продвигал между окружениями один неизменяемый digest образа, а не пересобирал его для каждого окружения.

• Cloud Build отправлял бы образ в региональный Docker-репозиторий рядом с нагрузками и записывал sha256 digest.
• Deployment manifests ссылались бы на digest, поэтому перенос тега не мог бы незаметно изменить production.
• Право записи было бы только у build identities, а runtime identities получили бы repository reader.
• Cleanup policies сохраняли бы выпущенные и недавно использованные образы, удаляя старые untagged-артефакты сборок.

Я бы включил Binary Authorization с attestations, которые создаются только после успешной одобренной сборки и проверок безопасности.

• Пайплайн подписывал бы digest образа, а не изменяемый тег, с помощью защищенного ключа attestor.
• Production policy требовала бы эту attestation и разрешала только явно одобренные registries.
• Сначала я бы запустил policy в режиме аудита, чтобы найти системные образы и законные исключения до включения enforcement.
• Break-glass деплой требовал бы контролируемой причины, узкого IAM-доступа и последующего аудита, а не постоянного обхода.

Я бы использовал Helm для переиспользуемого пакета приложения, а Kustomize для небольших environment overlays, если оба инструмента действительно полезны.

• Helm chart подходит для повторяющихся объектов, опциональных компонентов и версионированных релизов для нескольких команд.
• Kustomize подходит для patches вроде числа реплик, имен проектов и ссылок на Gateway без превращения каждого поля в параметр шаблона.
• Для простого приложения я бы выбрал один инструмент, поскольку многоступенчатый рендеринг усложняет проверку итогового manifest.
• CI рендерил бы каждое окружение и валидировал готовый YAML до передачи в Argo CD или Cloud Deploy.

Я бы использовал региональный private pool Cloud Build, подключенный к VPC с приватными зависимостями.

• Сетевой путь и firewall rules пула разрешали бы только репозиторий, зеркало пакетов, Artifact Registry и нужные Google APIs.
• Если нужны публичные зависимости, я бы зеркалировал их или использовал одобренный proxy, поскольку отключение внешних IP у workers убирает прямой доступ в интернет.
• Build service account имел бы узкие роли для артефактов и логов без широкой проектной роли Editor.
• Размер машин и concurrency пула я бы определил по измеренному спросу на сборки, поскольку емкость private pool напрямую влияет на стоимость.

Я бы создал delivery pipeline Cloud Deploy с canary strategy и явным подтверждением перед полным rollout.

• Skaffold рендерил бы один и тот же релизный артефакт для target без пересборки между процентами.
• Canary phases переводили бы 10%, затем 30% и 100% через поддерживаемую сетевую конфигурацию GKE-сервиса.
• Verification jobs сравнивали бы error rate и latency со стабильной версией на каждой фазе.
• Ошибка verification останавливает продвижение, но сама не возвращает стабильный трафик, поэтому я бы явно запускал rollback или заранее настроил repair automation Cloud Deploy по заданным критериям.

Я бы сделал Git источником desired state и выдал Argo CD только необходимые права в закрепленных за ним namespaces.

• Отдельные проекты Argo CD ограничивали бы разрешенные репозитории, destinations, namespaces и виды ресурсов каждой команды.
• Protected branches и проверенные pull requests контролировали бы production-изменения до reconciliation.
• Auto-sync мог бы работать в окружениях низкого риска, а production использовал бы sync windows или явное продвижение по принятой policy.
• Drift был бы виден в Argo CD, а экстренные ручные изменения либо откатывались бы, либо сразу фиксировались обратно в Git.

Я бы хранил environment-конфигурацию вне образа и рендерил версионированные ConfigMaps через deployment pipeline.

• Один digest образа проходил бы через dev и production, а overlays задавали endpoints, flags и настройки ресурсов.
• Checksum ConfigMap помещался бы в pod template, чтобы изменение конфигурации запускало контролируемый rollout.
• Крупную или часто меняющуюся конфигурацию я бы передавал через отдельный configuration service или mounted file, а не сотни environment variables.
• Schema validation в CI отклоняла бы отсутствующие ключи и неверные значения до принятия manifest Kubernetes.

Я бы использовал Secret Manager add-on или CSI driver вместе с Workload Identity Federation for GKE и никогда не хранил пароль в Git.

• Роль roles/secretmanager.secretAccessor я бы выдал workload principal на сам ресурс секрета, потому что IAM-доступ нельзя назначить отдельной версии секрета.
• В SecretProviderClass или конфигурации add-on я бы указал явную версию ресурса, например versions/7, вместо latest, чтобы потребляемое значение было детерминированным.
• При ротации я бы создал новые учетные данные БД и версию секрета, обновил закрепленную ссылку, перезапустил и проверил consumers и только затем отключил старые данные и версию.
• Data Access logs Secret Manager подтвердили бы, какой principal прочитал значение во время замены.

Я бы разместил VPC, подсети, маршруты и центральные firewall controls в host project и подключил три service projects.

• Ресурсы приложений остаются в service projects для разделения billing и IAM, но используют подсети host project.
• Network administrators управляют host, а deployers приложений получают только Network User на нужных подсетях.
• Я бы выделил непересекающиеся региональные CIDR с запасом для GKE pods, services и будущего роста.
• Центральное владение не заменяет IAM в service projects, поэтому права на ресурсы и сеть остаются разными зонами ответственности.

Я бы применил общий deny на уровне папки и добавил более приоритетное узкое разрешение для одобренного пути администрирования.

• Allow rule выбирало бы защищенные ресурсы по service accounts или secure tags, а не по широкому сетевому CIDR.
• SSH из 0.0.0.0/0 запрещался бы централизованно, чтобы владельцы проектов не обходили правило через VPC rule нижнего уровня.
• Приоритеты и наследование правил были бы документированы, поскольку совпадение на верхнем уровне может не дать сработать дочерним policies.
• До применения ко всей папке я бы проверил влияние policy на непродакшн-проекте.