Если администрировать Linux-сервера достаточно долго, рано или поздно сталкиваешься с сетевой фильтрацией. Где-то нужно закрыть лишние порты, где-то ограничить доступ между сегментами сети, а где-то настроить NAT.

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

В этой статье разберёмся, как появился nftables, чем он отличается от привычного iptables, как устроена его архитектура и как на практике использовать его для настройки firewall на Linux-сервере.

HAProxy часто появляется в инфраструктуре незаметно. Сначала это просто балансировщик: принял трафик, отправил дальше — всё понятно. Потом появляется второй сервис, третий, routing по домену, path, заголовкам, SNI, а заодно canary и временные исключения. И вот конфиг, который когда-то помещался на один экран, превращается в логическую задачу со звёздочкой.

В этот момент почти всегда всплывают ACL. Кто-то использует их осознанно, кто-то — по принципу: нашёл в примере, вроде работает. Рядом с ACL неизбежно стоит mode: tcp или http. Снаружи это выглядит как простая настройка, но на деле — фундаментальное решение, от которого зависит, какие данные HAProxy вообще видит и какие условия способен проверить.

Проблема в том, что HAProxy не делает догадок. Он последователен и выполняет конфигурацию ровно так, как она написана. Отсюда и классика жанра: ACL есть, но backend не выбирается; mode вроде http, но заголовки недоступны; routing работает почти всегда, кроме пятницы.

В какой-то момент почти в каждом Kubernetes-кластере наступает день, когда kubeconfig с правами cluster-admin перестаёт быть временным решением и внезапно становится: так исторически сложилось. Пользователей становится больше, доступы плодятся, а вопрос: кто и зачем может удалить namespace в проде? повисает в воздухе без логичного ответа.

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

Kubernetes из коробки умеет работать с OIDC (OpenID Connect), и это, пожалуй, самый адекватный способ интегрировать его с внешним Identity Provider. В роли такого провайдера часто выступает Keycloak: open-source, self-hosted, с поддержкой групп, ролей и интеграцией с LDAP/AD. В общем, всё, что обычно уже есть в инфраструктуре, либо планируется к появлению.

Когда проект Kubernetes только начинал свой путь, вопрос как пустить трафик в кластер решался просто: как-нибудь. Сервисы торчали наружу через NodePort, потом появился LoadBalancer, а чуть позже — объект Ingress, который на долгие годы стал стандартной точкой входа в HTTP-мир Kubernetes.

Ingress был своевременным решением. Он дал декларативный способ описывать маршрутизацию, TLS и виртуальные хосты, не заставляя инженеров напрямую настраивать nginx-конфиги или HAProxy руками. Для своего времени — шаг вперёд, и весьма заметный. Проблема в том, что Kubernetes рос быстрее, чем сам Ingress.

Со временем выяснилось, что спецификация Ingress намеренно минималистична. В ней нет ни чёткого разделения ответственности, ни расширяемой модели, ни нормального способа описывать сложные сценарии маршрутизации. Всё, что выходило за рамки базового use case, уезжало в аннотации ingress-контроллеров. В результате у нас появился единый стандарт, который на практике вёл себя по-разному в зависимости от того, какой контроллер стоял в кластере. Формально — Ingress, фактически — vendor-specific конфигурация с YAML-обвязкой.

eBPF давно перестал быть узкоспециализированной игрушкой для kernel-энтузиастов и исследователей внутренностей Linux. Сегодня с ним, так или иначе, сталкиваются не только SRE, но вообще все, кто разрабатывает системы, близкие к сети, производительности или безопасности: от авторов сетевых плагинов (CNI) и прокси, до разработчиков кастомных агентских решений, observability-инструментов и low-level инфраструктурных компонентов. Даже если вы никогда не писали eBPF-код руками, есть хороший шанс, что он уже работает в вашей системе — тихо, незаметно и с довольно широкими полномочиями.

Чаще всего eBPF проявляется через удобные CLI, библиотеки и дашборды: установили агент, включили, и внезапно система знает о происходящем больше, чем strace, tcpdump и половина метрик вместе взятых. Но за этим комфортом скрывается нетривиальный механизм исполнения пользовательского кода прямо внутри ядра Linux — с жёсткими правилами валидации, ограниченной моделью исполнения и целым набором архитектурных компромиссов, о которых обычно не принято говорить в маркетинговых описаниях.

Если верить вакансиям, DevOps — это человек-оркестр: он пишет пайплайны, чинит Kubernetes, настраивает облака, знает Linux на уровне ядра, умеет в безопасность, автоматизацию, мониторинг и, на всякий случай, может заменить бэкендера, когда тот ушёл в отпуск. Желательно за зарплату джуна и с готовностью выходить на алерты в три часа ночи. Реальность, к счастью, чуть менее драматична. Но и чуть более сложна, чем рассказывают на вводных курсах (привет тем, кто решился вкатится по быстрому). В этой статье разберёмся, кто такой DevOps на самом деле, почему от него действительно ждут «всего и сразу» и где заканчивается адекватное ожидание, и начинается фантазия работодателя.

Сетевую часть Linux обычно «настраивают», но редко понимают. Добавляют iptables-правило, включают NAT, правят sysctl — и если трафик пошёл, считается, что задача решена. Проблемы начинаются ровно в тот момент, когда он не идёт, а поведение системы перестаёт быть очевидным. В Linux нет магии. Есть IP-пакет, его заголовки и строго определённый путь внутри ядра: маршрутизация, netfilter, conntrack, NAT, TCP/UDP стек. Если не понимать этот путь целиком, firewall выглядит как чёрный ящик: NAT — как случайный набор правил, а Kubernetes CNI — как нечто «особенное», существующее отдельно от обычной сети.

Nginx часто воспринимают как «просто веб-сервер», который достаточно поставить и запустить с дефолтным конфигом. На этом этапе обычно и останавливаются: процессы работают как попало, заголовки отдаются по умолчанию, SSL настроен формально, keepalive либо не используется, либо вредит, а маршрутизация запросов со временем обрастает хаотичными location. В результате конфигурация вроде бы выполняет свою задачу, но остаётся плохо управляемой, неочевидной и далёкой от оптимальной.

Эта статья — о базовых, но часто недооценённых возможностях Nginx. Мы последовательно разберём настройку рабочих процессов, управление HTTP-заголовками, корректную конфигурацию SSL, работу keepalive-соединений и маршрутизацию запросов. Без магии и редких трюков — только то, что действительно используется в продакшене и позволяет сделать конфигурацию понятной, предсказуемой и безопасной даже для начинающего администратора.

Когда я писал статью про HAProxy, у меня возникла идея сравнить его с другим популярным proxy-сервером, например с Envoy. Но тогда мне показалось, что простое сравнение в виде таблицы или пары абзацев будет неинформативным — и я решил сделать полноценный разбор в отдельной статье. Если вам интересно — добро пожаловать! Здесь рассмотрены не все возможности каждого решения, но ключевые — те, которые действительно важны на практике.

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

HAProxy 3.3, NGINX 1.29 и Envoy 1.35 — три open source-прокси с разной архитектурой и моделью управления. Enterprise-версии рассматривать не буду — капитализм делает свое дело: серьёзных отличий почти нет, а вот в OSS-вариантах есть что сравнить — в ряде моментов конкуренция пошла на пользу.

Привет, Habr. Сегодня снова поговорим о прокси — это, пожалуй, моя любимая тема, и я рад вернуться к ней. На этот раз речь пойдёт об универсальном солдате в мире балансировки — HAProxy. Этот инструмент уже много лет остаётся стандартом в высоконагруженных системах, но за последние релизы он стал ещё мощнее и гибче.

Напомню, HAProxy (High Availability Proxy) — это высокопроизводительный, отказоустойчивый прокси-сервер и балансировщик нагрузки, способный работать как с HTTP(S), так и с TCP-трафиком. Это делает его идеальным решением не только для веб-приложений, но и для баз данных, почтовых систем, брокеров сообщений и других сервисов.

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

Итак, чем же хорош HAProxy как балансировщик и что интересного появилось в новых версиях?

Привет, Хабр. Продолжаем изучение Istio и сегодня рассмотрим некоторые интересные особенности, которые в дальнейшем могут облегчить сопровождение и развитие сервисной mesh-инфраструктуры в Kubernetes. С ростом распределённых систем и микросервисных архитектур в Kubernetes всё чаще встаёт вопрос о построении надёжной, масштабируемой и безопасной сетевой инфраструктуры. Когда одного кластера становится недостаточно, возникает потребность объединить несколько инсталляций в единую mesh-сеть. Здесь и появляется Istio, как кандидат на реализацию мультикластерной архитектуры.

Современные распределённые системы требуют надёжных, безопасных и масштабируемых способов управления сетевым взаимодействием между сервисами. Технологии Service Mesh, такие как Istio, предоставляют набор инструментов для решения этих задач. Недавно в экосистеме Istio появилась новая архитектура — Ambient Mesh, предлагающая альтернативный подход к реализации сетевых функций. В данной статье мы рассмотрим, чем отличаются классический Service Mesh и Ambient Mesh в контексте Istio, а также их преимущества и недостатки.

DevOps — это стремительно развивающаяся область, объединяющая разработчиков и специалистов по эксплуатации для автоматизации, ускорения и улучшения процессов доставки программного обеспечения. DevOps-инженеры играют ключевую роль в современном ИТ-ландшафте, помогая компаниям быстро адаптироваться к меняющимся условиям и требованиям рынка. Их задачи охватывают широкий спектр областей: автоматизация инфраструктуры, управление жизненным циклом приложений, настройка мониторинга и обеспечение надёжности систем.

Основная концепция DevOps заключается в устранении барьеров между командами разработки (Dev) и эксплуатации (Ops), что позволяет внедрять изменения быстрее и с меньшими рисками. Это достигается за счёт использования инструментов и подходов, таких как CI/CD (непрерывная интеграция и доставка), Infrastructure as Code (IaC, инфраструктура как код), контейнеризация и мониторинг. Однако DevOps — это не только технологии, но и культура взаимодействия, прозрачности и ответственности в командах.

Привет, Хабр! Давайте продолжим изучать возможности Envoy, но уже в контексте динамической конфигурации. В первой статье мы рассматривали настройку статической конфигурации, однако она имеет свои особенности. Статическая конфигурация подходит, когда ваши upstream (серверы, к которым Envoy отправляет запросы) редко изменяются. Envoy работает как прокси, и каждый запрос проходит через него. Чтобы правильно обработать запрос, Envoy должен иметь актуальную информацию о бэкенд-серверах, такую как их IP-адреса и порты. Когда информация о бэкенде меняется, необходимо обновить конфигурацию в статическом файле и перезапустить Envoy, что не всегда удобно.

Привет, Хабр, это моя первая статья. Меня зовут Константин, я системный инженер в компании ГНИВЦ. Здесь я хотел бы вам рассказать, что такое Envoy и как с его помощью можно упростить жизнь разработчикам и повысить надёжность взаимодействия микросервисов, минуя инфраструктуру для кого-то страшного и непонятного Kubernetes, а используя простой и старомодный Docker. Также эта статья поможет познакомиться с Envoy поближе и узнать, как он шагает в ногу с таким проектом как Istio.