Комментарии 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
Представляем библиотеку kubedog для слежения за ресурсами Kubernetes