Архитектурный выбор контроллеров в Kubernetes

Навыки

• API (интеграции)
• Распределённые системы
• DNS / DHCP
• Микросервисы
• REST API
• S3 (объектное хранилище)
• Системный анализ

О компании и продукте

• Это поведение можно переопределить полем .spec.persistentVolumeClaimRetentionPolicy с параметрами whenScaled и whenDeleted (Retain/Delete) — полезно, чтобы не копить orphaned-тома и не платить за неиспользуемое хранилище после scale down. Для развертывания по умолчанию используется политика OrderedReady. Для оптимизации времени деплоя доступна политика Parallel. Использование: распределенные СУБД, брокеры сообщений, координаторы (etcd, ZooKeeper). DaemonSet: гарантированное покрытие нод. Гарантирует, что экземпляр пода будет запущен на всех (или на строго определенных через nodeSelector / affinity) узлах кластера. Количество реплик не задается вручную, а динамически масштабируется вместе с размером кластера. При вводе новой ноды под разворачивается на ней автоматически
• Размещение подов DaemonSet делегируется штатному kube-scheduler — через автоматическое добавление NodeAffinity и tolerations к системным taints, а не рассчитывается напрямую контроллером DaemonSet. Поддерживает RollingUpdate. Параметр maxUnavailable управляет доступностью агентов с самого начала (по умолчанию 1). Использование: агенты мониторинга и метрик, сборщики логов, системные компоненты сети и проксирования (kube-proxy, CNI-плагины вроде Cilium или Calico). Чек-лист для архитектурного выбора. Deployment: нужна горизонтальная масштабируемость, поды идентичны, состояние хранится во внешних хранилищах (S3, внешняя БД). StatefulSet: нужна строгая идентичность подов, кворумные алгоритмы (Raft/Paxos), фиксация сетевых имен и индивидуальные диски для каждой реплики

Задачи

• Оркестрация жизненного цикла подов зависит от правильного выбора контроллера (Workload API)
• Ошибка на этапе проектирования может привести к нарушению консистентности данных, неэффективной утилизации ресурсов нод или деградации stateful-приложений
• Deployment: оркестрация Stateless-нагрузок
• Этот контроллер спроектирован для приложений без сохранения состояния, где любой под является эфемерным и взаимозаменяемым
• Поды не имеют постоянного сетевого или дискового состояния. Имена генерируются динамически на основе хэша шаблона и случайной строки
• При обновлении старые поды уничтожаются, а новые создаются с нуля. Порядок деплоя реплик не гарантируется
• Использование PersistentVolume ограничено
• Как правило, все реплики делят один том в режиме ReadWriteMany (например, NFS), либо работают исключительно с ephemeral-хранилищами
• Использование: REST API, микросервисы, фронтенд, stateless-воркеры очередей
• StatefulSet: управление Stateful-нагрузками
• Для приложений, требующих идентичности, стабильного сетевого имени и персистентного хранилища для каждой отдельной реплики
• Каждый под получает предсказуемый индекс (от 0 до N-1), который сохраняется при пересоздании (db-0, db-1)
• Требует обязательного объявления Headless Service. Это позволяет формировать уникальные DNS для каждого пода, что критично для сборки кластерных топологий
• Каждому индексу пода соответствует свой PersistentVolumeClaim (через volumeClaimTemplates)
• При пересоздании или переносе пода на другую ноду, к нему монтируется его родной том
• PVC не удаляются автоматически ни при масштабировании вниз, ни при удалении StatefulSet — это защищает данные от случайной потери

Паспорт вакансии

История публикации

Откуда что взялось

Отмечено то, что вывели мы. Без пометки — значение назвал работодатель.

Почему на этом месте в выдаче

Порядок выдачи объявлен контрактом: свежесть решает между днями, полнота и зарплата — внутри дня.