Что такое ReplicaSet и Deployment в Kubernetes

Что проверяют

Понимаете ли вы разделение ответственности между контроллерами и не путаете ли объект, которым управляют руками, с объектом, который создаётся сам. Заодно смотрят, умеете ли объяснить обновление без простоя.

Как отвечать

ReplicaSet держит заданное число подов по шаблону: следит за живыми, создаёт недостающие, убирает лишние. Про версии и обновления он не знает ничего.

Deployment стоит уровнем выше и управляет именно версиями. При изменении шаблона он создаёт новый ReplicaSet и постепенно переводит поды туда, а старый сжимает до нуля. Пустые ReplicaSet остаются ради отката, их число ограничивает revisionHistoryLimit.

Что назвать по делу:

• стратегия RollingUpdate с maxSurge и maxUnavailable, а также Recreate, когда две версии одновременно недопустимы;
• kubectl rollout status и kubectl rollout undo для наблюдения и отката;
• селектор Deployment неизменяем, смена меток означает новый объект;
• ReplicaSet руками не создают и не масштабируют, контроллер вернёт своё значение.

Где спотыкаются

Забывают про пробы. Без readiness под считается готовым сразу после старта, трафик уходит в непрогретое приложение, и обновление без простоя оказывается обновлением с простоем. Liveness при этом настраивается иначе: слишком жёсткая перезапускает рабочие поды под нагрузкой.

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

Держат replicas в манифесте вместе с автомасштабированием. Каждое применение конфигурации возвращает число из репозитория и сбрасывает то, что подобрал HPA; в этом случае поле из манифеста убирают.