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

Я бы запустил три control-plane ноды и три совмещённых участника etcd, по одному на стойку, за двумя load balancer с virtual IP.

• Три участника etcd выдерживают потерю одной стойки; пять увеличат задержку записи, но не улучшат заданную устойчивость к одной стойке.
• Scheduler и controller-manager работают в трёх репликах с leader election, а трафик принимают все три API server.
• Я резервирую CPU и память для control plane и до запуска проверяю изоляцию стойки и failover load balancer.

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

• Я размещу их по схеме 2-2-1 в трёх зонах и проверю, что после потери любой зоны с двумя участниками остаются три голоса.
• Межзонная задержка должна быть низкой и стабильной, желательно меньше 10 мс, потому что каждая запись ждёт большинство.
• Шесть участников не нужны: они всё равно выдерживают только два отказа и добавляют ещё одну цель репликации.

Сначала я ограничу churn объектов, а затем измерю и настрою etcd, не сводя проблему только к объёму диска.

• Я использую выделенные SSD с низкой задержкой и ставлю алерты на p99 fsync и WAL до приближения к тревожному уровню 100 мс.
• Я сокращаю частые status update, крупные Secrets и ConfigMaps, а также контроллеры, которые делают повторный LIST вместо watch.
• Я выполняю compaction ревизий, поочерёдную defragmentation участников и нагрузочный тест rollout на точных версиях Kubernetes и etcd.

Я буду делать зашифрованные snapshots каждые 15 минут и докажу, что полное восстановление control plane укладывается в 60 минут.

• Snapshots хранятся в отдельном аккаунте или регионе с retention и проверкой целостности, а не на volume того же кластера.
• Runbook восстанавливает новый логический кластер etcd, обновляет endpoints и сертификаты API server, затем проверяет контроллеры и workloads.
• Регулярный тест восстановления фиксирует возраст snapshot, длительность restore, отсутствующие внешние ресурсы и фактически достигнутые RPO и RTO.

Сначала я уберу повторные LIST, потому что они умножают работу по каждому объекту, и только потом добавлю реплики API server.

• Контроллеры должны использовать shared informers, watches, pagination и узкие label или field selectors.
• Я настрою API Priority and Fairness, чтобы трафик kubelet, leader election и системных контроллеров сохранял места под нагрузкой tenant-ов.
• Я слежу за request rate, inflight requests, промахами watch cache, размером ответов и задержкой etcd при воспроизведении ожидаемой нагрузки.

Я использую shared региональные кластеры для обычных команд и выделенные PCI-кластеры для двенадцати регулируемых workloads.

• Namespaces, RBAC, quotas и NetworkPolicy дают soft multi-tenancy командам внутри общей границы доверия.
• PCI-workloads получают отдельные control plane, node identities, audit trail и окна обновления, потому что namespace не является жёсткой границей безопасности.
• Оба класса я стандартизирую одинаковыми шаблонами Cluster API и policy bundle, чтобы дополнительные кластеры не стали уникальными snowflake.

Я запущу по автономному кластеру в каждом регионе и оставлю каждый control plane и кворум etcd внутри региона.

• Global DNS или anycast edge отправляет пользователей на ближайший здоровый региональный ingress.
• Конфигурация workloads реплицируется через GitOps, но живой трафик API и etcd не пересекает Атлантику.
• Stateful-сервисам нужен явный дизайн репликации и failover, потому что Kubernetes federation не решает межрегиональную консистентность данных.

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

• Node pools охватывают все три зоны, но минимальная мощность считается примерно с 50% запасом в оставшейся паре, а не только по равному числу нод.
• Критические Deployments используют topologySpreadConstraints с maxSkew 1 и Pod anti-affinity там, где совместное размещение реплик недопустимо.
• PodDisruptionBudgets защищают добровольные drain, а readiness и failover-тесты доказывают устойчивость приложения к внезапной потере зоны.

Я сразу определю границу шардирования и проверю плановый предел одного кластера нагрузочными тестами.

• Сначала я разделю по регионам и trust domain, потому что эти границы также уменьшают blast radius отказов и доступа.
• Я тестирую API request rate, число watches, объём EndpointSlice, задержку scheduler и рост базы etcd при прогнозируемом churn.
• Я не создаю произвольные шарды по 500 нод, потому что каждый кластер дублирует add-ons, обновления, запас мощности и эксплуатационные расходы.

Я задам строгий бюджет задержки для всей admission chain и уберу из неё некритичную синхронную работу.

• При цели API 500 мс я выделю примерно 100 мс p99 на каждый webhook, оставив остаток на authentication, storage и сеть.
• Каждый webhook работает минимум в трёх репликах по зонам с readiness probes, PodDisruptionBudget и без зависимости от допускаемого workload.
• Security-проверки fail closed, advisory mutation может fail open, но каждая failure policy и timeout проверяются при отключении webhook.

Я использую один namespace на приложение и окружение, а принадлежность команде задам labels вместо одного огромного namespace на команду.

• Имена вроде payments-api-prod явно показывают владельца и окружение, а labels управляют quotas, policies, cost reports и автоматизацией.
• Шаблон namespace создаёт RoleBindings, ResourceQuota, LimitRange, default-deny policies и базовый service account.
• Число namespaces я ограничу только после измерения нагрузки control plane; 2 700 namespaces допустимы при эффективных watches контроллеров.

Я привяжу переиспользуемый ClusterRole через RoleBinding в этом namespace и исключу поверхности privilege escalation.

• Роль может управлять namespaced workloads, Services, ConfigMaps и Secrets своего приложения.
• Она не может привязывать более широкие роли, impersonate пользователей, менять admission webhooks или CRDs и получать доступ к Nodes и PersistentVolumes.
• Workloads используют отдельные service accounts с более узкими Roles, а audit rules отмечают попытки изменить RBAC или выполнить exec в защищённые поды.

Я гарантирую меньше пиковой заявки и сделаю burst явным, а не зарезервирую 40% кластера навсегда.

• Например, я задам requests.cpu quota 200 cores и limits.cpu 400 после проверки измеренного p95 команды и бизнес-приоритета.
• Namespace quotas также ограничат memory requests, число объектов, ёмкость PVC и LoadBalancer Services для защиты не только CPU.
• Prometheus предупреждает на 80% quota, а согласованный путь повышения не даёт команде впервые увидеть лимит во время релиза.

Я введу консервативные defaults по классам workloads, а не одно большое значение, которое скроет плохой sizing.

• Для обычных web-подов можно начать со 100m CPU и 128 MiB memory requests при limits 1 CPU и 512 MiB.
• Batch и JVM namespaces получат другие шаблоны, потому что одинаковые defaults исказят scheduling и OOM-поведение.
• Сначала я проведу audit и warning, затем enforcement после явных значений команд; иначе defaults незаметно вызовут throttling или OOMKills.

Сначала я сгенерирую allow rules из наблюдаемого трафика, затем буду включать enforcement группами namespaces, а не сразу во всём парке.

• Каждый namespace получает default-deny ingress и egress плюс явный DNS-доступ к kube-dns по TCP и UDP 53.
• Platform namespaces публикуют стабильные labels для ingress, metrics scraping, tracing и одобренных shared services.
• До enforcement я две недели анализирую Cilium Hubble или Calico flow logs, а у каждой группы есть проверенный rollback commit.

Platform-команда будет владеть Gateway и listeners, а команды приложений будут владеть HTTPRoutes в своих namespaces.

• allowedRoutes разрешает attachment только namespaces с одобренным label, поэтому tenant не сможет забрать все hostnames.
• ReferenceGrant требуется для намеренных cross-namespace ссылок на backend или сертификат вместо широкого доступа.
• Admission policy проверяет владение hostname и требования TLS до попадания маршрута на shared gateway.

Я доставлю один версионированный Kyverno bundle через GitOps и переведу каждое правило из Audit в Enforce после измерения нарушений.

• Bundle проверяет runAsNonRoot, блокирует privileged и host namespace access, проверяет подписи образов и требует digest.
• Исключение содержит namespace, владельца, причину и дату истечения вместо постоянного wildcard.
• Я делаю canary на одном кластере, слежу за admission p99 и rejection count, затем продвигаю волнами с проверенной rollback-версией.

Я ограничу и активный compute, и churn Kubernetes-объектов этого tenant.

• ResourceQuota ограничивает активные Jobs, Pods, CPU и memory, а TTLAfterFinished удаляет завершённые Jobs после короткого срока, например одного часа.
• Kueue допускает batch-работу по quota tenant-а вместо одновременного создания тысяч Pending Pods.
• API Priority and Fairness выделяет tenant ограниченную долю запросов, чтобы kubelet и системные контроллеры оставались отзывчивыми.

Он должен создать полную границу tenancy, а не только объект Namespace.

• Workflow назначает owner и cost labels, RoleBindings, workload service accounts, ResourceQuota и LimitRange.
• Он устанавливает default-deny NetworkPolicies, labels Pod Security Admission, approved registry policy и базовые observability hooks.
• Conformance Job проверяет DNS, image pulls, metrics, policy rejection и quota до завершения onboarding в целевые 15 минут.

Нет, я помещу враждебный код в отдельный кластер или более сильную sandbox-границу, а не положусь только на namespaces.

• Namespaces разделяют kernel, kubelet, CNI dataplane и control plane, поэтому container escape пересечёт предполагаемую границу tenant.
• Если важна плотность, я добавлю gVisor или Kata Containers, выделенные tainted nodes, отдельные identities и строгий egress, но это дополнительные меры.
• Внутренний multi-tenancy может оставаться namespace-based, потому что его threat model это случайное вмешательство, а не взаимно враждебное выполнение.