13139
Присоединяйтесь к нашему каналу и погрузитесь в мир DevOps Сотрудничество, реклама: @devmangx Менеджер: @Spiral_Yuri РКН: https://clck.ru/3P8kFH
У Linux Foundation есть целая библиотека бесплатных обучающих материалов по Linux, DevOps и облачным технологиям.
https://training.linuxfoundation.org/full-catalog/
👉 DevOps Portal
Как защитить проброшенный порт Docker с помощью правил файрвола
Оказывается, корректно защитить опубликованный порт контейнера от нежелательного доступа извне не так просто — даже если порт привязан к внутреннему IP-адресу хоста.
Подробнее: https://labs.iximiuz.com/challenges/docker-networking-prevent-unexpected-access-to-published-port
👉 DevOps Portal
⚡️ Онлайн-митап IT_ONE: Между кодом и продом
Три прикладных доклада для тех, кто отвечает за стабильность инфраструктуры. Обсудим на встрече защиту Helm-чартов
от некорректных данных, научим писать надежные проверки
на helm-unittest и разберем развертывание собственной LLM-модели для всей команды.
Приглашаем разработчиков, DevOps-, QA- и SRE-инженеров, тимлидов и архитекторов.
12 ноября
18:00 (мск), онлайн
Регистрация: по ссылке
В программе митапа:
1️⃣ Персональный ИИ своими руками.
Руслан Кашафутдинов расскажет, как развернуть свою ИИ-модель и работать без квот облачных сервисов.
2️⃣ Helm-чарты: когда они действительно нужны.
Виталий Перваков разберет защиту от некорректных данных и сравнит инструменты проверки конфигураций.
3️⃣ Стабильные unit-тесты для Helm-чартов.
Андрей Слатимов покажет, как с помощью helm-unittest находить ошибки шаблонизации и проверять обратную совместимость.
Обязательно к прочтению DevOps-инженерам
Реальный инцидент, в ходе которого Netflix столкнулся с серьёзной деградацией сетевой производительности в разных регионах.
В статье подробно разбирается, как инженерные команды Netflix обнаружили проблему, провели расследование и в итоге устранили её.
Главный урок?
Когда возникают проблемы с сетью и вы уже успели обвинить сетевиков и разработчиков, не забудьте проверить, не обновлялось ли ядро Linux 😁
Подробный разбор: https://netflixtechblog.com/investigation-of-a-cross-regional-network-performance-issue-422d6218fdf1
Несколько технических понятий из статьи:
1. Размер TCP-окна (TCP Window Size) — механизм TCP, управляющий потоком данных между отправителем и получателем. Определяет, сколько данных получатель может принять до того, как потребуется подтвердить их получение (ACK).
2. /proc/sys/net/ipv4/ — директория, содержащая множество параметров ядра, связанных с TCP. Их можно настраивать, чтобы изменять поведение TCP-стека в Linux.
3. /proc/sys/net/ipv4/tcp_window_scaling — файл, через который можно проверить состояние масштабирования TCP-окна (TCP Window Scaling). Временно включать и отключать этот механизм можно с помощью sysctl.
👉 DevOps Portal
Удобный способ управления алиасами kubectl
До Kubernetes v1.33 алиасы приходилось вручную прописывать в .bashrc или .zshrc, смешивая их с остальными настройками shell.
Это не было ни нативным, ни структурированным решением.
Теперь с помощью kuberc можно хранить все алиасы kubectl в отдельном YAML-файле.
Просто, удобно и аккуратно. Более того, конфигурацию можно хранить под версионным контролем.
Вот подробный практический гайд, который поможет быстро разобраться с настройкой.
Подробный гайд: https://devopscube.com/kubectl-aliases/
👉 DevOps Portal
Как получить доступ к сервису, запущенному на Docker-хосте, из контейнера?
Продолжаем серию про Docker Networking. Если известен IP-адрес одного из сетевых интерфейсов хоста, всё просто. Но что делать, если он неизвестен?
Задача 1: https://labs.iximiuz.com/challenges/docker-networking-connect-app-to-host-service
Задача 2: https://labs.iximiuz.com/challenges/docker-networking-reach-host-service-bound-to-localhost
👉 DevOps Portal
В этом туториале показано, как мигрировать кластер EKS с выведенного из эксплуатации контроллера ingress-nginx на Gateway API. Разбираются CRD контроллера AWS Load Balancer Controller и переключение трафика без простоя (zero-downtime).
➜ douglas0n/migrating-from-ingress-nginx-to-gateway-api-on-eks-0a514952e91b" rel="nofollow">https://medium.com/@douglas0n/migrating-from-ingress-nginx-to-gateway-api-on-eks-0a514952e91b
👉 DevOps Portal
31 октября AvitoTech собирает инфраструктурных инженеров на Avito Infraween Party 🤩
Вместо классических докладов — два круга открытых дискуссий: можно будет обсудить инфраструктурные задачи, поделиться своими кейсами и поспорить о решениях с экспертами AvitoTech и другими участниками.
А на афтерпати устроят настоящий чемпионат по метанию старой списанной техники 🔥
Победителей наградят реальными чемпионскими поясами!
Хороший повод пообщаться с инфракомьюнити — зарегаться можно тут!
P. S. Кстати, костюмы максимально приветствуются! Так что если хотите прийти в образе, welcome.
K8s-комьюнити снова встретится в Москве
5 ноября в 19:00 пройдёт четвёртый KuBeer Talks!
Формат камерных встреч стартовал ровно год назад. С тех пор кубер-комьюнити не раз собиралось в баре, чтобы послушать неформальные доклады, обсудить рабочие «боли» и найти тех, кто сталкивается с теми же задачами.
Приглашаем вас отметить наш первый день рождения 🎂
В программе:
◾«Опыт работы с VTEP-схемой в Cilium», Екатерина Низовцева
◾«Закон Гудхарта для бекапов K8s», Артём Горячев
◾Открытый микрофон — для всех, кому есть чем поделиться
И это не всё — скоро анонсируем ещё один доклад.
Участие бесплатное, как и первые три кружки любого напитка из меню. Количество мест ограничено, успевайте зарегистрироваться!
Регистрация
DevOps-инструмент недели: Kubetail
Отладка по логам нескольких подов Kubernetes может быть неудобной. Приходится запускать kubectl logs, переключаться между подами и разбираться, что пошло не так.
Ситуация усложняется, когда у приложения несколько реплик.
Здесь на помощь приходит Kubetail — опенсорсный дашборд для просмотра логов Kubernetes в реальном времени, который позволяет собирать логи нескольких подов в одном интерфейсе.
Основные возможности:
• Просмотр логов нескольких подов и контейнеров в одном месте.
• Автоматическое обновление временной шкалы при запуске, остановке или замене подов.
• Фильтрация логов по временному диапазону, зоне доступности, архитектуре CPU или ноде.
• Переключение между несколькими кластерами через десктопное приложение.
Начать работу: GitHub
Kubetail читает логи напрямую через Kubernetes API, поэтому данные остаются внутри кластера без необходимости подключать внешний сервис логирования.
Вместо постоянного переключения между терминалами можно отслеживать происходящее в подах приложения через единый интерфейс.
👉 DevOps Portal
ИИ-агенты для DevOps-инженеров: объяснение принципов работы
ИИ-агенты становятся важной частью DevOps и платформенной инженерии.
Но прежде чем создавать собственного агента, необходимо разобраться, что именно делает приложение агентом.
В отличие от традиционного приложения, которое следует фиксированному набору инструкций, ИИ-агент может самостоятельно решать, что делать дальше, на основе полученной информации.
В одном из недавних выпусков рассылки разобрали ключевые концепции ИИ-агентов, включая фреймворки для разработки агентов, инструменты, циклы работы агента, машины состояний, этапы согласования и память.
Начать изучение: https://newsletter.devopscube.com/p/ai-agents-part01
👉 DevOps Portal
В этом туториале показано, как развернуть мультитенантную платформу Apache Spark в Kubernetes с использованием Spark Operator, Volcano, Helm, Airflow, общих образов, ограничений на рабочие нагрузки и мониторинга.
➜ https://medium.com/towards-data-engineering/building-a-production-grade-apache-spark-platform-on-kubernetes-2984e083dd71
👉 DevOps Portal
Сетевые основы 101: Как работает маршрутизация трафика
Знаете ли вы, что компьютеры могут обмениваться данными только с соседями (участниками одной подсети)? Но как тогда мы передаём пакеты через Интернет? Именно здесь вступает в игру маршрутизация.
Узнайте больше: https://labs.iximiuz.com/challenges/networking-configure-basic-routing
👉 DevOps Portal
Изучение Linux через устранение неполадок на серверах
Подборка практических сценариев по диагностике и устранению проблем, которые помогут прокачать навыки работы с Linux:
- Демон отправки логов, который не запускается — https://labs.iximiuz.com/challenges/linux-strace-failing-daemon
- Демон конвертации изображений с отсутствующими зависимостями — https://labs.iximiuz.com/challenges/linux-missing-shared-library
- Воркер-сервис, который постоянно исчезает — https://labs.iximiuz.com/challenges/linux-debug-vanishing-worker-service
- Несколько сервисов разработки, конфликтующих из-за одного порта — https://labs.iximiuz.com/challenges/linux-resolve-port-conflict
- Привилегированный демон с некорректно настроенным контролем доступа — https://labs.iximiuz.com/challenges/linux-restrict-unix-socket-access
В этом кейсе показано, как WSC Sports полностью перестроила модель деплоя: от пайплайнов с helm upgrade до полноценного GitOps на базе ArgoCD ApplicationSets.
Рассматриваются:
- Архитектура монорепозитория с единым Helm-чартом;
- Теневые деплои;
- AppProjects;
- Механизмы заморозки кода в CI.
➜ elad320011/gitops-at-enterprise-scale-inside-wsc-sports-deployment-platform-5ee373431309" rel="nofollow">https://medium.com/@elad320011/gitops-at-enterprise-scale-inside-wsc-sports-deployment-platform-5ee373431309
👉 DevOps Portal
Как восстановить инфраструктуру после крупного сбоя в облаке
Настроить резервное копирование — это полдела. Чтобы бэкапы помогли при аварии, нужно заранее проверить, получится ли восстановить из них данные и запустить приложения.
На что стоит обратить внимание — в разборе инженеров KTS, которые поделились опытом восстановления сервисов на новой площадке:
- Бэкап ≠ восстановление. Нужно проверять целостность и доступность резервных копий, а главное — возможность развернуть из них работоспособную систему.
- RTO и RPO недостаточно прописать в документации. Запуск может задержаться, пока команда ждёт снапшоты и переносит данные. Поэтому важно проверять сроки возвращения сервисов в работу и актуальность данных в резервных копиях.
- IaC, документация и проверенные бэкапы работают вместе. Чем лучше продуманы действия для разных сценариев, тем проще вернуть сервисы в работу.Главный вывод: к disaster recovery нужно готовиться заранее.
👉 Подробный разбор: https://habr.com/ru/companies/kts/articles/1101622/
👉 DevOps Portal
PigeonEye — быстрый нативный GUI для Kubernetes, который загружает даже крупные кластеры через Table API и поддерживает поиск по нескольким кластерам, просмотр логов, безопасное редактирование ресурсов, инструменты отладки и автоматическую поддержку CRD.
➤ https://github.com/tackish/pigeoneye
👉 DevOps Portal
Интересная задача по маршрутизации, которая показывает, насколько непросто бывает правильно настроить сетевую изоляцию
Дано: рабочая станция в офисной сети и сервер с двумя сетевыми интерфейсами в дата-центре.
Ваша задача - обойти ограничения маршрутизатора между ними и получить доступ к внутреннему интерфейсу сервера.
Справитесь? https://labs.iximiuz.com/challenges/networking-restore-emergency-ssh-access
👉 DevOps Portal
Харденинг!
Если вы не знаете это слово, листайте дальше. А если оно вам знакомо — обратите внимание, с 9 ноября стартует последний в этом году поток практикума «Харденинг ИТ: от дизайна до настроек» от Positive Education
Вы наверняка слышали, что 96% организаций уязвимы для проникновения во внутреннюю сеть, а 70% успешных атак можно было предотвратить харденингом. На практикуме расскажут именно об этом. За четыре недели участники выстроят системный подход к укреплению инфраструктуры — с нуля, по методологии, с практикой на стенде
🎯 Что внутри:
• Сетевая архитектура: зонирование, сегментация, DMZ, защита Management, Control и Data Plane
• Харденинг Windows и Linux: политики, учётки, аудит, отключение лишних служб
• Безопасные конфигурации сервисов: SSL/TLS, web, базы данных, контейнеры и виртуализация
• Практика на облачном стенде — настройки проверяются до внедрения в продуктив
• Соответствие ФСТЭК и РКБ, готовые шаблоны и чек-листы в комплекте
Практикум ведут эксперты Positive Technologies — Константин Смирнов, Павел Маслов, Константин Ким, Олег Кочетов и Антон Еремин — специалисты по архитектуре, сетевой безопасности, харденингу и DevSecOps, которые каждый день строят и защищают инфраструктуры крупных компаний
📅 Старт: 9 ноября 2026
⏳ Длительность: 4 недели
💻 Формат: онлайн
📩 Стоимость: по запросу
📄 Кстати, Positive Education получил государственную лицензию на образовательную деятельность. Это значит, что все выпускники программ получат документы установленного образца, а при самостоятельной оплате можно оформить налоговый вычет.
👉 Программа и регистрация
Docker 101: Фоновые контейнеры, логи и потоки STDIO
Продолжаем серию "Знакомство с Docker". В продакшене чаще всего приходится иметь дело с фоновыми контейнерами.
Практикуемся в получении их логов и повторном подключении к потокам STDIO: https://labs.iximiuz.com/challenges/docker-101-container-run-in-background
👉 DevOps Portal
На Stepik запустили годный курс по «Troubleshooting Docker и Kubernetes: поиск и устранение проблем»
В программе только важные аспекты:
— troubleshooting Docker и образов
— диагностика сетевых проблем
— настройка readiness/liveness probes
— отладка pod’ов, деплоев и ingress
— анализ логов контейнеров и кластера
— разбор ошибок CrashLoopBackOff, OOMKilled, ImagePullBackOff и других
Собеседования на DevOps/SRE сейчас всё чаще строятся вокруг реальных инцидентов. Данный курс фокусируется именно на таких сценариях и помогает в подготовке к практическим вопросам
48 часов доступен со скидкой 25%
↗️ Пройти курс на Stepik
Fluentd vs Fluent Bit: что выбрать для Kubernetes?
Краткое сравнение 👇
Fluentd:
- Полноценный инструмент для обработки логов.
- Написан на Ruby (с расширениями на C).
- Справляется с высокими нагрузками и сложной маршрутизацией логов.
- Лучше всего подходит для централизованного сбора и обработки логов.
- Потребляет больше ресурсов (CPU и памяти).
Используйте Fluentd, если вам нужны продвинутые возможности фильтрации, парсинга и маршрутизации логов в больших масштабах.
Fluent Bit:
- Легковесный инструмент для пересылки логов.
- Написан на C (высокая производительность и минимальное потребление ресурсов).
- Отлично подходит для периферийных узлов, DaemonSet в Kubernetes и встраиваемых систем.
- Обычно используется для сбора и отправки логов во Fluentd, Elasticsearch или другие бэкенды.
- Оптимизирован для высокой производительности и низкого потребления ресурсов.
Используйте Fluent Bit, если вам нужен максимально легковесный сборщик логов, который не создаёт дополнительной нагрузки на узлы.
Примечание: оба инструмента имеют статус Graduated-проектов CNCF и широко используются в продакшене.
Хотите разобраться, как устроено логирование в Kubernetes?
Читайте здесь: https://devopscube.com/kubernetes-logging-tutorial/
👉 DevOps Portal
В этом кейсе рассказывается, как платёжная компания перестроила процесс деплоя на Kubernetes, внедрив GitOps с Argo CD. Теперь каждое изменение в продакшене оформляется в виде Git-коммита, который проходит код-ревью, а подготовка к аудитам PCI перестаёт быть гаданием.
➤ https://dodopayments.com/engineering/deployment-pipeline-gitops-argocd-kubernetes
👉 DevOps Portal
Подготовлены две новые практические задачи для освоения сетевого взаимодействия контейнеров:
Лёгкая: перенаправить запросы контейнера без изменения кода приложения — https://labs.iximiuz.com/challenges/docker-networking-redirect-app-to-request-sink
Сложная: перехватить и проанализировать зашифрованный трафик подозрительного контейнера — https://labs.iximiuz.com/challenges/docker-networking-intercept-encrypted-traffic
Удачного хакинга!
👉 DevOps Portal
На Stepik вышла программа «DevOps с нуля: от Linux до Kubernetes»
Это комплексная программа из 5 практических курсов по ключевым технологиям DevOps: Linux, Git, Docker, GitLab CI/CD, Kubernetes
Вы последовательно пройдёте путь от работы в Linux и управления кодом через Git до контейнеризации приложений, настройки CI/CD-пайплайнов и развёртывания в Kubernetes.
Что вы изучите:
• работу с Linux и командной строкой
• Git и контроль версий в реальных проектах
• создание Docker-образов и запуск контейнеров
• автоматизацию сборки, тестирования и деплоя в GitLab CI/CD
• развёртывание и управление приложениями в Kubernetes
• сети, хранилища, конфигурации и секреты
• диагностику инфраструктуры и автоматизацию рутинных задач
... и многое другое
DEVPS20 стоимость всей программы составит 10 392 ₽.
Kube API не отвечает, LoadBalancer не пропускает трафик, DNS не резолвит, исходящие запросы не уходят. Причина обычно кроется на стыке облачной сети и кластера, и найти её без понимания всей цепочки сложно.
3 ноября в 12:00 Роман Ерема, разработчик в команде Managed Kubernetes MWS Cloud Platform, на практике покажет:
⏺️как взаимодействуют сеть облака, CNI и сеть Kubernetes
⏺️как работают SNAT и Source IP
⏺️когда нужен externalTrafficPolicy: Local и почему при нём может не проходить health check
⏺️как диагностировать проблемы на реальных кейсах (live-demo)
Все участники получат чек-лист для проверки доступности.
Полезно инженерам, разработчикам и специалистам по сетям и облачной инфраструктуре.
🗓 3 ноября в 12:00
Регистрируйтесь по ссылке
Yahont - полноценная опенсорс-платформа для корпоративного поиска и ИИ-агентов, ориентированная на быстрое развертывание внутри периметра компании
Знания команды разбросаны по различным источникам и приложениям, а отдавать их на обработку внешнему ИИ-сервису не всегда можно. Yahont ищет по всем вашим источникам и отвечает со ссылками на документы. Работает у вас на сервере в Docker Compose.
Что умеет👇
- Подключается к Confluence, Jira, GitHub, GitLab, Google Drive, Gmail, Яндекс Почта/Диск, Mail ru, S3-совместимым хранилищам, сайтам и другим источникам.
- Гибридный индекс (OpenSearch): ищет и по смыслу, и по точному слову, адаптирован под русский язык.
- Любые модели: RouterAI, Polza AI, OpenRouter, OpenAI, Anthropic или свои через Ollama, vLLM, LM Studio.
- Агенты, глубокое исследование, веб-поиск, запуск кода в песочнице.
- MCP и OpenAPI: подключайте MCP-серверы или сам Yahont как источник знаний для Claude Desktop.
и много другое.
Начать: github.com/pipedude/yahont-ce
Документация: docs.yahont.ai
DevOps-инструмент недели: kube-green
Окружения для разработки и тестирования часто работают 24/7, даже когда ими никто не пользуется.
В результате простаивающие поды продолжают работать по ночам и выходным, а инфраструктура продолжает потреблять деньги.
Можно написать скрипты, которые будут ежедневно масштабировать рабочие нагрузки до нуля, а затем восстанавливать их. Но управлять этим в нескольких неймспейсах может быть непросто.
Здесь на помощь приходит kube-green.
kube-green — опенсорсный Kubernetes-оператор, который автоматически переводит рабочие нагрузки в спящий режим, когда они не нужны, и восстанавливает их к началу работы.
Что умеет kube-green 👇
- Масштабирует Deployments и StatefulSets до нуля на время простоя.
- Приостанавливает CronJobs на ночь.
- Восстанавливает рабочие нагрузки по заданному расписанию.
- Поддерживает настройку по дням недели и часовым поясам.
- Позволяет исключать отдельные ресурсы по именам или меткам.
- Поддерживает кастомные ресурсы через патчи.
С чего начать: GitHub
Примечание: масштабирование подов до нуля позволяет экономить только в том случае, если неиспользуемые ноды также масштабируются вниз. Чтобы действительно сократить расходы на инфраструктуру, используйте kube-green вместе с Cluster Autoscaler или Karpenter.
👉 DevOps Portal
Базовая настройка Kubernetes: доводим кластер до работоспособного состояния
Pov: вы развернули кубер и, кажется, все отлично — можно выкатывать сервисы. Но как бы не так! Перед этим вас ждет еще целая полоса препятствий:
▪️настройки сети и балансировка входящего трафика;
▪️подключение хранилища;
▪️и много чего еще.
29 октября в 11:00 команда «Штурвала» расскажет и покажет все этапы настройки «ванильного» Kubernetes, ответит на ваши вопросы и разберет проблемные моменты.
Присоединяйтесь — за час узнаете, как пользоваться кластером, а не просто любоваться на пять запущенных бинарей.
Регистрация 📌
Kubernetes: Client-Side Apply vs Server-Side Apply
При выполнении команды kubectl apply по умолчанию используется Client-Side Apply (CSA).
При использовании Client-Side Apply утилита kubectl анализирует манифест, ранее применённую конфигурацию и текущее состояние объекта в кластере.
На основе этих данных kubectl определяет, что изменилось, и отправляет необходимый патч на API-сервер Kubernetes.
Server-Side Apply (SSA) работает иначе.
При выполнении команды kubectl apply --server-side операцию применения конфигурации выполняет сам API-сервер Kubernetes.
Главное отличие — владение полями.
В руководстве ниже подробно объясняется эта разница.
Подробное руководство: https://skills.devopscube.com/kubernetes-client-side-vs-server-side-apply/
👉 DevOps Portal