😐 Устали деплоить в Kubernetes через kubectl и бесконечные CI-скрипты? Хотите, чтобы деплой был воспроизводимым, контролируемым и прозрачным?

ArgoCD — де-факто стандарт GitOps для Kubernetes, который используют в крупных компаниях.

🚀 Запустил курс: «ArgoCD: GitOps-деплой и автоматизация в Kubernetes»

В курсе:

- GitOps — что это и зачем он нужен.
- Установка и настройка ArgoCD.
- Application и App of Apps.
- GitOps-деплой приложений.
- ArgoCD Image Updater (автокоммиты новых образов).
- Notifications (Telegram).
- SOPS и шифрование секретов в Git.

Курс подойдёт, если у вас есть базовые знания Docker и Kubernetes, вы DevOps или просто хотите прокачать практический GitOps-навык, который точно встретится в работе.

🆓 Бесплатные доступы для 5 первых участников:

1 ссылка
2 ссылка
3 ссылка
4 ссылка
5 ссылка

🔥 После прохождения — буду рад фидбеку!

Helm — менеджер пакетов для Kubernetes, который упрощает установку, обновление и управление приложениями, упакованными в Helm-чарты.

Но... Конфликты при apply, CRD которые «поставились один раз и забылись», ресурсы зависли в Pending, а ты не понимаешь почему, плагины для diff и secrets как обязательный набор… Знакомо? 🤬

Есть инструмент, после которого возвращаться к классическому Helm уже не захочется.

😳 Знакомьтесь — Nelm. Разработка компании Flant, современная альтернатива Helm, полностью совместимая с вашими текущими Helm-чартами и релизами.

🤔 Коротко: Helm, каким он должен был быть в 2026 году:

✅ Полная совместимость и простая миграция — Nelm построен на Helm, ничего переписывать не нужно.

✅ Вместо проблемного клиентского 3-Way Merge применяется Kubernetes Server-Side Apply.

✅ Контролируемый порядок деплоя — Nelm строит граф зависимостей ресурсов, а не надеется на хуки. Порядок можно явно задать аннотациями.

✅ UX при деплое — Nelm во время установки/обновления выводит удобный прогресс, постоянно показывая статусы ресурсов, логи контейнеров и события (и даже автоматически откатывается при сбоях).

✅ nelm release plan — точный план изменений перед применением (как terraform plan, но для Kubernetes).

✅ Секреты из коробки — шифрованные values без плясок с плагинами.

✅ Расширенное управление ресурсами — Nelm улучшил работу с CRD и политику жизненного цикла. Например, CRD из папки crds/ обновляются при каждом upgrade (в Helm они устанавливаются только однажды).

🎥 На видео — обычный nelm release plan и nelm release install: посмотрите, как Nelm генерирует план изменений, а во время установки в реальном времени показывает готовность ресурсов, подтягивает логи подов и выводит NOTES.

Helm после такого выглядит… ну, вы поняли 😅

📌 Инструмент новый, но если вы живёте в Kubernetes и вам важен контроль деплоя, Nelm точно стоит попробовать и положить в свою DevOps-копилку.

🍴 Попробуешь Nelm или Helm пока и так норм? 👀

😎 Сегодня пятница, а что это значит? Правильно — в прод не деплоим. А ещё новая большая и продуманная программа: «Профессия: DevOps-инженер»

Сделали её совместно с Pragmatic Programmer и Rotoro cloud!

💗 На 3 дня объявляем неприличные скидки! Все курсы в программе по отдельности стоят 15 088 руб.

Но по промокоду: FIRST_3_DAYS_MAX_OFF, сегодня-завтра-послезавтра можно забрать всю программу за 4 974 руб! (он уже вшит в ссылку).

😎 Только тсс... об этом лайфхаке никому не рассказывайте!

А что внутри?

Внутри 7 топовых практических курсов для становления DevOps-инженером в 2026 году:

✅ Linux
✅ Docker
✅ Hello, DevOps!
✅ Git + GitHub
✅ Kubernetes
✅ GitLab CI
✅ Prometheus

🥹 390+ уроков, 30 часов видео и 600+ тестовых и интерактивных задач!

⌨️ Что такое траблшутинг и почему это самый важный навык инженера?

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

Вот это и есть момент, когда начинается траблшутинг.

🤔 Что это вообще такое?

Траблшутинг — это не просто «на 7 бед — один резет». Это системная детективная работа:

✅ Замечаешь симптом.
✅ Выдвигаешь гипотезы.
✅ Проверяешь их по одной.
✅ Находишь настоящую причину.
✅ Устраняешь с минимальным риском.

В Linux у вас всегда есть улики (нагрузка, логи, сетевые соединения, открытые файлы), подозреваемые (процессы, сервисы, конфиги) и инструменты (ps, top, journalctl, tcpdump). Задача — собрать улики так, чтобы они указывали на одного виновника.

Главные правила бойцовского клуба:

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

🧠 Симптом ≠ причина. Копай глубже.
Высокий CPU — это не проблема. Медленные запросы — это не диагноз. Это симптомы. Задача траблшутера — выстроить цепочку: от симптома к реальному источнику.

🔍 Работай гипотезами, а не рандомными командами.
Не «попробую эту команду, если не поможет — следующую». А: сформулировали → поняли, что должно быть правдой → проверили. Ошибочная гипотеза — не провал, а шаг, который сделал картину чуть яснее.

💡 Каждый шаг должен сужать круг поиска.
Каждый шаг должен либо подтверждать гипотезу, либо исключать целый класс причин. Это как идти с фонариком в тёмной комнате — вы не освещаете всё сразу, вы постепенно делаете тьму меньше.

Почему это один из самых ценных навыков?

Инженер, который умеет системно разбирать инциденты:

✅ Сокращает время простоя — меньше денежных и репутационных потерь.
✅ Меньше зависит от помощи коллег.
✅ Видит точки улучшения: где добавить мониторинг, что автоматизировать.
✅ Прокачивает мышление, применимое далеко за пределами Linux

Именно это отличает человека, который выполняет задачи, от человека, которому доверяют сложные системы.

Со временем приходит важное ощущение: инцидент — это не катастрофа. Это задача. Иногда сложная, иногда неприятная — но у неё всегда есть причина и решение.

Умение это чувствовать — и есть настоящий траблшутинг 😉

👨‍💻 Код в Прод

Ставишь Nginx Ingress Controller в Kubernetes — и получаешь два балансировщика.

В облаке появился свой балансировщик, а в неймспейсе ingress-nginx крутится под с Nginx.

⏳ Знакомо? А зачем два?

Отличный вопрос с реального DevOps собеседования! Звучит просто, но на практике большинство спотыкается об это. 💀

Попробуйте проверить себя с помощью небольшого теста ниже. После ответа вы можете отобразить объяснение и сравнить свой ответ.

🗒 Варианты ответов:

1️⃣ Облачный балансировщик обеспечивает внешний доступ и маршрутизирует трафик в соответствии с конфигурациями Ingress, а Nginx используется только как прокси внутри кластера.

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

3️⃣ Облачный балансировщик принимает внешний трафик на уровне IP и портов, а Nginx внутри кластера маршрутизирует его по хостам и путям на основе правил Ingress.

4️⃣ Облачный балансировщик обрабатывает HTTP, а Nginx — HTTPS, вместе они обеспечивают полную TLS терминацию.

💡 Объяснение:

При установке Ingress Controller создаётся сервис с типом LoadBalancer — это сигнал облаку создать балансировщик с публичным IP.

Облачный балансировщик работает на L4 уровне — знает только IP и порт, больше ничего. Его задача — принять трафик снаружи и отправить на сервис ingress-nginx, который уже направляет трафик на поды Nginx.

Nginx делает умную работу на L7 уровне — читает Ingress-конфигурации и направляет трафик на нужные сервисы внутри кластера по имени хоста (api.example.com) и пути (/api/v1/bananas).

Правильный ответ: 3️⃣

👨‍💻 Код в Прод

🐧 Ты создал облачный сервер. Добавил туда SSH-ключ… как тебе казалось.

Пытаешься зайти:

ssh foo@158.165.43.21

❌ Permission denied.

😭 Отлично. Единственный доступ, который у тебя остаётся — serial console от облака.

Serial console — это доступ к серверу через системную консоль: ты подключаешься не по SSH, а напрямую к инстансу, как будто через физический терминал, только в браузере.

Но проблема... Copy-paste в нём работает очень плохо, и просто скопировать и вставить ключ не получится.

Хитрый вопрос с реального DevOps собеседования! Подумай, как бы ты выкрутился? 🤔

💡 Решение:

1. Можно временно включить доступ по паролю, подключиться к серверу по SSH из своего терминала и добавить ключ в ~/.ssh/authorized_keys.

👉 Способ рабочий, но важно не забыть потом отключить вход по паролю.

2. Если у вас есть аккаунт на GitHub, можно использовать его как источник публичных ключей:

curl https://github.com/<ваш логин>.keys >> ~/.ssh/authorized_keys

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

👨‍💻 Код в Прод