DevOps Portal | Linux

Как установить и настроить kubectl на Linux kubectl - это CLI-инструмент для взаимодействия с кластерами Kubernetes. Независимо от того, управляете ли вы контейнерами, деплоите приложения или устраняете проблемы в кластере, kubectl является вашим основным интерфейсом для работы с API-сервером K8s. Читать тут 👉 DevOps Portal

Встречайте новый формат инженерного диалога T-Sync Conf — офлайн-конференция от Группы «Т-Технологии» для опытных инженеров. 7 февраля в Москве на площадке TAU соберутся платформенные, security- и дата-инженеры, аналитики, DevOps-, SRE-, CI/CD-, AI-, ML-, R&D- и DX -специалисты. Как все устроено: — Контуры — тематические зоны, каждая из которых раскрывает отдельный слой инженерной реальности: AI, Data, R&D, Security, Platform и другие направления. — Вместо классических докладов — круглые столы, стенды, хакатон, воркшопы и мастер-классы. — Инженерные решения изнутри — возможность посмотреть, как устроены технологии в Т-Банке и других компаниях, и пообщаться напрямую с теми, кто их создает. А еще много практики, интересных знакомств и живых систем. Успейте подать заявку

Мини-курс по containerd обновлён и переведён на недавно вышедшую версию containerd 2.2.1. Если нужно глубже разобраться, как контейнеры управляются низкоуровневыми рантаймами (тем самым слоем под Docker или Kubernetes), это хорошая отправная точка https://labs.iximiuz.com/courses/containerd-cli 👉 DevOps Portal

Apache Kafka — отличный инструмент, пока не приходится запускать брокер с нуля. Настройки ZooKeeper, обновления, мониторинг, алерты, репликация. Всё это быстро превращается в отдельный инфраструктурный продукт, который требует времени и внимания команды. В Managed Kafka в облаке MWS Cloud Platform ⬜ мы взяли на себя:

⏺развёртывание и базовую конфигурацию кластера ⏺обновления, бэкапы и мониторинг ⏺управление доступом через облачный IAM Сфокусируйтесь на работе с данными, а рутину возьмёт на себя Managed Kafka

Сервис работает с актуальной версией Kafka на KRaft. А ещё у нас есть Private Link для полной сетевой безопасности. 💲Попробуйте с грантом до 10 000 рублей. ➡Попробовать

Простой способ создавать свои DevOps-лабы Примерно год iximiuz Labs поддерживает создание кастомных плейграундов: вы выбираете стандартную базу (Ubuntu-VM, Docker-хост, Kubernetes-кластер и т.д.) и донастраиваете её под свои задачи с помощью скриптов, похожих на cloud-init. Подход хорошо себя зарекомендовал, таким образом было создано около 700 плейграундов. Но при всей "чистоте" скриптового провижининга у него есть и заметные минусы:

- Init-скрипты запускаются при каждом старте плейграундов, увеличивая time-to-prompt, иногда весьма существенно - Некоторые задачи провижининга гораздо проще решать запуском shell-команд вручную (попутно чиня упавшие шаги) - Некоторые "случайные" состояния VM имеет смысл сохранить как переиспользуемые кастомные плейграунды (но задним числом заскриптовать их уже нельзя)

К счастью, с появлением "persistent playgrounds" в ноябре стало возможным сохранять остановленный плейграунд как кастомный. При этом результат ничем не отличается от любого другого плейграунда: вы получаете read-only шаблон, который можно перезапускать сколько угодно раз, делиться им с другими или встраивать в туториалы, челленджи и уроки курсов. Магия 🧙 Попробуйте сами: http://labs.iximiuz.com/playgrounds 👉 DevOps Portal

How-To: как собрать eBPF-фаервол, который фильтрует пакеты по диапазонам IP В большинстве туториалов показывают, как заблокировать один конкретный IP-адрес. Но в реальном мире (Kubernetes, автоскейлинг нод, короткоживущие ворклоады, managed-сервисы и т. п.) IP-адреса постоянно меняются, поэтому на практике имеет смысл работать именно с CIDR-диапазонами. В этой статье вы узнаете, как правильно блокировать целые подсети: https://labs.iximiuz.com/tutorials/ebpf-firewall-ed03d648 👉 DevOps Portal

На Stepik вышел курс по Linux Внутри 20+ модулей: от установки Linux и работы с файлами до сетей, прав, дисков, процессов, автоматизации на Bash и многого другого. Всё сразу закрепляется на практике (200+ заданий с автопроверкой) Материал подаётся понятным языком, шаг за шагом, на реальных примерах и с наглядными схемами. После прохождения вы получите сертификат, который можно добавить в резюме. Есть бесплатные демо-уроки для ознакомления. В ближайшие 48ч курс доступен со скидкой 25% по промокоду «HNY_LINUX»: открыть курс на Stepik P.S: Курс можно купить в подарок на Новый год

Большинство людей сразу прыгают в Prometheus и Grafana, не понимая, какую именно задачу они на самом деле решают. Я постоянно вижу это на собеседованиях. Человек говорит: «Мы используем Prometheus для мониторинга», но при этом не может объяснить, почему логи и метрики требуют разных пайплайнов, или что вообще происходит, когда CloudWatch перестаёт справляться на масштабе. В observability вы решаете две принципиально разные проблемы. Логи отвечают на вопрос "что произошло". Произошла ошибка. Пришёл запрос. Упал запрос к базе данных. Это события - истории, которые рассказывает ваше приложение. Метрики отвечают на вопрос "как система чувствует себя прямо сейчас". Латентность 200 мс. CPU 75%. 500 запросов в минуту. Это измерения. Разные типы данных. Разные способы сбора. Разное хранение. И именно здесь большинство людей путается. В прошлом месяце на моём DevOps-буткемпе мы собрали полноценную систему observability для микросервисов в Kubernetes. Логи Для логов мы использовали Fluentd sidecar-контейнеры, которые шарят volume с основным контейнером приложения: - приложение пишет логи в volume; - Fluentd читает их и отправляет дальше; - чёткое разделение ответственности; - на небольшом масштабе логи просто улетают напрямую в CloudWatch. Но когда у вас тысячи строк логов в секунду, приходится добавлять слои: - Lambda для форматирования. - Kinesis для буферизации. - OpenSearch для быстрых запросов по петабайтам данных. - S3 для долгосрочного бэкапа. Мы держали 7 дней в OpenSearch для активных расследований. 30 дней — в CloudWatch. Годы — в S3 для комплаенса. У каждого слоя разные характеристики по цене и производительности. Метрики Для метрик Prometheus скрейпит application endpoints каждые 30 секунд: - разработчики инструментируют код клиентскими библиотеками Prometheus; - экспонируют /metrics endpoint; - Prometheus сам подтягивает данные. Мы создали ServiceMonitor’ы, которые говорят Prometheus, какие pod’ы скрейпить на основе label’ов: - Как только поднимаются новые pod’ы, Prometheus их обнаруживает и начинает скрейпить. - Дальше Grafana визуализирует всё это. - Мы импортировали готовые дашборды с grafana.com для мониторинга Kubernetes. - И также собрали кастомные панели под метрики конкретного приложения. Логи и метрики идут параллельно. Когда что-то ломается, метрики показывают вам всплеск: error rate подпрыгнул в PM. Латентность выросла со 100 мс до 2 секунд. Дальше вы идёте в логи: фильтруете по тому же окну времени, находите stack trace’ы и видите, что именно упало. Нельзя нормально дебажить, имея только один тип данных. Нужны обе перспективы. Мы всё это реализовали и оттраблшутали в лайв-созвоне: нагенерили метрики и логи и собрали дашборды в Grafana Прочитать подробный пост можно здесь: https://open.substack.com/pub/akhileshmishra/p/youre-not-ready-for-kubernetes-observability 👉 DevOps Portal

Kubernetes совет Удалить все поды в неймспейсе При работе с тестовым кластером или в процессе обучения могут возникнуть ситуации, когда нужно удалить все поды в конкретном неймспейсе. Сделать это можно с помощью флага --all 👉 DevOps Portal

Увлекательный мир устранения неполадок в Kubernetes⚡️Сняли видеоурок, в котором:• разберем распространенные сетевые проблемы и научим вас применять strace для решения сложных ситуаций• узнаем, как использовать kubectl для диагностики и управления вашими приложениями• посмотрим сайдкар контейнеры и узнаем, зачем их использовать🌚Будет полезно, даже если ваши сервисы крутятся на bare metal или VM без оркестрации.➡️Забрать урок и сохранить себе, чтобы чинить инциденты без паники