Лучший тест Kubernetes для найма SRE и DevOps инженеров

Почему стандартные тесты Kubernetes не работают

Большинство оценок Kubernetes спрашивают: "Что такое StatefulSet?" или "Объясните пятна и толерантности." Эти измеряют запоминание, не может ли кто-то проектировать кластер, который выживает отказ узла, обнаружить, когда ваше приложение колеблется, или отладить почему развертывание никогда не стабилизируется.

SRE или DevOps инженер с глубоким опытом Kubernetes знает, что реальные вопросы о операционной стабильности, стоимости и отладке производственных проблем под давлением.

Вот как выглядит оценка, несущая сигнал.

Основные навыки для оценки

1. Дизайн кластера и устойчивость

Могут ли они проектировать кластер, который выживает отказ зоны?

Вопрос оценки:

"Вы запускаете производственную нагрузку, которая должна оставаться работающей во время отказов зоны. У вас есть 3-узловой кластер в одной AZ. Что вы измените? Какие компромиссы?"

Хороший ответ:

• Распределите узлы по 3 AZ (минимум)
• Используйте PodDisruptionBudgets для предотвращения каскадных отказов
• Используйте сходство узлов для избежания размещения всех реплик в одной зоне
• Настройте проверки здоровья для ваших узлов
• Понимает компромисс стоимости (3x инфраструктура)

Слабый ответ:

• "Просто запустите больше реплик" (не решает отказ зоны)
• "Используйте анти-сходство" (без понимания ограничений распределения топологии пода)

2. Конфигурация нагрузки и отладка

Могут ли они конфигурировать нагрузку для производства и отладить, когда она ломается?

Вопрос оценки:

"Вы развернули новый микросервис. Развертывание показывает 3 работающих реплики, но только 2 обрабатывают трафик. Проверки готовности пройдены. Почему это может происходить?"

Хороший ответ рассматривает (в порядке):

• Отсутствует ли конечная точка в селекторе сервиса? (kubectl get endpoints)
• Блокирует ли политика сетей пода трафик?
• Неправильно ли сконфигурирован сетевой интерфейс пода?
• Отличается ли проверка здоровья балансировщика нагрузки от проверки готовности?

Это тестирует систематическую отладку, не факты Kubernetes.

3. Хранилище и управление состоянием

Понимают ли они, когда использовать StatefulSets vs. Deployments? Когда использовать локальное на узле vs. постоянное хранилище?

Вопрос оценки:

"Мы запускаем Elasticsearch на Kubernetes. Используем ли мы StatefulSet или Deployment? Что насчет хранилища?"

Хороший ответ:

• StatefulSet для стабильной идентичности и упорядочения
• Постоянные тома для долговечности данных
• Анти-сходство для распределения по узлам
• Осторожная стратегия обновления (катящиеся перезагрузки могут привести к потере кворума)

Слабый ответ:

• "Используйте Deployment, это проще"
• Нет упоминания о персистентности данных или кворуме

4. Масштабирование и оптимизация стоимости

Знают ли они, когда масштабировать вверх vs. когда оптимизировать нагрузки?

Вопрос оценки:

"Использование CPU вашего кластера составляет 85%. Стоимость $10k/месяц. У вас есть два варианта: добавить больше узлов или оптимизировать запросы пода. Что вы проверяете первым?"

Хороший ответ:

• Проверяет, если поды слишком запрашивают ресурсы (установить запросы слишком высоко)
• Проверяет, если есть проблемы с шумным соседом (один под использует намного больше чем ожидается)
• Проверяет, если нагрузка естественно пиковая (можно сдвинуть паттерны трафика вместо этого)
• Только тогда добавить узлы, если это реальное ограничение ресурса

Это тестирует операционное суждение.

5. Наблюдаемость и отладка производства

Могут ли они проектировать мониторинг для Kubernetes? Могут ли они диагностировать почему приложение ненадежно?

Вопрос оценки:

"Ваше приложение в Kubernetes имеет всплеск частоты ошибок 0.1% который длится 30 секунд, затем восстанавливается. Это происходит один раз в день в случайные времена. Как вы бы это расследовали?"

Хороший ответ упоминает:

• События перезагрузки пода (проверяет журналы узлов и kubelet)
• Исчерпание ресурсов (проверяет память и CPU)
• Истечения времени сети (проверяет конечные точки сервиса и DNS)
• Повторные попытки на уровне приложения (восстанавливается ли приложение от переходящих ошибок?)

Структура оценки

Часть 1: Упражнение в домашнем дизайне (2 часа)

Сценарий:

"Проектируйте производственный кластер Kubernetes для SaaS приложения со следующими ограничениями:

• Uptime SLA 99.9%
• Stateless фронтенд и stateful бэкенд (база данных)
• 50-500 одновременных пользователей (переменная нагрузка)
• Ограничение бюджета: $5,000/месяц максимум
• Должны выжить отказ зоны
• Масштабирование должно быть автоматическим"

Кандидат должен предоставить:

• Архитектура узлов (сколько узлов, типы экземпляров, зоны)
• Конфигурация нагрузки (deployments, запросы ресурсов, политики масштабирования)
• Стратегия хранилища (постоянные тома, резервные копии)
• План мониторинга и оповещений
• Разбор стоимости

Это тестирует, построили ли они системы в масштабе.

Часть 2: Просмотр конфигурации (30 минут)

Дайте им манифест Kubernetes с преднамеренными проблемами:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  replicas: 1  # Проблема: должно быть 3 для HA
  selector:
    matchLabels:
      app: api-server
  template:
    metadata:
      labels:
        app: api-server
    spec:
      containers:
      - name: api
        image: api:latest  # Проблема: должно использовать семантическое версионирование
        resources:
          requests:
            cpu: 100m  # Проблема: слишком низко; приложение будет ограничено CPU
            memory: 64Mi  # Проблема: слишком низко; выйдет из памяти
      # Проблема: нет пробы готовности, нет пробы живучести
      # Проблема: нет сходства узлов; может запуститься на том же узле
---
apiVersion: v1
kind: Service
metadata:
  name: api-server
spec:
  selector:
    app: api-server
  ports:
  - port: 80
    targetPort: 8080
  # Проблема: нет headless сервиса для упорядочения; не используется StatefulSet для упорядочения

Попросите их определить все проблемы и объяснить исправления. Сильный кандидат ловит 8+ проблем; слабый ловит 1–2 очевидные.

Часть 3: Разговор по устранению неполадок (30 минут)

Сценарий:

"Вы развернули новый сервис в Kubernetes. Трафик ударяет по нему, но задержка в 10x нормальной. Prometheus показывает нормальное использование CPU и памяти. Пройдитесь через как вы это отладили бы."

Кандидат должен спросить:

• Конечная точка сервиса в курсе? (kubectl get endpoints)
• Поды получают трафик равномерно, или один под медленный?
• Проблема ли пути сети (kube-proxy, CNI)?
• Блокируется ли приложение на что-то (внешний API, база данных)?
• Развертывание включило изменение кода, которое неоптимизировано?

Это тестирует, думают ли они систематически.

Рубрика оценки Kubernetes

Что НЕ тестировать

Не просите кандидатов:

• Написать Kubernetes Operator с нуля. (Это системное программирование, не SRE.)
• Запомнить версии API. (Они будут использовать документы в производстве.)
• Установить кластер с нуля во время интервью. (Это операционная задача, не оценка суждения.)

Просите их:

• Проектировать кластер для реалистичных ограничений
• Отладить почему развертывание ломается
• Объяснить компромиссы между вариантами
• Конфигурировать нагрузки для производства

Для команд еще не использующих Kubernetes

Если вы нанимаете для DevOps или SRE но еще не используете Kubernetes, тестируйте контейнеризацию и концепции оркестрации без требования опыта Kubernetes. Многие команды чрезмерно взвешивают знание Kubernetes, когда им действительно нужно системное мышление.

Для команд использующих Kubernetes в производстве, используйте эту структуру оценки для оценки операционной глубины перед наймом. Кандидат, который проходит эту оценку, будет производителен в первый день.

Дальше: поймите как интерпретировать результаты вашей DevOps оценки.