Как стать автором
Обновить

Комментарии 5

Как библиотека — выглядит хорошо с первого взгляда: обертка с простым и понятный интерфейсом (проще чем использовать client-go). Как CLI — мне кажется, вы повторяете то что уже есть в kubectl. Поправьте меня, если я ошибаюсь, но:


  • Для слежения за состоянием можно использовать kubectl wait
  • Для слежение за логами в стиле tail -f есть флаг -f/--follow в kubectl logs
  • kubectl apply + kubedog rollout track, выглядит как тоже самое что kubectl apply --wait=true

Подумайте над тем чтобы предложить свою помощь в улучшении kubectl ребятам из sig-cli ;)

Kubectl wait можно использовать в CI/CD, но есть "нюансы".


1) Зафейлить ci/cd pipeline как можно раньше.


Например, есть deployment с ошибкой, он никогда не перейдет в состояние READY. Если запустить kubectl wait --for condition=Available,
то команда завершится с ошибкой только по timeout. Kubedog увидит ошибку и может сразу зафейлить ci/cd pipeline. Для пользователя это дает быстрый фидбек.


2) Показывать "что происходит" во время ожидания.


Kubedog следит не только за указанным ресурсом до достижения какого-то condition, но и за всеми связанными. И получает события и логи этих связанных ресурсов. Вся инфа объединяется в единый поток и выдается наверх. Грубо говоря это аггрегатор "новостей" по указанному ресурсу.


У нас изначально стояла задача: сделать штуку для выката, которая может сказать что "все хорошо", может сказать что "все плохо" и покажет "что происходит сейчас" во время ожидания выката.


В случае с kubectl wait надо придумывать отдельный поток/процесс для показа логов. А чтобы показать логи надо еще узнать имена связанных ресурсов. И как это все в CI/CD по-простому сделать неясно.


Но и логи это не все, еще есть event'ы. С ними отдельная история. В event'ах может содержаться важная пользователю информация для того, чтобы исправить ошибку.


Мы держали в голове такую мысль: следилка должна показать достаточно информации пользователю для дебага проблем. Не надо вызывать kubectl и копатся в консоли. В идеале достаточно посмотреть на вывод CI/CD pipeline и понять где ошибка.


3) Использовать как библиотеку.


Kubectl wait на данный момент это pkg связанный с cli. А хочется подключить этот wait в свое приложение. Будь то helm или dapp. Понятно почему они так делают: не обобщают раньше времени. Но мы сделали библиотеку, потому что было видение сразу.


4) Детали реализации.


Kubedog использует informer-ы из библиотеки того же куба. Это примитив, который позволяет следить за ресурсами сутками, обрабатывает всякие низкоуровневые косяки. Например, натравил сейчас kubectl wait на древний ресурс, который у меня создан месяц назад, вылезла сразу такая ошибка:


error: An error occurred while waiting for the condition to be satisfied: too old resource version: 847449 (1360240)

Вот informer-ы эту ситуацию обрабатывают. Их обычно используют для написания всяких controller-ов.


В общем это надежная такая обертка над низкоуровневым watch-ем. И за счет ее использования в kubedog нет вышеуказанной проблемы. Но это исправимо в kubectl, надо патч им предложить :).




Обобщая. Если сделать kubectl apply + kubedog rollout track, то сразу из коробки получаем и логи, и event-ы, и ожидание до готовности, и прерывание по ошибкам.


Честно, была идея попробовать в kubectl такие функции добавить. Это в идеале. Потому что тогда работа точно зря не пропадет. Но возможно чуть позже.

Спасибо. Это пояснение отлично дополняет статью.


Kubectl wait на данный момент это pkg связанный с cli. А хочется подключить этот wait в свое приложение.

Кстати, несколько месяцев назад (после разбивки kubectl команд на пакеты) на одном из sig-cli митингов обсуждалось нужно ли делать пакеты вроде экспортируемыми или нет. Вроде как пришли к тому что некоторые пакеты будут "повышаться" в общий пакет (на подобии cli-runtime), но конкретных планов по реализации этого я не видел.

Ещё вариант оформить kubedog плагином к kubectl — это какая-то прям элементарная вещь из разряда переименовать бинарь.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий