Комментарии 3
Интересная статья, спасибо. Реализовывал аналогичный оператор, пришли к достаточно похожим решениям.
А какие преимущества использования sigs пакета controller-runtime?
Почему не сделали как в куберовском примере? Как минимум, используя нативные куберовские средства, мы более явно контролируем на обновления каких объектов подписываться.
Мы хотели простой в реализации и будущей поддержке оператор. Использование архитектуры sample-controller подразумевает прямой использование функционала client-go. Получается слишком низкоуровнего и если кто-то захочет поучаствовать в разработке оператора (опенсорс же все) - будет сложней.
Нам понравилась реализация Controller Runtime, где все объекты соответствуют и интерфейсу client.Object и runtime.Object. (Минусы, конечно, есть. Из этой же статьи их видно)
+ нативное использование Controller Runtime в kubebuilder и OpenSDK стало немаловажным фактором.
Изначально мы архитектурно хотели сделать оператор схожим с оператором seaweedfs, но в процессе поняли, что настолько "в лоб" не получится и начали "поглядывать" на реализацию оператора у Виктории и того же Логгинг Оператора. (У логгинг мы точно знали все минусы, т.к. тесно с ним работали и даже отсылали им пулреквесты на всякие мелочи (да и не мелочи тоже), а у Виктории, на мой взгляд, очень хорошая и понятная архитектура кода)
Наступая на грабли. Опыт написания Kubernetes Operator’а