🌟 Тяжелый день в мире DevOps 😓

☝️ Сперва на кластер NiFi при миграции с публичного GitHub прокатилась какая-то старая Ansible роль и поломались конфигурационные файлы 😮

Затем кластер никак не хотел собираться, якобы не может достучаться до соседних нод, хотя с виду все работает.
Затем я все таки подумал на ядро и посмотрел логи:
RPC: fragment too large 😐

Не знаю, откуда это взялось, вроде никаких NFS у меня нет. Семь бед один резет 🚁

🧶Потом пришлось разбираться в Jenkins пайплайне, который запускает с параметрами Ansible playbook, который шаблонинизирует Kubernetes манифест через Jinja2, который потом применяется через kubectl apply. Вопросов больше, чем ответов. 😡

📝Ну и успел поразбираться с OOM на одном из Jupyter server в Kubeflow, что тоже прошло не спокойно.

План был такой:
☝️ Увелечение memory limits
👩‍💻Оптимизация дата сета (возможно удастся его уменьшить)
🆚Использование альтернативных моделей, которые более оптимизированы по работе с памятью

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

И тут началось: увидел на Kubeflow no healthy upstream.. а в событиях собственно и причину 🔫
429 Too Many Requests - Server message: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading

The rate limits of 100 container image requests per six hours for anonymous usage

Беспощадный капитализм 🤑

📄Завел задачу себе на синк образов для Kubeflow в локальный Artifactory, а также добавить аутентификацию для увеличения лимита до 200. Различных образов у меня в Kubeflow чуть более, чем 100.
Но так как времени уже много, а контейнеров стартануло в целом достаточно, кроме парочки, среди которых был UI, я принял решение подождать шесть часов в качестве быстрого решения 😂

#историядня #kubeflow #oom #nifi

🎉Kubeflow присоединяется к CNCF - Отличные новости! 🎉

Kubeflow официально присоединился к CNCF в качестве проекта на стадии инкубации! Это означает, что проект стал частью нейтральной структуры управления, поддерживаемой Linux Foundation🐧

Теперь у нас открываются новые возможности для развития и роста. Следим за новостями о том, что это значит для сообщества 🔍

Kubeflow Mailing List 📦
Kubeflow Community Call 🍷

👩‍💻 #Kubeflow #MachineLearning #Kubernetes

Ну так что, а кто как запускает контейнеры на MacOS? Docker? Или еще что?

Я ранее использовал Podman на Linux.

Ну, собственно, на MacOS я также остановился на Podman 🔫

Я так понимаю, тут виртуалочка нужна будет под ногами для запуска контейнеров..

📊Управление метриками через Pushgateway: проблемы и стратегии 📈

Привет, друзья! 👋 Давайте рассмотрим тему, которая очень важна для поддержания точных метрик в нашем царстве Kubernetes - управление обновлениями и истечением срока действия метрик с помощью Prometheus Pushgateway.

🚀 Отправка метрик в Prometheus Pushgateway

Мы старательно отправляли метрики в Prometheus Pushgateway, который затем делал их доступными для сканирования Prometheus. Однако есть одна загвоздка - Prometheus собирает эти метрики с фиксированным интервалом в 30 секунд. Хотя такой подход имеет свои достоинства, он не всегда дает точную картину нашей динамичной системы.

⏰ Временные метки (timestamps): Добавлять или не добавлять?

Одним из решений, находящихся в поле нашего зрения, является добавление временных меток (timestamps) в наши метрики. Этот, казалось бы, простой шаг позволяет получить много информации о времени последнего обновления каждой метрики. Такая наглядность может стать спасением при отладке.

Но подождите, есть один нюанс - нужно ли использовать временные метки? Ответ может вас удивить. 🤔
https://prometheus.io/docs/practices/pushing/

💡 Удаление метрик вручную: Тактический ход

Еще одним направлением, которое мы изучаем, является ручное удаление метрик. Поскольку в Pushgateway отсутствует встроенный механизм истечения срока действия метрики (TTL), мы рассматриваем возможность стратегического использования PUT-запросов с пустым телом. Это позволяет эффективно удалять метрики, но с другой стороны. Как мы можем гарантировать, что не потеряем метрики до того, как Prometheus получит возможность их собрать?

🎟 Обогащение метрик метаданными

Лейблы, лейблы, больше лейблов! Еще одна хитрость в наших рукавах - обогащение метрик метаданными. С помощью меток мы можем эффективно классифицировать и фильтровать метрики. Это все равно что добавить нотку организованности в хаос метрик.

😎 Поделитесь своими идеями и мыслями!

Буду рад услышать ваши мнения и рекомендации по поводу этих подходов. Открыли ли вы для себя другие методы, которые творят чудеса в области управления метриками Pushgateway? Особенно в тех случаях, когда речь идет о частых обновлениях или истечении срока действия?

Kubernetes Exposed: один Yaml до провала

🔓 В статье рассматриваются два вектора атаки: public endpoints + anonymous RBAC access.

🇰🇵 Убедитесь, что kubectl proxy недоступен из публичных сетей, он должен быть исключительно в защищенной сетевой среде и доступен только аутентифицированным и авторизованным пользователям.

🐉 Не назначайте роль администратора анонимному пользователю. Обязательно назначьте соответствующие разрешения каждому пользователю и строго придерживайтесь принципа наименьших привилегий.

🛂 Внедрение Admission Control Policies. Admission Controllers могут перехватывать запросы к API Kubernetes, что позволяет вам определять и применять политики, что укрепит безопасность ваших кластеров Kubernetes.

🧐 Углубляемся в Мир PostgreSQL: Работа с Индексами и Схемой 😎

🔥 CREATE INDEX: Важность Блокировок

Создание индекса в большой таблице — это далеко не мгновенное действие, особенно если в ней много данных. По этой причине, операция может занять некоторое время и повесить exclusive lock на всю таблицу.

Есть хитрость! Используйте CONCURRENTLY при создании индекса, чтобы максимально уменьшить воздействие на работу таблицы. По сравнению с традиционным способом, данный метод может существенно уменьшить время блокировки.

♻️REINDEX: Перестройка Индексов

Время от времени индексы нужно перестроить. Когда? Например, если индекс поврежден или в нем много пустых страниц. В таких случаях, REINDEX приходит на помощь. Однако стоит помнить, что без параметра CONCURRENTLY это действие может блокировать таблицу. Выбор параметра зависит от конкретной ситуации.

🧹 VACUUM FULL: Освобождение Места

Если ваша база данных "набрала вес", поможет VACUUM FULL. Эта команда используется для восстановления хранилища путем удаления устаревших данных или кортежей из базы данных PostgreSQL. Важно помнить, что для успешного выполнения VACUUM FULL потребуется достаточно свободного дискового пространства.

Рекомендуется придерживаться хороших практик управления версиями схемы базы данных и рассматривать альтернативные решения, такие как pg_repack.

🔀 ALTER COLUMN: Изменение Структур

Изменение типа колонки или индекса может вызвать сложности, особенно если изменение проводится несистематически. Частые структурные изменения могут привести к трудностям при обновлениях и миграциях.


🛠 Работа с базой данных требует осторожности. Правильные практики, адекватное управление блокировками и переоценка индексов - важные шаги на пути к оптимизации и надежности работы с PostgreSQL.

Kubernetes 1.28 officially introduces sidecars to the Kubernetes API

Обновление Kubernetes до версии 1.28 внесло интересное изменение в спецификацию пода, а именно в поле RestartPolicy для init-контейнеров.

🧑‍🚒 RestartPolicy для Init-Контейнеров

В предыдущих версиях Kubernetes RestartPolicy для init-контейнеров была наследована от общей RestartPolicy пода. Теперь появилось новое поле RestartPolicy в спецификации init-контейнера, и единственным допустимым значением является "Always".

🚀 Always: Если установлена RestartPolicy "Always" для init-контейнера, это означает, что этот контейнер будет постоянно перезапускаться, даже если он завершил выполнение задачи.

🛠 Остальные контейнеры: Для остальных контейнеров или если поле RestartPolicy не указано в спецификации контейнера, поведение перезапуска определяется RestartPolicy на уровне пода и типом контейнера.

🏍 Sidecar: Это изменение позволяет создавать sidecar-контейнеры или контейнеры инициализации с RestartPolicy: Always, которые будут перезапускаться независимо от других контейнеров. После завершения работы всех обычных контейнеров с RestartPolicy "Always", все init-контейнеры с этой настройкой также будут завершены.

Это изменение предоставляет больше гибкости при управлении жизненным циклом init-контейнеров и позволяет им работать как легкие sidecar-контейнеры с возможностью постоянного перезапуска.