Контролер Kubernetes против Оператора Kubernetes?

Как я понимаю, цель контроллера Kubernetes - убедиться, что текущее состояние равно желаемому состоянию. Тем не менее, Kubernetes Operator делает ту же работу.

Список контроллеров в Control-plane:

развертывание
ReplicaSet
StatefulSet
DaemonSet
так далее

Из поиска Google я узнал, что есть операторы K8s, такие как

Оператор etcd
Прометей Оператор
Конг Операторы

Однако я не смог понять, почему это нельзя сделать с помощью контроллера?

Оператор дополняет контроллеры?

Какая разница между этими двумя дизайнами как целью и функциональностью.

Какие определенные вещи нужно иметь в виду, чтобы выбирать между Контроллером и Оператором? ?

Ответ 1

Я считаю, что термин "оператор kubernetes" был введен людьми из CoreOS здесь

Оператор - это контроллер для конкретного приложения, который расширяет API Kubernetes для создания, настройки и управления экземплярами сложных приложений с отслеживанием состояния от имени пользователя Kubernetes. Он основан на базовых концепциях ресурсов и контроллеров Kubernetes, но также включает в себя знания в области предметной области или приложения для автоматизации общих задач, лучше управляемых компьютерами.

В общем, оператор kubernetes - это имя шаблона, состоящего из контроллера kubernetes, который добавляет новые объекты в API Kubernetes для настройки и управления приложением, таким как Prometheus или etcd.

В одном предложении: оператор - это контроллер, специфичный для домена.

Обновление

Существует новое обсуждение на Github по этой же теме, ссылающееся на тот же пост в блоге. Соответствующие биты обсуждения:

Все операторы используют шаблон контроллера, но не все контроллеры являются операторами. Это только Оператор, если он получил: шаблон контроллера + расширение API + фокус одного приложения.

Оператор представляет собой специализированный контроллер с CRD. Он следует той же схеме со встроенными контроллерами (то есть watch, diff, action).

Обновление 2

Я нашел новое сообщение в блоге, которое также пытается объяснить разницу.

Ответ 2

В Кубернетесе большинство операций происходит асинхронно.

Например, когда создается объект ReplicaSet (выбирается более простой объект), происходит следующая последовательность действий:

Отправляем запрос на api-сервер Kube.
Сервер kube-api имеет сложную проверку
- Гарантирует, что у пользователя есть учетные данные RBAC для создания RS в заданном пространстве имен
- Запрос проверен всеми настроенными контроллерами доступа
Наконец, объект просто записывается в ETCD - ни больше, ни меньше

Теперь именно контроллеры Kubernetes обязаны следить за изменениями ETCD и фактически выполнять необходимые операции. В этом случае контроллер ReplicaSet будет наблюдать за изменениями в ETCD (например, CRUD для ReplicataSets) и будет создавать блоки в соответствии с количеством реплик и т.д.

Теперь, что касается операторов, концептуально они очень похожи на контроллеры Kubernetes. Но они используются со сторонними организациями. В Kubernetes существует концепция CRD, где поставщики могут определять свои собственные CRD, которые представляют собой не что иное, как собственный (например, специфичный для поставщика) тип объекта kubernetes. Очень похоже на то, как контроллеры Kubernetes читают в CRUD объектов Kubernetes, эти операторы реагируют на операции с соответствующими CRD. Например, оператор Kong может создавать новые записи API на сервере API Kong, когда в кластере Kubernetes создается новый объект API CRD.