💐 С 8 Марта, прекрасная половина ИТ-вселенной!

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

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

С праздником!

🎙️ За неделю

📃 ERP-системы включили в КИИ
Правительство утвердило единый перечень типовых отраслевых объектов КИИ, куда включили ERP-системы. В документе они отдельно указаны для химической, металлургической, горнодобывающей, ракетно-космической и оборонной отраслей.

📃 Переход на российское оптоволокно перенесли до 2028 года
Минпромторг предлагает перенести обязательное использование российского оптоволокна на два года. Причина — отсутствие собственного производства.

📃 Объем утечек данных вырос
В 2025 году в сеть попало более 767 млн записей с данными россиян. Утечек стало меньше по числу случаев, но сами они стали крупнее.

📃 Рост рынка российского ПО замедлился
В 2025 году рынок вырос на 19%, тогда как годом ранее рост составлял 30%. Основные причины — высокая ключевая ставка, сокращение бюджетов и более осторожный подход компаний к ИТ-закупкам.

📃 Nvidia наращивает инвестиции в AI-инфраструктуру
Компания вложит по $2 млрд в производителей фотонных компонентов Lumentum и Coherent. На этом фоне мировые игроки продолжают вкладываться в развитие AI-инфраструктуры, а требования к технологиям для дата-центров постепенно растут.

🌐 HTTP-методы

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

🗣 GET
— получение данных.

Используется, когда клиенту нужно запросить ресурс у сервера: страницу, карточку товара, список пользователей. Метод не должен изменять данные на сервере.

🗣 POST
— создание нового ресурса.

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

🗣 PUT
— полное обновление ресурса.

Сервер получает новую полную версию объекта и заменяет ею текущую. Используется, когда нужно обновить ресурс целиком.

🗣 PATCH
— частичное изменение.

Подходит для точечного обновления: например, изменить только имя пользователя, статус заказа или один параметр настройки без перезаписи всего объекта.

🗣 DELETE
— удаление ресурса.

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

🗣 HEAD
— запрос без тела ответа.

Работает как GET, но сервер возвращает только заголовки. Удобен для проверки доступности ресурса, даты изменения или размера файла без загрузки содержимого.

🗣 OPTIONS
— проверка доступных действий.

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

🗣 CONNECT
— создание туннеля.

Используется для установки соединения через прокси-сервер, например при работе с HTTPS-трафиком.

🗣 TRACE
— диагностический запрос.

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

#полезное

Kube-scheduler: как Kubernetes назначает поды на ноды

При создании пода в Kubernetes он не появляется на конкретной ноде автоматически.
За выбор подходящего узла отвечает kube-scheduler — компонент control plane, который принимает решение, на какую ноду отправить новый или ожидающий назначения под.

🔭 Что делает kube-scheduler?

Основная задача — найти для каждого пода ноду, которая:
— соответствует всем жёстким требованиям (например, достаточно CPU и памяти, нужные метки, отсутствие запрещающих taint'ов);
— является наилучшей по ряду критериев (например, более свободная, с меньшей загрузкой, предпочитаемая по affinity).

После выбора scheduler сообщает API-серверу о назначении, и kubelet на выбранной ноде запускает под.

✍️ Как происходит планирование:

Процесс планирования логически делится на два этапа:

📌 Фильтрация (Predicates / Filtering)
Отсеиваются все ноды, которые не могут запустить под.
Проверяются:
🔵достаточно ли свободных ресурсов (CPU, память, диски, порты);
🔵соответствуют ли нода меткам, указанным в nodeSelector или nodeAffinity;
🔵не запрещают ли taints запуск пода без соответствующих tolerations;
🔵соблюдены ли правила Pod Affinity/Anti-Affinity;
🔵не конфликтуют ли с уже запущенными подами (например, занятые порты hostPort).

Результат — список подходящих нод.

📌 Оценка (Scoring / Prioritization)
Каждая оставшаяся нода получает баллы по различным критериям. Чем больше баллов, тем предпочтительнее нода.
Критерии могут быть разными:
🔵количество свободных ресурсов после запуска пода,
🔵сбалансированность использования ресурсов,
🔵близость к другим заданным подам (для уменьшения сетевых задержек), 🔵выполнение правил предпочтений (preferred affinity) и т.д.

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

Если подходящих нод нет — под остаётся в статусе Pending, и scheduler будет периодически повторять попытки.

⚙️ Ключевые механизмы управления планированием

💬 nodeSelector
— Простейший способ указать, что под должен быть размещён на ноде с определённой меткой.

💬 Affinity и Anti-Affinity
— Более выразительные правила, поддерживающие условия и уровни строгости (requiredDuringSchedulingIgnoredDuringExecution — жёсткое требование, preferredDuringSchedulingIgnoredDuringExecution — предпочтение).

— Node affinity: привязка к характеристикам ноды
— Pod affinity/anti-affinity: привязка к расположению других подов (например, требование запускать под на той же ноде, где уже работает под с меткой app=frontend, или, наоборот, избегать одной ноды с подами другого приложения).

💬 Taints и Tolerations — Taints (метка) наносятся на ноды и отталкивают поды, у которых нет соответствующих tolerations (переносимости). Позволяет выделять ноды под специальные задачи (например, только для GPU-нагрузок) или защищать мастер-ноды.

💬 Resource Requests и Limits — Scheduler учитывает запрошенные подом ресурсы (requests) и доступные на ноде. Без указания requests под может быть запланирован на перегруженную ноду, что приведёт к нехватке ресурсов для других.

💬 Приоритеты подов (Pod Priority and Preemption) — Поды можно разделять по приоритетам. Если высокоприоритетный под не может быть запланирован, scheduler может вытеснить (preempt) один или несколько низкоприоритетных подов с ноды, чтобы освободить место.

Kube-scheduler — это мозг Kubernetes по размещению подов. Он не просто выбирает первую попавшуюся ноду, а принимает взвешенное решение на основе множества факторов. Управление его поведением через манифесты позволяет строить эффективные и надёжные системы, максимально использующие мощности кластера.

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

⭐️ Karpenter — opensource-инструмент для автоматического масштабирования кластера Kubernetes, разработанный в AWS и переданный в CNCF.

Он мгновенно создаёт новые узлы (ноды) под неразмещённые поды, выбирая оптимальные типы инстансов и удаляя неиспользуемые, экономя ресурсы и деньги.

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

— Мгновенное создание узлов: при появлении подов, которые не могут быть запланированы, Karpenter за секунды запускает новые узлы (вместо минут, как у Cluster Autoscaler).
— Умный выбор инстансов: автоматически подбирает тип, размер, архитектуру (amd64/arm64), зону доступности на основе требований подов (resources, nodeSelector, affinity, topologySpread).
— Поддержка разнообразных ресурсов: GPU, специализированные инстансы (например, для машинного обучения).
— Автоматическая консолидация: удаляет неэффективные узлы и перепаковывает их поды на другие, оптимизируя заполнение кластера.
— Настройка через CRD: конфигурация описывается в ресурсах Provisioner и NodeTemplate.

👀 Ключевые преимущества

✅Скорость — Karpenter не ждёт, пока освободятся ресурсы на существующих узлах — он сразу создаёт новый, идеально подходящий под требования пода. Это особенно важно для burst-нагрузок и пакетных задач.
✅Гибкость — Позволяет точно контролировать, какие типы узлов используются, задавать limits по стоимости, выбирать между spot и on-demand, а также учитывать topologySpreadConstraints для распределения по зонам.
✅Отказ от групп узлов — В отличие от Cluster Autoscaler, которому нужны предопределённые группы. Karpenter управляет каждым узлом индивидуально. Это упрощает конфигурацию и убирает ограничения на размер группы.

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

👉 Git
#полезное

🕔 Cron — это классический планировщик задач в Unix-подобных системах.

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

Без него пришлось бы вручную запускать резервное копирование, ротацию логов или обновление кеша.

⏱ Как работает cron

За расписание отвечает демон crond (cron daemon). Он запускается при старте системы и постоянно работает в фоне. Crond читает конфигурационные файлы — crontab (cron tables) — и в нужный момент выполняет указанные команды.

⏱ Существуют два уровня crontab:

— Системные — лежат в /etc/crontab и в каталогах /etc/cron.d/, /etc/cron.daily/, /etc/cron.hourly/ и т.д. Требуют указания пользователя, от которого запускается задача.
— Пользовательские — создаются командой crontab -e для каждого пользователя отдельно. Запускаются от имени этого пользователя.

⏱ Формат записи crontab

Каждая строка в crontab описывает одно задание и состоит из пяти полей времени и команды:

* * * * * команда
│ │ │ │ │
│ │ │ │ └── день недели (0-7, где 0 и 7 = воскресенье)
│ │ │ └──── месяц (1-12)
│ │ └────── день месяца (1-31)
│ └──────── час (0-23)
└────────── минута (0-59)

⏱ Специальные символы:

— * — любое значение (каждую минуту, каждый час...)
— */n — каждые n единиц (например, */5 в поле минут — каждые 5 минут)
— , — перечисление (например, 1,15 в поле дня — 1-й и 15-й дни)
— - — диапазон (например, 9-17 в поле часа — с 9 до 17 включительно)

⏱ Управление пользовательским crontab

crontab -e          # открыть текущий crontab для редактирования (или создать новый)
crontab -l          # показать текущие задания
crontab -r          # удалить весь crontab
crontab -u username -l   # (от root) посмотреть crontab другого пользователя

⏱ Примеры заданий

Каждый день в 2:30 ночи

30 2 * * * /home/user/backup.sh

Первого числа каждого месяца в полночь

0 0 1 * * /home/user/cleanup.sh

Cron остаётся самым простым и надёжным способом автоматизации в Linux. Один раз настроил — и задачи выполняются годами без участия человека. Главное — не забывать проверять логи и не допускать конфликтов при одновременном запуске тяжёлых заданий.

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

🗞 Удобная шпаргалка по Linux CRON, которая всегда под рукой.

Компактно и наглядно 🥂

#полезное

⬇️ Подборка 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 и возможность совместной работы.

#полезное

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

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

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

#статья

💻 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 и превращает их в живые контейнеры, обеспечивая обратную связь о состоянии. Без него узел остаётся просто сервером, не интегрированным в кластер.

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

🔗 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
#полезное

📄 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] и т.д.) описывают уже конкретную логику работы юнита.

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

🐮🔮🌈 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

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

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

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

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

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

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

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

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

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

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

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

#ИТиЗАКОН

🌐 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.

#полезное

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

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

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

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

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

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

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

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

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

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

#полезное

💻 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 подов в стабильные точки доступа и равномерно распределяя нагрузку.

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

🐙 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
#полезное

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 даёт быстрый доступ к логам через единый интерфейс с удобной фильтрацией — без необходимости парсить текстовые файлы.

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

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

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

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

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

#статья

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

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

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

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

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

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

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

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

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

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

#полезное