CORTEL

⚠️ DDoS 2026

И снова в центре внимания новости про DDoS-инциденты.

Если раньше атака часто сводилась к объёму мусорного трафика, то сейчас всё чаще используются многоуровневые сценарии: комбинации разных векторов, имитация поведения реальных пользователей, атаки на API, точечная перегрузка отдельных сервисов.

Поэтому DDoS всё сложнее распознать сразу.
Проблема становится заметной уже на этапе деградации сервиса: замедляется работа сайта, растёт нагрузка на приложения, пользователи сталкиваются с отказами.

➡️ Этапы атаки

сначала — анализ инфраструктуры и разведка,
затем — многоуровневая атака: на приложения (L7), API и одновременно на сетевой уровень (L3/L4).

В результате страдает не только доступность ресурса, но и устойчивость всей ИТ-среды.
Для бизнеса это означает простой, потерю обращений, рост нагрузки на команды эксплуатации и ИБ.

➡️ Какая защита нужна

Для защиты требуется выстроенная схема фильтрации трафика, которая включает несколько уровней:

— очистку трафика до его попадания в инфраструктуру;
— сокрытие реального IP-адреса ресурса;
— анализ штатного поведения сервиса;
— автоматическое выявление аномалий;
— пропуск к ресурсу только легитимного трафика.

Такой подход позволяет снижать нагрузку на инфраструктуру и поддерживать доступность сервисов даже при сложных сценариях атак.

При выборе защиты важно, чтобы решение работало не только против объёмных атак, но и против более сложных сценариев: на уровне приложений, API и пользовательских сессий.

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

Как выстраивается такая защита и какие варианты подходят для разных типов инфраструктуры, можно посмотреть здесь.

#проИБ

💬 6 принципов отказоустойчивой системы

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

✅ Replication
— создание нескольких копий данных или сервисов.

Если один экземпляр выходит из строя, второй продолжает работу. Это помогает сохранить доступность и снизить риск потери данных.

✅ Redundancy
— резервирование критичных компонентов.

У важных узлов должен быть запасной вариант. Иначе один отказ может стать причиной остановки всей системы.

✅ Load Balancing
— распределение нагрузки между несколькими серверами.

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

✅ Failover
— автоматическое переключение на резервный компонент при сбое основного.

При сбое основного узла резервный вступает в дело без ручного вмешательства.

✅ Graceful Degradation
— сохранение основной функции системы при частичном отказе.

Если часть компонентов недоступна, сервис не отключается полностью, а временно ограничивает второстепенные возможности.

✅ Monitoring and Alerting
— постоянный контроль за состоянием системы и уведомления о проблемах.

Помогает быстро замечать сбои, перегрузки и деградацию, чтобы реагировать до серьёзного инцидента.

#полезное

💸 Почему ИТ- департамент не получает бюджет?

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

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

📰 В новом материале разобрали, как связать SLA, RTO, RPO и TCO в одну систему аргументов для бизнеса, почему считать нужно не только инфраструктуру, но и стоимость риска, и какие метрики помогают ДИТу говорить с руководством на одном языке и обосновывать вложения.

#статья

🖥 Rsync — утилита для быстрого инкрементального копирования и синхронизации данных.

🟢 Главный плюс: передаются только изменившиеся части файлов, а не целиком. Это экономит трафик и время.

💬 Как работает

— Разбивает файлы на блоки фиксированного размера.
— Вычисляет контрольные суммы (rolling checksum + хэш).
— Сравнивает блоки источника и назначения.
— Передаёт только отличающиеся блоки.
— Работает локально, через SSH или собственный rsync-демон.

💬 Базовый синтаксис

rsync [параметры] источник назначение

💬 Основные параметры

— -a — архивный режим: сохраняет права, симлинки, таймстампы, рекурсивность. Почти всегда нужен.
— -v — подробный вывод (verbose): показывает, какие файлы копируются.
— -z — сжатие при передаче (полезно по медленным каналам).
— -h — человеко-читаемые размеры (K, M, G).
— -P — комбинация --partial (докачка) и --progress (прогресс-бар).
— --delete — удаляет файлы в назначении, которых нет в источнике. Делает синхронизацию зеркалом.
— -n / --dry-run — тестовый прогон: показывает, что будет сделано, без реальных изменений.
— --exclude — исключает файлы/папки по шаблону (можно несколько).
— -e — указывает удалённую оболочку, например -e ssh.

💬 Примеры

Локальное копирование папки

rsync -avh /home/user/data/ /backup/data/

Отправка на удалённый сервер (push)

rsync -avz -e ssh /local/folder/ user@server:/remote/folder/

Загрузка с сервера (pull)

rsync -avz -e ssh user@server:/remote/folder/ /local/folder/

Тестовый прогон зеркалирование с удалением лишнего

rsync -avn --delete /source/ /dest/

Rsync — незаменимый инструмент в арсенале любого администратора. Быстрый, надёжный, работает везде, где есть Linux (и не только).

#линуксятина

⬇️ Замена kube-proxy с помощью CNI Cilium (kube-proxy replacement)

kube-proxy — компонент Kubernetes, который на каждой ноде реализует сервисы (Service), балансировку нагрузки и перенаправление трафика на поды через режимы iptables, ipvs или userspace.

Cilium — мощный CNI-плагин на базе eBPF и его Network Policies для L3/L4/L7-фильтрации.

🧑‍💻 Соединим их вместе

Cilium способен полностью заменить kube-proxy, взяв на себя всю обработку Kubernetes-сервисов (ClusterIP, NodePort, LoadBalancer, externalIPs, hostPort) напрямую в ядре Linux.

🤓 Как это работает под капотом

Cilium использует eBPF-программы, которые загружаются в ядро и обрабатывают пакеты на ранних этапах сетевого стека.

— Вместо генерации тысяч правил в iptables (линейный просмотр) или даже IPVS Cilium хранит маппинги сервисов и эндпоинтов в BPF hash-таблицах;
— При создании/изменении Service Cilium-агент обновляет BPF-мапы. Трафик к ClusterIP мгновенно транслируется в IP пода с балансировкой.
— Direct Server Return (DSR) для снижения latency (ответы идут напрямую от пода к клиенту, минуя лишние хопы)

🙂 Преимущества замены

✔️ Производительность — ниже latency, выше пропускная способность, значительно меньше потребление CPU (в крупных кластерах экономия 25–40 % на сетевой обработке). Не деградирует при росте количества сервисов.
✔️ Масштабируемость — тысячи сервисов без проблем с длинными цепочками правил.
✔️ Упрощение стека — можно полностью удалить kube-proxy (или не устанавливать его при развертывании кластера). Меньше компонентов — проще отладка и меньше точек отказа.
✔️ Интеграция с возможностями Cilium — политики безопасности, Hubble-мониторинг и L7-фильтрация работают в едином eBPF-пространстве.

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

Как включить kube-proxy replacement

При установке Cilium через Helm:

kubeProxyReplacement: true
k8sServiceHost: <IP API-сервера>
k8sServicePort: <порт API-сервера>
# Дополнительно для полного функционала:
nodePort:
  enabled: true
externalIPs:
  enabled: true
hostPort:
  enabled: true
bpf:
  masquerade: true

Замена kube-proxy на eBPF-реализацию в Cilium — это логичный шаг для тех, кто уже использует Cilium как CNI. Кластер становится быстрее, проще и современнее: меньше оверхеда, лучше наблюдаемость и единый механизм для сети и безопасности.

#заметкиИнженера

💿 С Днем резервного копирования, друзья!

🔥 ТОП полезных статей

— Как настроить резервное копирование и работать без перебоев

— Иллюзия безопасности: почему бэкапы не спасают бизнес

— Сколько стоит час простоя: строим стратегию восстановления данных

— Как избежать потерь: стратегии Disaster Recovery для бизнеса

— Репликация данных в различных СУБД

— Бэкап (backup): как сделать резервное копирование надёжным

— Опыт организации резервного ЦОД для непрерывной работы критичных сервисов

#полезное

📝 Шпаргалка по балансировке трафика между серверами.

Помогает разделять трафик, масштабировать приложения, улучшать производительность и доступность

🔫 Алгоритмы балансировки

— Round Robin
Запросы отправляются по очереди на разные серверы. Подходит, если узлы одинаковые по мощности, а нагрузка примерно равномерная.

— Weighted Round Robin
Похож на Round Robin, но с учётом веса сервера. Более мощные узлы получают больше запросов, слабые — меньше.

— Least Connections
Новый запрос идёт на сервер с наименьшим числом активных соединений. Полезно, когда нагрузка неравномерная и запросы живут разное время.

— Least Response Time
Трафик направляется туда, где сервер отвечает быстрее. Помогает распределять нагрузку с учётом текущего состояния системы, а не только количества соединений.

— IP Hash
Запросы от одного и того же клиента направляются на один и тот же сервер. Удобно, если важна привязка к сессии.

🔫 Как понять, что балансировка работает нормально
Важно смотреть, как система ведёт себя под нагрузкой.

Для этого обычно ориентируются на следующие метрики:
➡️задержка;
➡️время ответа;
➡️количество активных соединений;
➡️число запросов на сервер;
➡️ошибки 5xx;
➡️процент недоступных бэкендов.

#полезное

🤑 Сколько денег теряет бизнес за один час простоя ?

Во многих компаниях настроены бэкапы, согласованны RTO и RPO и даже есть план аварийного восстановления.

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

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

#статья

Systemd-journald — компонент, который пришёл на смену традиционной syslog. Он собирает сообщения от ядра, служб, пользовательских процессов и хранит их в структурированном бинарном формате с индексацией, в система с systemd

💬 Основные команды journalctl

✅ Просмотр логов

journalctl                     # все логи
journalctl -u nginx            # логи конкретной службы
journalctl -u nginx -u sshd    # нескольких служб

✅ Фильтрация по времени

journalctl --since "2026-03-26 08:00:00"
journalctl --since "1 hour ago"
journalctl --since yesterday --until now

✅ Фильтрация по приоритету

journalctl -p err              # ошибки и выше (0-3)
journalctl -p warning          # предупреждения и выше

✅ Логи загрузки

journalctl -b                  # текущая загрузка
journalctl -b -1               # предыдущая загрузка
journalctl --list-boots        # список всех загрузок

💬 Диагностика и очистка

journalctl --disk-usage          # занимаемое место
sudo journalctl --rotate         # принудительная ротация
sudo journalctl --vacuum-size=1G # оставить 1 ГБ
sudo journalctl --vacuum-time=2d # логи не старше 2 дней

journald даёт быстрый доступ к логам через единый интерфейс с удобной фильтрацией — без необходимости парсить текстовые файлы.

#линуксятина

🐙 Kube-router объединяет функции CNI, kube-proxy и контроллера сетевых политик в одном агенте, работающем на каждой ноде.

Это упрощает сетевую архитектуру кластера и повышает производительность за счёт прямого взаимодействия с ядром Linux через BGP и iptables/ipvs.

➡️ Основной функционал:

— CNI (Container Network Interface) — назначает подам IP-адреса из указанного пула, настраивает маршрутизацию между нодами.
— Замена kube-proxy — обеспечивает реализацию сервисов (ClusterIP, NodePort, LoadBalancer) через iptables или ipvs с возможностью session affinity.
— Сетевые политики — реализует NetworkPolicy (L3/L4) с помощью iptables, не требуя дополнительных контроллеров.
— BGP-маршрутизация — анонсирует IP-адреса подов и сервисов в сеть дата-центра, позволяя внешним маршрутизаторам напрямую направлять трафик на ноды (без наложения overlay).

➡️ Ключевые особенности:

— Единый агент — один процесс вместо трёх (CNI, kube-proxy, network policy controller), снижающий потребление ресурсов и сложность эксплуатации.
— Гибкая конфигурация — выбор режима работы: только CNI, только kube-proxy, только политики или всё вместе.
— Высокая производительность — работает напрямую с iptables/ipvs и BGP без промежуточных прослоек.
— Поддержка IPv6 и dual-stack.

Kube-router особенно полезен в сценариях, где нужна простота (замена нескольких компонентов одним), интеграция с существующей BGP-инфраструктурой или работа в bare-metal окружениях без overlay.

👉 Git
#полезное

💻 Kube-proxy — компонент kubernetes, работающий на каждой ноде кластера.

Он отвечает за реализацию сервисов (Service) и обеспечивает перенаправление трафика на поды.

➡️ Основные задачи

— Обеспечивает работу сервисов типов ClusterIP, NodePort, LoadBalancer
— Преобразует виртуальный IP сервиса в IP-адреса целевых подов
— Выполняет балансировку нагрузки на уровне L4 (TCP/UDP/SCTP)
— Отслеживает изменения сервисов и эндпоинтов через Kubernetes API

➡️ Принцип работы

Kube-proxy следит за API-сервером. При создании, удалении или изменении сервиса он обновляет правила маршрутизации на ноде. Трафик, приходящий на IP сервиса, перенаправляется на один из подов согласно настроенному режиму.

➡️ Режимы работы

🔵 iptables (режим по умолчанию)
— Генерирует цепочки правил в iptables
— Пакеты перенаправляются напрямую на поды без дополнительных переходов
— Балансировка реализована через случайный выбор правила
— Подходит для большинства кластеров среднего размера

🔵 ipvs (рекомендуется для крупных кластеров)
— Использует встроенный балансировщик ядра Linux IPVS
— Выдерживает десятки тысяч сервисов без деградации
— Обеспечивает session affinity (persistence) на уровне ядра

🔵 userspace (устаревший)
— Прокси работает в пространстве пользователя
— Каждое соединение проходит через kube-proxy
— Используется только в legacy-кластерах

🔵 Ключевые особенности
— Работает независимо от container runtime (containerd, CRI-O)
— Запускается на каждой ноде как DaemonSet (или системный сервис)
— Взаимодействует только с сетевым стеком ноды, не влияет на сами поды
— Обновления правил применяются атомарно, без прерывания существующих соединений

Kube-proxy обеспечивает базовую сетевую связность в кластере, превращая динамические IP подов в стабильные точки доступа и равномерно распределяя нагрузку.

#заметкиИнженера

🤔 Как выбрать ИТ-инфраструктуру: сервер, облако или гибридная модель

🔥 ТОП полезных статей

— 99,9% времени без перебоев. Как обеспечить надёжную работу IT-систем и не разориться

— Пять признаков, что вашей ИТ-инфраструктуре пора в облако

— Публичное, частное, гибридное облако — в чем разница и какое подходит бизнесу?

— Частное облако за 10 минут — что такое Private Cloud и как оно работает

— Облако или свой сервер — где лучше спрятать чувствительные данные

— 5 типичных ошибок при переходе на облачную инфраструктуру и как их избежать

— Конец эпохи VMware: как российскому бизнесу избежать штрафов и простоев

— Как VDI решает проблему с нехваткой кадров в инженерных компаниях

#полезное

🌐 18 сетевых портов

Шпаргалка, которая помогает быстро понять, какой сервис работает за тем или иным портом, и куда смотреть, если в сети что-то пошло не так.

⏺️ FTP — 21/TCP
Передача файлов. Сейчас используется реже, потому что без дополнительной защиты считается небезопасным.

⏺️ Удалённый доступ — SSH 22/TCP, Telnet 23/TCP, RDP 3389/TCP
SSH, Telnet и RDP используются для удалённого подключения
SSH — защищённый доступ, Telnet — устаревший протокол без шифрования, RDP — удалённый рабочий стол Windows.

⏺️ Почта — SMPT 25/TCP, POP3 110/TCP, IMAP 143/TCP
SMTP отвечает за отправку писем, POP3 и IMAP — за получение почты. IMAP позволяет работать с письмами на сервере, POP3 — загружать их на устройство.

⏺️ DNS — 53/UDP или TCP
Преобразует доменные имена в IP-адреса.

⏺️ DHCP — 67/UDP и 68/UDP
Автоматически выдаёт устройству IP-адрес и сетевые настройки.

⏺️ Веб-трафик — HTTP 80/TCP и HTTPS 443/TCP
HTTP и HTTPS используются для сайтов и API. HTTPS — тот же веб-трафик, но с шифрованием.

⏺️ NTP — 123/UDP
Синхронизация времени на серверах и рабочих станциях.

⏺️ Базы данных — 1521/TCP, 3306/TCP, 5432/TCP
Стандартные порты Oracle, MySQL и PostgreSQL.

#полезное

⚖️Законы для ИТ и связи

Что уже вступило в силу с 1 марта

👀 Заработала ГИС «Антифрод»
— единая система для обмена данными о признаках мошенничества между госорганами, операторами связи, банками и платформами.

👀 Вступили в силу правила по перечню российского ПО и баз данных для собственных нужд. Теперь внутренняя разработка тоже вынесена в отдельный регуляторный трек, а значит, подтверждать статус такого софта придётся уже по формальным правилам.

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

👀 Вступили в силу правила по перечню доверенного российского ПО.

👀 Доверенному ПО дали приоритет в закупках. Если у программы есть отметка о соответствии требованиям к доверенному софту, её положение в закупочном контуре становится сильнее.

Что обсуждается и что вступит в силу с 1 сентября

👀 С 1 сентября 2026 года вступят в силу новые правила взаимодействия операторов связи с органами власти при размещении сетей на государственных и муниципальных объектах. Для операторов и подрядчиков это означает более формализованный порядок доступа к инфраструктуре, согласований и размещения линий связи.

👀С 1 сентября 2026 года вступят в силу поправки в закон об информации. В том числе закрепляется обязанность операторов ИС взаимодействовать с государственной системой обнаружения, предупреждения и ликвидации последствий компьютерных атак, а значит, интеграции с госконтуром киберзащиты станет больше.

👀 Для ИИ готовят отдельные правила, роли участников и требования к применению таких систем.

#ИТиЗАКОН

🐮🔮🌈 fortune + cowsay + lolcat

Разноцветная корова-предсказательница прямо в терминале

🧑‍💻 Установка:

# Ubuntu/Debian
sudo apt install fortune-mod cowsay lolcat

# Fedora
sudo dnf install fortune-mod cowsay lolcat

# Arch/Manjaro
sudo pacman -S fortune-mod cowsay lolcat

# macOS
brew install fortune cowsay lolcat

🔮 Пример:

user@ubuntu:~ $ fortune | cowsay | lolcat
 _________________________________________
/ Сегодня великий день.                   \
| Особенно если ничего не сломается после |
\ обеда.                                  /
 -----------------------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

user@ubuntu:~ $ fortune | cowsay | lolcat
 _________________________________________
/ Ожидайте перемен.                       \
| Скорее всего, их принесет коллега с     |
\ фразой: «а можно на минутку?»           /
 -----------------------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

user@ubuntu:~ $ fortune | cowsay | lolcat
 _________________________________________
/ Вселенная на твоей стороне.             \
| Но просит сначала дочитать документацию.|
 -----------------------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

P.S. В примере вольный перевод инженера 🤓
Хороших весенних выходных 🥳

#rootoffun

📄 systemd unit: структура файлов и секции

➡️ Ранее рассматривали основные типы юнитов.

🔵А как устроены сами unit-файлы?

Unit-файлы — это простые текстовые файлы в формате, напоминающем ini.

Они хранятся в каталогах:
— /etc/systemd/system/ — для пользовательских/локальных юнитов (приоритет выше остальных)
— /lib/systemd/system/ — юниты, установленные пакетами
— /run/systemd/system/ — динамически созданные юниты (например, при монтировании)

🔵 Общая структура

Каждый unit-файл состоит из секций.
Имя секции заключается в квадратные скобки.
Внутри секции — директивы вида Ключ=Значение. Комментарии начинаются с #.

➡️ Основные секции:
— [Unit] — присутствует во всех юнитах. Содержит описание, зависимости, порядок загрузки.
— [Service] — только для .service юнитов. Определяет, как запускать, контролировать и останавливать процесс.
— [Install] — используется командой systemctl enable. Указывает, в какие таргеты включать юнит.
— Другие специфические секции: [Socket], [Timer], [Mount], [Path] и т.д.

🔵 Остановимся на самой важной — [Unit].

➡️ Основные директивы:

— Description — понятное имя юнита (отображается в systemctl status).
— Documentation — список URI с документацией (можно указать несколько через пробел).
— After, Before — управление порядком запуска. Например, After=network.target означает, что этот юнит должен запускаться после network.target (но не гарантирует, что сеть готова).
— Requires — жёсткая зависимость: если указанный юнит не запустится, этот тоже не запустится (или будет остановлен).
— Wants — мягкая зависимость: если указанный юнит не запустится, это не помешает запуску текущего.
— Conflicts — если указанный юнит запущен, текущий будет остановлен (и наоборот).
— Condition... и Assert... — проверки перед запуском (например, ConditionPathExists=/etc/myapp.conf).

✅ Пример unit-файла

[Unit]
Description=Python Application
Documentation=https://python.appdocs.ru/myapp
After=network.target
Wants=network-online.target
ConditionPathExists=/opt/myapp/app.py

[Service]
Type=simple
User=appuser
ExecStart=/usr/bin/python3 /opt/myapp/app.py
Restart=on-failure

[Install]
WantedBy=multi-user.target

➡️ Где:

— Description — что это за сервис.
— Documentation — где искать информацию.
— After=network.target — старт после базовой сети.
— Wants=network-online.target — желательно дождаться полной готовности сети (но не критично).
— ConditionPathExists — проверяет наличие файла перед запуском.
— Далее идут секции [Service] (параметры запуска) и [Install] (автозагрузка).

Понимание секции [Unit] даёт контроль над тем, когда и при каких условиях запускается ваш сервис. Остальные секции ([Service], [Timer], [Socket] и т.д.) описывают уже конкретную логику работы юнита.

#линуксятина

🔗 kubetail — это bash-скрипт, который объединяет логи нескольких подов в один поток с цветовой индикацией источника. Позволяет одновременно следить за логами группы подов, не открывая десяток вкладок терминала.

⌛️ Основной функционал:

— Выбор подов по имени, части имени, регулярному выражению или меткам (labels).
— Цветовое кодирование для каждого пода (по умолчанию 8 цветов, настраивается).
— Объединение логов в хронологическом порядке (как если бы все логи писались в один файл).
— Поддержка мультиконтейнерных подов: можно указать конкретный контейнер или следить за всеми.
— Работа в режиме tail -f (follow) для непрерывного вывода новых сообщений.
— Возможность исключать отдельные поды из выборки.
— Использует стандартный kubectl logs под капотом — не требует установки дополнительных компонентов в кластер.

⌛️ Ключевые особенности:

— Простота использования: достаточно написать kubetail my-app и получить логи всех подов, имя которых начинается с my-app.
— Гибкость: выбор по лейблам (-l app=my-app,version=v1), регулярным выражениям (-r ^web-), исключение ненужных подов (-E broken-pod).
— Не требует привилегий в кластере — работает с текущим контекстом kubectl.
— Лёгкость интеграции в повседневную работу: можно добавить алиас в .bashrc или .zshrc.
— Цвета помогают визуально разделять потоки разных подов, что упрощает отладку.

kubetail превращает разрозненные логи множества микросервисов в единую ленту событий. Это особенно полезно при отладке распределённых транзакций, когда нужно видеть, что происходит в нескольких компонентах одновременно. Инструмент не перегружен лишними функциями, но закрывает 90% потребностей при работе с логами в Kubernetes.

👉 Git
#полезное

💻 Kubelet — основной компонент, работающий на каждой ноде.

Он не запускается как контейнер, а выполняется напрямую в системе как системный сервис (systemd-юнит). Его задача — превратить узел в полноценную единицу кластера, способную выполнять рабочую нагрузку.

🔵 Как работает?

1. Регистрация узла — При старте kubelet регистрирует узел в API-сервере, передавая информацию о ресурсах (CPU, память), IP-адресах и метках.
2. Получение заданий — Kubelet постоянно наблюдает за API-сервером. Как только появляется Pod, назначенный на его узел (поле spec.nodeName совпадает с именем узла), он приступает к запуску.
3. Запуск контейнеров — Kubelet не запускает контейнеры напрямую. Он обращается к container runtime (containerd, CRI-O) через CRI (Container Runtime Interface). Runtime создаёт и запускает контейнеры, настраивает изоляцию через namespace и cgroups.
4. Мониторинг и пробы — После запуска kubelet регулярно выполняет:
— livenessProbe — проверяет, живо ли приложение (если нет — перезапускает контейнер);
— readinessProbe — определяет, готов ли под принимать трафик;
— startupProbe — для приложений с долгим стартом.
5. Отчётность — Kubelet собирает состояние контейнеров (Running, Terminated, Waiting) и передаёт его в API-сервер.

🔵 Что важно знать?

➡️ Управляет только контейнерами — Kubelet не знает про Deployment, Service или Ingress — он работает исключительно с подами и их контейнерами. Высокоуровневые абстракции обрабатывает kube-controller-manager.

➡️ Автономность при сбоях control plane — Если API-сервер временно недоступен, kubelet продолжает запущенные поды и следит за их состоянием. Новые поды назначить он не сможет, но уже работающие не остановятся.

➡️ Статичные поды — Kubelet умеет запускать поды из манифестов в каталоге /etc/kubernetes/manifests. Так работают статичные поды (например, компоненты control plane в kubeadm).

➡️ Связь с API-сервером через механизм watch — Вместо постоянного опроса kubelet использует длинные соединения (watch), чтобы получать обновления мгновенно. Это снижает нагрузку на API-сервер и ускоряет реакцию на изменения.

➡️ Kubelet — это граница между Kubernetes и фактическим выполнением кода. Он принимает декларативные описания подов из API и превращает их в живые контейнеры, обеспечивая обратную связь о состоянии. Без него узел остаётся просто сервером, не интегрированным в кластер.

#заметкиИнженера

😎 Иллюзия безопасности: почему бэкапы не спасают бизнес

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

✅ В новом материале разобрали, почему резервное копирование не равно отказоустойчивости, как ИТ-сбои и шифровальщики бьют по бизнесу и что нужно проверить, чтобы восстановление действительно сработало.

#статья

⬇️ Подборка self-hosted платформ для разработки и инфраструктуры

🟡 GitLab — полноценная DevOps-платформа с репозиториями кода, встроенным CI/CD, реестром контейнеров и управлением проектами. Community Edition доступна для самостоятельного развёртывания, данные остаются под контролем.

🟡 Nexus Repository — менеджер артефактов с поддержкой Maven, npm, Docker, PyPI и десятков других форматов. Позволяет проксировать внешние репозитории, хранить собственные сборки и управлять версиями.

🟡 Temporal — платформа для оркестрации распределённых рабочих процессов (workflow orchestration). Обеспечивает надёжное выполнение бизнес-логики с автоматическими повторными попытками, сохранением состояния и масштабированием.

🟡 NetBox — система учёта сетевой инфраструктуры и управления IP-адресами (DCIM/IPAM). Хранит единую модель данных: устройства, соединения, IP-планы, VLAN, кабели и т.д.

🟡 Outline — современная open-source вики-система для документации и базы знаний. Удобный редактор с Markdown, быстрый поиск, интеграция с Slack и возможность совместной работы.

#полезное