Три оттенка Kubernetes Operator, или чем слушает Prometheus

Вашему вниманию предлагается вольное описание работы некоторых компонентов Кубернетес Операторов, с которыми приходится иметь дело как в эксплуатации уже написанных кем-то, так и при разработке собственного Оператора. Чтобы лучше разобраться, как реализован функционал этих компонентов, для наглядности, позволю себе рассмотреть Golang сорс-код Prometheus Оператора для мониторинга и Оператора Hashicorp Vault для управления секретами в Кубернетес, архитектура которых разработана с применением лучших практик использования Kubernetes API и продолжает стабильно обновляться сообществом.

https://habr.com/ru/articles/817091/

#devops #девопс

Подпишись 👉@i_DevOps

Crd-to-sample-yaml or cty ( city )

Утилита для генерации манифестов YAML из CRD.

Это простая утилита, написанная на Go, которая читает CRD-файлы и создает из них YAML-образцы.

Она использует controller-tools/pkg/crd/schema и controller-tools/pkg/crd/markers для интерпретации и разбора схемы.

Установка:

go install github.com/Skarlso/crd-to-sample-yaml@latest

Использование:

crd-to-sample-yaml -path ./path/to/crds > output.yaml

https://github.com/Skarlso/crd-to-sample-yaml

#devops #девопс

Подпишись 👉@i_DevOps

Почему Fedora CoreOS — это container optimized дистрибутив

Fedora CoreOS на официальном сайте представлена как container optimized, container-focused, container based и так далее OS. Но что это вообще значит? Там предустановлен какой-то container runtime? А еще что? В этой статье попытаемся разобраться.

→ Что такое optimized
→ Иммутабельная система и транзакционные обновления
→ Автоматические background-обновления
→ Запуск системы на основе контейнер-образа
→ Безопасность
→ Предустановленные инструменты для контейнеров
→ Гибкий деплой
→ Заключение

https://habr.com/ru/companies/selectel/articles/817299/

#devops #девопс

Подпишись 👉@i_DevOps

Распределённый инференс и шардирование LLM. Часть 1: настройка GPU, проброс в Proxmox и настройка Kubernetes

Когда модель DeepSeek R1 стала широко обсуждаться в сообществе, я заинтересовался, можно ли эффективно использовать её и другие крупные модели в домашних условиях, не прибегая к дорогостоящим облачным сервисам. Поскольку DevOps и инфраструктурой я увлекаюсь уже несколько лет, у меня постепенно сформировалась домашняя лаборатория, на которой я и решил проверить эту идею.

Эта статья в трёх частях — результат моего опыта в решении этой задачи. Внутри вас ждёт пошаговое руководство по реализации бюджетного распределённого инференса с использованием Ray Serve, vLLM, Kubernetes, Proxmox и других технологий. В первой части мы разберём настройку GPU и его проброс в Proxmox, развернём Kubernetes-кластер, установим GPU Operator и KubeRay Operator.

https://habr.com/ru/companies/flant/articles/906700/

#devops #девопс

Подпишись 👉@i_DevOps

💡 Как DevOps'у не утонуть в логах

Когда в продакшене случается затык, первое, что мы делаем — лезем в логи. Но с микросервисами, десятками подов и различными компонентами инфраструктуры, логов становится столько, что можно утонуть.

Вот несколько проверенных приёмов, которые реально спасают время:

🔹 Стандартизируй формат логов. JSON — твой друг. Структурированные логи можно парсить, фильтровать и индексировать.

🔹 Сразу думай про central logging. Loki + Grafana, Elasticsearch + Kibana или даже простой Fluent Bit + S3. Главное — не SSH на 20 серверов.

🔹 Добавляй trace_id во все логи. Это твой маяк в море. Особенно полезно, когда надо отслеживать один запрос через всю систему.

🔹 Фильтры, фильтры, фильтры. Хорошие правила фильтрации в Grafana или Kibana — это как хороший кофе с утра. Делают день лучше.

🔹 Логи — это не помойка. Не пиши туда print("Hello from service X"). Пиши полезное: ошибки, статусы, идентификаторы.

И напоследок: не забывай про ротацию и retention. Логи не должны жить вечно, особенно если ты не хочешь платить лишнее за storage.

#devops #девопс

Подпишись 👉@i_DevOps

Распределённый инференс и шардирование LLM. Часть 2: скрипт vLLM, Ray Serve для вывода API и настройка KubeRay Cluster

Часть 1

Продолжаем пошагово разбираться с ответом на вопрос о том, как эффективно работать с передовыми LLM, используя доступное оборудование и распределённые вычисления.

В первой части статьи мы подготовили всё необходимое для развёртывания распределённого инференса с Ray Serve и vLLM. Сегодня этим и займёмся. Мы напишем скрипт vLLM, используем Ray Serve, чтобы предоставить внешний HTTP API, а также настроим KubeRay Cluster и развернём в нём Gemma 3.

https://habr.com/ru/companies/flant/articles/906702/

#devops #девопс

Подпишись 👉@i_DevOps

Централизованный vs Децентрализованный ArgoCD

Разворачивая в Kuberentes ArgoCD есть 2 подхода, которые можно использовать, если у вас в контуре несколько кластеров Kubernetes, развертывания в которых неободимо с помощью ArgoCD:

Централизированный. Когда в одном Kubernetes разворачивается один ArgoCD и к нему подключаются все доступные кластера Kuberentes.

Децентрализованный. Когда в каждом Kuberentes’e разворачивается свой персональный ArgoCD, который занимается деплоем в этот Kuberentes.

Разберём плюсы и минусы каждого подхода.

Централизированный ArgoCD

Плюсы:
1️⃣ Единый интерфейс. Можно быстро отсортировать проблемные компоненты и понять причину ошибки.

2️⃣ Мощные CRD ApplicationSets (документация). Позволяют описать один компонент и разом раскатить его на все подключённые кластеры.

3️⃣ Удобное обновление ArgoCD. Достаточно обновить в одном месте, и оно сразу применяется ко всем кластерам.


Минусы:
1️⃣ Сетевые сложности. ArgoCD должен иметь доступ к kube-apiserver всех кластеров. Соответственно нужно продумать маршруты до этих API и защитить их.

2️⃣ Единая точка отказа и уязвимость. Если ArgoCD падает, управление всеми кластерами временно недоступно. Слабое место с точки зрения безопасности. Особенно опасно, если подключать кластеры с Cluster-Admin правами (что все и делают).


Децентрализированный ArgoCD

Плюсы:
1️⃣ Полная автономность кластеров. Каждый кластер полностью управляется своим ArgoCD. Если один ArgoCD сломается, это не повлияет на другие кластеры.

2️⃣ Упрощённая безопасность. Нет необходимости прокидывать сетевые доступы к kube-apiserver из централизованного ArgoCD.

3️⃣ Гибкость в настройке. Можно кастомизировать ArgoCD под конкретный кластер. Удобно для multi-tenant окружений, где каждый проект или команда живут в отдельный Kuberentes кластерах и управляет своим ArgoCD.

Минусы:
1️⃣ Больше инфраструктуры и поддержки. Нужно поддерживать N независимых ArgoCD-инсталляций. Дополнительная нагрузка на команду DevOps.

2️⃣ Отсутствие единого интерфейса. Придётся заходить в каждый ArgoCD по отдельности, чтобы мониторить состояние. (Решается мониторингом). Если нужно что-то обновить во всех кластерах, придётся делать это вручную или автоматизировать через внешние инструменты (еще один ArgoCD?).

3️⃣ Сложность в управлении глобальными компонентами. Например, если нужно одновременно обновить общий Helm-чарт во всех кластерах, придётся либо использовать внешние механизмы (типа CI/CD), либо делать это вручную.


🎯 Какой вариант выбрать?

✔ Много кластеров (10+) → Централизованный ArgoCD, но с HA и жёсткими мерами безопасности.

✔ Изолированные кластеры (air-gapped, private) → Локальный ArgoCD в каждом кластере.

✔ Нужна гибкость в управлении → Децентрализованный вариант.

✔ Важно минимизировать затраты на инфраструктуру → Централизованный ArgoCD.

#devops #девопс

Подпишись 👉@i_DevOps

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

Radius предоставляет:

* Единый опыт разработки для приложений, развертываемых в разных облаках и средах.
* Поддержку нескольких облаков и Kubernetes.
* Интеграции с популярными инструментами, такими как Terraform, Bicep, Helm и другие.
* Ресурсы приложений и вычислений, включая службы, базы данных, кэш, очереди и т. д.
* Безопасность и сетевые политики, управляемые централизованно.

https://github.com/radius-project/radius

#devops #девопс

Подпишись 👉@i_DevOps

🔧 Про grep, который умеет больше, чем ты думаешь

Все знают grep как утилиту “найди мне это слово в этих логах”. Но давай копнём глубже — вот тебе пара трюков, которые удивят даже видавшего виды девопса:


📍 Ищем с контекстом
Хочешь не просто строку, а и то, что рядом?

grep -C 3 "ошибка" /var/log/syslog

Покажет 3 строки до и после найденной.


📍 Ищем по слову, а не по вхождению
Не хочешь ловить ошибка, если в логе есть предошибкака?

grep -w "ошибка" файл.log

Совпадение только по целому слову.


📍 Списки IP-шников? Без проблем.
Вытаскиваем IPv4 из текста:

grep -Eo '([0-9]{1,3}\.){3}[0-9]{1,3}' лог.txt

📍 Ищем рекурсивно, но только в файлах
Искать по директории, пропуская бинарники и показывая имя файла:

grep -rIn --exclude-dir={.git,node_modules} "TODO" .

📍 Цвет для глаз
Визуально быстрее цепляться за результат:

grep --color=auto "fail" журнал.log

Если ты думаешь, что grep — это просто "найди слово", то, возможно, ты не используешь весь его потенциал. А зря 😉

#devops #девопс

Подпишись 👉@i_DevOps

Когда Kubernetes и Go не очень хорошо работают вместе

Go не знает об ограничениях, установленных для его контейнера, что приводит к некоторым проблемам, которые нелегко отследить. Это история о том, как я наткнулся на одну из них.

https://lalatron.hashnode.dev/when-kubernetes-and-go-dont-work-well-together

#devops #девопс

Подпишись 👉@i_DevOps

Домашняя серверная для DevOps: установка GitLab + Let's Encrypt

Привет! Это Александр, DevOps инженер команд Страхования в Банки.ру.
Продолжаю серию статей про домашний сервер. В прошлых материалах я рассказал о выборе железа, сборке и настройке NAS и серверов для дома. В этой и последующих статьях опишу установку нужного софта в домашнюю серверную. Для этого вам, возможно, понадобится VPN на виртуальных машинах или на уровне всей домашней сети (у меня второй вариант).

Начать я бы хотел с установки GitLab. На данный момент у меня достаточно ресурсов, чтобы хостить GitLab и другие сервисы, которые использует DevOps-инженер. Но для чего мне нужен GitLab? Тут всё очень просто: в своей работе я использую подход Infrastructure as Code (IaC) — инфраструктура как код. При таком методе конфигурация инфраструктуры описана в файлах в репозитории, который хранит историю изменений.

В итоге из хранилища можно как развернуть нужный софт за считаные минуты, так и вспомнить, что мы коммитили в репозиторий. GitLab требованиям этого подхода отвечает. К тому же у платформы широкий функционал, который понадобится мне в будущем (CI/CD, например, или хранение terrafrom state в самом GitLab).

https://habr.com/ru/companies/banki/articles/909028/

#devops #девопс

Подпишись 👉@i_DevOps

Периодическая таблица инструментов DevSecOps

Независимо от того, начинаешь ли ты с нуля, устраняешь пробелы или заменяешь существующие инструменты, начни с Периодической таблицы, чтобы подобрать оптимальные решения для своей DevOps-пайплайна.

#devops #девопс

Подпишись 👉@i_DevOps

Сложная оркестрация

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

https://habr.com/ru/articles/910422/

#devops #девопс

Подпишись 👉@i_DevOps

aws-network-policy-agent — это агент политики сети для Kubernetes, который обеспечивает реализацию Kubernetes NetworkPolicy на уровне VPC для Pod'ов в Amazon VPC Lattice. Он используется в сочетании с VPC Lattice integration for Amazon EKS.

Агент реализует политики сети Kubernetes, управляя исходящим трафиком Pod'ов через VPC Lattice Service Network, разрешая или блокируя соединения в соответствии с правилами, заданными в NetworkPolicy.

https://github.com/aws/aws-network-policy-agent

#devops #девопс

Подпишись 👉@i_DevOps

AList — это система для индексирования и управления файлами в облачном хранилище, предоставляющая веб-интерфейс и API. Поддерживает множество облачных хранилищ, таких как OneDrive, Google Drive, Dropbox, WebDAV и другие. Позволяет просматривать, скачивать и делиться файлами через веб-интерфейс без необходимости скачивать их на локальное устройство. AList написан на Go и легко разворачивается.

Основные возможности:

* Поддержка множества облачных хранилищ
* Удобный веб-интерфейс
* Гибкие настройки прав доступа
* REST API для интеграции
* Простота установки и настройки

https://github.com/AlistGo/alist

#devops #девопс

Подпишись 👉@i_DevOps

Docker Images for Frp Based on Alpine and Debian

(amd64, arm32v5, arm32v6, arm32v7, arm64v8, i386, mips64le, ppc64le,riscv64, s390x)

https://github.com/snowdreamtech/frp

#devops #девопс

Подпишись 👉@i_DevOps

Понимание динамического масштабирования ресурсов Kubernetes и ускорения CPU

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

Что такое динамическое масштабирование ресурсов?

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

Для этого Kubernetes использует такие инструменты, как:

* Vertical Pod Autoscaler (VPA) — автоматически регулирует запросы и лимиты ресурсов у подов.
* Horizontal Pod Autoscaler (HPA) — масштабирует количество подов в зависимости от метрик (например, загрузки CPU).

Что такое CPU Boost?

На уровне ядра Linux существует функция под названием CPU Boost (часто называемая Turbo Boost на процессорах Intel), которая позволяет временно увеличивать частоту CPU выше номинальной, если это необходимо.

Kubernetes позволяет использовать CPU Boost, но важно понимать, что:

* CPU boost не гарантируется, даже если ты укажешь высокий лимит CPU.
* Он может сработать, если:

* Контейнер запущен с Guaranteed QoS.
* У узла есть свободные ресурсы.
* Система не перегружена по температуре и энергопитанию.

Почему это важно?

Если твои приложения чувствительны к задержкам и требуют быстрой реакции (например, real-time обработка), то использование CPU Boost может дать кратковременное, но значительное улучшение производительности.

Но полагаться на него как на стабильную стратегию масштабирования не стоит — это больше бонус, чем гарантированный ресурс.

Практические рекомендации

1. Используй requests и limits с умом: слишком заниженные requests могут привести к throttling.
2. Настрой HPA и VPA, чтобы обеспечить гибкость и эффективность.
3. Не рассчитывай на CPU Boost как на основу производительности.
4. Мониторь реальные метрики и подстраивай конфигурации.


https://cloud.google.com/blog/products/containers-kubernetes/understanding-kubernetes-dynamic-resource-scaling-and-cpu-boost

#devops #девопс

Подпишись 👉@i_DevOps

🔁 Как перезапускать сервис только если он завис?

Иногда не хочется перезапускать сервис "на всякий случай", но вот если он реально завис — другое дело. Вот простой способ проверять, активен ли сервис, и перезапускать его при зависании:

#!/bin/bash

SERVICE="nginx"

if ! systemctl is-active --quiet "$SERVICE"; then
    echo "$(date): $SERVICE не активен, пробую перезапустить..." >> /var/log/service_monitor.log
    systemctl restart "$SERVICE"
else
    echo "$(date): $SERVICE работает нормально" >> /var/log/service_monitor.log
fi

🛠 Можно добавить в крон, например, проверку каждые 5 минут:

*/5 * * * * /usr/local/bin/check_nginx.sh

📁 Не забудь сделать скрипт исполняемым:

chmod +x /usr/local/bin/check_nginx.sh

💡 Можно заменить nginx на любой другой системный сервис.

👉@bash_srv

k'exp - Kubernetes Explorer

Создан не для управления продом, а для изучения кубера через визуализацию.

k'exp предназначен для:

Изучение и исследование возможностей Kubernetes
Разработка приложений (предварительные наборы объектных графов для каждого приложения)
Разработка контроллеров и операторов (динамические графы объектов)
[скоро появится] Postman-подобный клиент и конструктор запросов для Kubernetes API
k'exp может отражать состояние вашего кластера в режиме реального времени:

https://github.com/iximiuz/kexp

#devops #девопс

Подпишись 👉@i_DevOps

Как проверить, что твои бэкапы не просто занимают место?

Резервное копирование — это как страховка: пока не случится беда, никто о нём не думает. Но когда приходит время восстановления, многие с удивлением обнаруживают, что бэкап либо повреждён, либо неполон, либо вовсе не содержит нужных данных. Как избежать этого?

🔹 Автоматическое тестирование восстановления
Настрой регулярное восстановление из резервных копий в тестовой среде. Например, можно развернуть временный сервер и поднять на нём восстановленную БД.

🔹 Сравнение контрольных сумм
Для файловых бэкапов сохраняй хэши (MD5, SHA256) до и после резервного копирования. Это поможет выявить изменения или повреждения данных.

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

🔹 Глубина хранения и дедупликация
Не удаляй старые бэкапы слишком рано. Иногда проблему замечают через несколько недель. Храни несколько версий резервных копий, но следи за размером и удостоверься, что не копируешь лишнее.

🔹 Периодические мануальные проверки
Раз в месяц пробуй восстановить данные вручную. Это займёт 15 минут, но может спасти компанию от потерь.

Бэкап, который не тестировали на восстановление — это просто набор битов. Убедись, что твои копии действительно можно использовать!

#devops #девопс

Подпишись 👉@i_DevOps

🚀 Kubernetes 1.32: пять фич, которые стоит попробовать прямо сейчас

* Auto-delete PVC для StatefulSet
StatefulSet наконец-то умеет сам удалять PVC, когда поды и сам объект больше не нужны. Включите StatefulSetAutoDeletePVC и задайте persistentVolumeClaimRetentionPolicy — забудете про ручную очистку хранилища.

* Память-backed emptyDir с динамическим размером
Теперь emptyDir { medium: "Memory" } может автоматически подстраиваться под лимиты RAM вашего пода (или заданный лимит), а не фиксированные 50 %. Отлично для временных кэшей и build-джобов.

* Field Selectors для CRD
Custom Resource теперь поддерживает --field-selector, как “родные” объекты K8s. Фильтруйте CR легко, без дополнительных label-index.

* status.hostIPs в GA
Подам больше не нужен костыль, чтобы узнать IPv4/IPv6 узла в dual-stack-кластере: адреса приходят прямо в Downward API.

* Node name в ServiceAccount JWT
Узел теперь прописывается в SA-токен, что упрощает Validating/Mutating Admission Policies и сокращает риск эскалации прав.

💡 Как обновиться

1. Скачайте свежий kubeadm 1.32 и выполните kubeadm upgrade plan && kubeadm upgrade apply v1.32.
2. Проверьте deprecated API в релиз-нотах.
3. Включите нужные Feature Gates — и в бой!

#devops #девопс

Подпишись 👉@i_DevOps