⚡️ 20 kubectl команд, которые экономят часы в проде

Когда что-то падает — не нужен весь kubectl.
Достаточно этих команд 👇

🧪 Быстрый дебаг
• kubectl get pods -A --field-selector=status.phase!=Running
• kubectl get pods -A --sort-by=.status.containerStatuses[*].restartCount
• kubectl describe pod <pod> -n <ns>
• kubectl get pods -A | grep Pending

📜 Логи и ресурсы
• kubectl logs <pod> -n <ns> --previous
• kubectl top pods -A
• kubectl describe node <node>

🧭 Сеть и размещение
• kubectl get pod <pod> -n <ns> -o wide
• kubectl get pods -A -o wide | grep <node>
• kubectl get svc -A -o wide
• kubectl run tmp-shell -it --rm --image=busybox -- /bin/sh

🚀 Роллауты и откаты
• kubectl port-forward svc/<svc> 8080:80
• kubectl rollout history deployment/<name>
• kubectl rollout undo deployment/<name>
• kubectl get deployment <name> -o yaml

🧩 События и конфиг
• kubectl get events -A --sort-by=.metadata.creationTimestamp
• kubectl describe svc <svc>
• kubectl get endpoints <svc>
• kubectl get ingress -A

Освоишь эти команды - будешь закрывать 90% проблем в проде намного быстрее.

Сохрани, чтобы не искать потом 🔖

🚀 Скоро: HashiCorp Vault 2.0!

В открытом доступе появился релиз-кандидат HashiCorp Vault 2.0 — первого крупного обновления за долгое время. Вас ждут автоматическая ротация секретов, передовые протоколы PKI и полная интеграция с Kubernetes.

🔐 Главные нововведения

• Автоматическая ротация секретов: Снижение числа инцидентов на 75% и сокращение разрастания учетных данных на 90% благодаря устранению статических кредов и динамической выдаче секретов.
• Передовые PKI-протоколы: Полная поддержка протоколов SCEP, EST и CMPv2 для автоматизации выдачи сертификатов. Теперь подписывать промежуточные сертификаты стало проще, а в alt_names можно использовать глоб-шаблоны.
• Нативная интеграция с Kubernetes: Динамическая инъекция секретов на уровне подов без изменения кода.
• Доработки и исправления: Обновление Go до версии 1.25.7, улучшение статуса sys/seal-backend-status для лучшего мониторинга и поддержка HashiCorp-плагинов как внешних бинарных файлов.

Финальный релиз, как ожидается, окончательно сформирует стандарт управления секретами в эпоху zero-trust. Официальной даты выхода пока нет, но ждать, судя по всему, осталось недолго. (час назад вышел билд на github: https://github.com/hashicorp/vault/releases/tag/v2.0.0)

https://discuss.hashicorp.com/t/vault-2-0-0-rc1-released/77296

• SCIM-провижининг: Полная автоматизация жизненного цикла пользователей и групп через синхронизацию с внешними IDP-платформами.
• Нативная поддержка SPIFFE: Аутентификация рабочих нагрузок с помощью JWT-SVID, что позволяет бесшовно вписаться в экосистему SPIFFE.
• Визуальный конструктор политик: Генерация ACL-политик прямо в веб-интерфейсе Vault. Больше не нужно писать сложные правила вручную.
• Workload Identity Federation (WIF) для синхронизации секретов: Теперь для настройки синхронизации с AWS, GCP или Azure не нужны статичные креды — всё работает через федерацию.
• Расширение для публичных центров сертификации (Public CA): Vault теперь умеет оркестрировать выдачу и управление жизненным циклом сертификатов от публичных CA.
• In-Place Encryption SDK: Шифрование и дешифрование данных на стороне клиента без отправки данных в Vault. Ключевой функционал для конфиденциальных сред.
• Ротация паролей локальных учетных записей: Управление учетными данными локальных пользователей Linux с автоматической ротацией.
• Умная ротация для LDAP: Гибкая настройка ротации статических кредов LDAP: начальные пароли, самоуправляемая ротация, расписания и политики повторных попыток при сбоях.
• Мультикластерные уведомления о событиях: Теперь вы не пропустите ни одного важного изменения в вашей распределенной системе.
• Улучшенный онбординг: Новый GUI помогает быстрее освоить ключевые функции, а процесс создания неймспейсов стал интуитивно понятным.

Пополнение среди проектов от подписчиков:
Lynxdb - schema-on-read база данных и аналитическая система для анализа логов.

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

Lynx Flow язык запросов LynxDB,
По сути, это упрощённый и более интуитивный слой (синтаксический сахар) над Splunk SPL2, ориентированный на удобную работу с логами.

Возможности:
- режим конвейера - чтение из стандартного ввода или файлов, работает как grep. Нет сервера, нет конфигурации.
- Lynx Flow - group, let, parse, order by, join, CTE, доменные синтаксисы и многое другое. Частичная совместимость с SPL2.
- полнотекстовый поиск - инвертированный индекс FST + roaring bitmaps, фильтры Блума для пропуска сегментов.
- столбцовое хранение - пользовательский формат .lsg, временные метки с дельта-вариантами, кодирование по словарю, Gorilla XOR, LZ4
- материализованные представления - предварительно вычисленные агрегации с автоматической переадресацией запросов, ускорение до ~400 раз.
- кластерный режим - добавьте --cluster.seeds для распределенной работы; общее хранилище на основе S3.
- загрузка данных без предварительной обработки - Elasticsearch_bulk, OpenTelemetry OTLP, Splunk HEC

https://github.com/lynxbase/lynxdb

KubeUser — это Kubernetes оператор для управления пользователями, доступами и kubeconfig без Keycloak, Dex и других тяжёлых IAM решений. Вместо ручной выдачи сертификатов и RBAC всё описывается декларативно через User CRD, а оператор сам создаёт доступы и готовый kubeconfig.

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

KubeUser использует стандартный Kubernetes CSR API, автоматически создаёт RoleBinding и ClusterRoleBinding, а kubeconfig сохраняет как Secret внутри кластера.

Ubuntu 26.04 LTS: на что смотреть перед миграцией с 24.04

23 апреля Canonical выпустил Ubuntu 26.04 LTS — Resolute Raccoon. Про сам релиз уже написали все, поэтому не будем повторяться — и посмотрим на релиз с другой стороны.

26.04 — это не косметическое обновление. cgroup v1 удален, DSA-ключи в OpenSSH больше не работают, apt-key окончательно убран, классический sudo заменен на Rust-реализацию, формат конфигов Dovecot изменился, Postfix больше не работает в chroot по умолчанию. Запустить do-release-upgrade и уйти на обед уже не получится: часть систем после такого обновления просто не поднимется.

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

@usr_bin_linux

Fail2Ban больше не нужен? Разбираем PerSourcePenalties в OpenSSH на Ubuntu 26.04

Начиная с OpenSSH 9.7, sshd умеет автоматически ограничивать на время подозрительные IP без Fail2Ban и iptables. В Ubuntu 26.04 эта функция уже включена по умолчанию — даже если в sshd_config про неё ничего не написано. Автор этой статьи предлагает разобраться с тем, как это работает.

@usr_bin_linux

Isopolicy — CLI инструмент от разработчиков Cilium для упрощения управления, проверки и тестирования Network Policy от Cilium в Kubernetes.

Основные функции:
- Статический анализ и проверка синтаксиса: Выполняет статический анализ политик для выявления распространенных ошибок конфигурации, таких как отсутствующие labels или непреднамеренные наложения.
- Моделирование политик: Включает команду моделирования, которая создает среду «что если». Это позволяет операторам предварительно оценить, как новые, измененные или удаленные политики повлияют на доступ к сети для разных идентификаторов или namespaces, не затрагивая работающий кластер.
- Историческая проверка: При подключении к Hubble Timescape может воспроизводить исторические потоки трафика, чтобы показать, как различные политики обрабатывали бы прошлый трафик, повышая общую «чистоту политик».
- Интеграция с GitOps: Может быть интегрирован в конвейеры CI/CD для автоматической проверки синтаксиса политик во время PR, блокируя мерджи, содержащие неподдерживаемые конструкции или очевидные ошибки.

Примеры использование можно посмотреть тут и тут.

👉 Linux - strace: один из самых недооценённых инструментов

Он нужен в тот момент, когда приложение падает, не видит конфиг, не может найти библиотеку или ругается на файл, которого “вроде бы нет”.

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

Но strace позволяет не гадать.

Он показывает, к каким файлам процесс реально обращается во время работы. Не то, что написано в документации. Не то, что вы предполагаете. А то, что программа делает на самом деле.

И вот тут часто всё становится очевидно: приложение ищет config не в той директории, лезет за библиотекой по старому пути, не может открыть сертификат или получает отказ из-за прав доступа.

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

Главная идея простая: когда Linux-программа ведёт себя непонятно, сначала посмотри её системные вызовы.

https://www.youtube.com/shorts/iRnNQWKozSA

☁️ ITENTIS CLOUD: как на инфраструктуре начинают зарабатывать

Реальные цифры: системный администратор перешел на Itentis Cloud по реферальной программе, изначально — просто попробовать: перевести несколько клиентов, посмотреть, как работает облако.

Сейчас он зарабатывает 70–100 тыс. руб. в месяц на партнерской комиссии. И растет дальше — с каждым новым клиентом.

📣 Вы можете так же:
подключаете клиентов к ITENTIS CLOUD — получаете процент с их инфраструктуры.

ITENTIS CLOUD — это тот же уровень технологий (VPC, Kubernetes, S3, Tier III), но без переплаты за бренд и с прозрачными тарифами.

Плюс — живая поддержка 24/7, которая реально помогает довести проекты до результата.

💥 Попробуйте сами: перенесите часть проектов — первые 14 дней бесплатно.

Переходите на страницу ITENTIS CLOUD, чтобы посмотреть условия и начать зарабатывать.

Партнерская программа
ITENTIS CLOUD

boring

Простой менеджер SSH-туннелей. Управляется из командной строки.

Репыч на Гитхаб

@usr_bin_linux

Lies, damned lies, and Elastic's benchmarks

https://www.gouthamve.dev/lies-damned-lies-and-elastics-benchmarks

#elasticsearch #clickhouse #prometheus #benchmarks #mimir

А Вы знали, что кроме постгресса есть другие базы данных? Быстрые, легко масштабируемые, с богатой экосистемой, поддерживаемые разными компаниями. Один из таких примеров - MySQL c форками MariaDB и Percona Server.

Если вы работаете с MySQL или хотели бы больше узнать об этой СУБД - добро пожаловать на единственный на данный момент в России интенсив, покрывающий все ключевые этапы эксплуатации MySQL в высоконагруженных приложениях: от установки до оптимизации запросов и масштабирования.

Два подряд интенсива проходят в разное время: вечерний для тружеников европейской части РФ пройдет с двадцать третьего по двадцать пятое июня ежедневно с 19:00 до 21:00 по Московскому времени в режиме онлайн. Утренний, для удобства жителей Сибири, Байкала и Дальнего Востока - с тридцатого июня по второе июля с 10:00 утра до 12:00 по Москве.

Каждая встреча посвящена одному большому разделу.

День 1: Ставим и тюним MySQL для работы с высокими нагрузками
Поговорим про версии и форки, про начальную настройку и общую архитектуру. Разберемся что и как нужно мониторить, что бы увидтеть проблемы раньше, чем база упадет.

День 2: Учимся писать самые быстрые в мире запросы MySQL и использовать ClickHouse для аналитики
Поговорим про оптимизацию запросов, про индексы и миграции. Отдельно зацепим внешние инструменты для работы с аналитическими и полнотекстовыми запросами

День 3: Строим отказоустойчивую инфраструктуру для MySQL
Часть интенсива, которая очень пригодится тем, кто работает с действительно высокими нагрузками: поговорим о масштабировании, горизонтальном и функциональном шардировании, разберемся в тонкостях работы репликации (асинхронной, синхронной и мастер-мастер) и научимся балансировать нагрузку.

Подробности и билеты по ссылке https://fournines.ru/mysql_workshop

PII-Shield — open-source инструмент для защиты логов и данных от утечки персональной информации прямо в Kubernetes . Он работает как sidecar контейнер, перехватывает stdout/stderr, находит секреты и чувствительные данные до того, как они попадут в лог-системы.

Сочетание Shannon Entropy для поиска неизвестных секретов (токены, API-ключи, пароли) и O(1) regex для точного детектирования известных паттернов снижает false positive и позволяет находить даже то, что не было заранее описано правилами.

PII-Shield работает полностью локально, без API вызовов наружу, с почти нулевой нагрузкой на GC. Интересный проект, чтобы попробовать безопасно коррелировать логи между сервисами, не раскрывая реальные данные.

AI SRE Summit 2026: выжимка из заметок

Привет, киты 🐳.

Наткнулся на пост на реддите и решил поделиться.

AI в SRE - это уже не демо, а продакшен. Вопросы сместились с "как это работает" на "кто отвечает, когда оно ломается".

Ключевые тезисы

1. Стоимость и надёжность - это одно целое
ИИ-агент, который лечит инцидент автоскейлингом, может накрутить счёт за облако на $50K. Если в ваших SLO нет бюджета - вы не контролируете надёжность.

2. Нельзя наложить ИИ на сломанную платформу
Broken platform + AI = более сложный баг, который сложнее отладить. Сначала наведите порядок в конфигурациях, логировании и деплое. Потом добавляйте агентов.

3. Observability теперь для машин
ИИ-агенту нужна структурированная, семантически богатая телеметрия. Если логи - это "text/plain с примесью надежды", агент будет гадать. Гадание в продакшене = инцидент.

4. У ИИ-агента нет владельца
Кто отвечает, когда автономный агент неправильно интерпретировал метрику или запустил неверный скрипт? Пока это серая зона. Нужны чёткие рамки: что агент делает сам, а где нужен человеческий апрув.

5. Роль SRE трансформируется
Было: тушим пожары, пишем ранбуки, дежурим.
Становится: проектируем границы автономии, пишем политики, интерпретируем решения ИИ.

Что уже сделать бы надо

- Добавьте бюджетные лимиты (деньги) в error budgets. Нет денег - нет надёжности
- Структурируйте логи под ИИ: векторизуйте, тегируйте, давайте контекст. Logfmt лучше свободного текста
- Введите режимы для агентов: автономно / с апрувом / только рекомендации. Переключайте по уровню риска
- Документируйте решения ИИ для постмортема и обучения
- Тренируйте команду на гибридных сценариях: человек + ИИ, а не "или-или"

Что я думаю

Главный риск - не технология, а управленческая иллюзия: запустили агента и можно расслабиться. Не расслабляйтесь - Н, наблюдайте за наблюдателем.

ИИ - усилитель процессов. Хаос ускорит хаос. База + ИИ = масштабирование надёжности.

Вопрос: если агент чинит инциденты, кто чинит агента когда он сломался?

P.s. вспоминается статья 1982 г "Иронии автоматизации", проблемы те же