Основное назначение контроллера ReplicaSet - это поддержание указанного количества запущенных подов. Если посмотреть исходный код контроллера, то можно увидеть, что он подписывается на события создания, обновления и удаления Pod. Основная логика по управлению подами представлена в методе manageReplicas, где происходит вычисление актуального количества подов и желаемого. Если есть разница, то создаются новые поды или удаляются лишние.
Deployment - это абстракция на уровень выше, которая позволяет, например, использовать разные стратегии деплоя (RollingUpdate, Recreate), просматривать историю деплоя, делать откаты и т.д. Контроллер Deployment уже управляет напрямую не Pod, а ReplicaSet, чтобы получить желаемое число подов в кластере. Если посмотреть исходный код, то контроллер подписывается только на события удаления Pod, чтобы реализовать логику стратегии Recreate, но напрямую управляет ресурсом ReplicaSet, а не подами.
Рассматривайте эти сущности как кирпичики, поверх которых выстраивается более сложная логика, что позволяет переиспользовать готовую функциональность: Deployment -> ReplicaSet -> Pod. Вы, например, можете написать свою логику по деплою подов в собственном контроллере и переиспользовать ReplicaSet.
C ключами пода в etcd может работать Deployment Controller и ReplicaSet Controller?
Отвечая формально, то с etcd работает только один компонент Kubernetes - kube-apiserver, проводя аутентификацию, авторизацию, валидацию запросов и в конечном итоге меняя состояние объекта в etcd.