CORTEL

💻 QoS-классы в Kubernetes: как определяется приоритет подов Каждый под в кластере получает класс качества обслуживания — QoS class. kubelet вычисляет его сам, исходя из того, как в поде описаны requests и limits. QoS-класс влияет на приоритет вытеснения подов при нехватке памяти на ноде. 👑 Guaranteed Самый высокий приоритет. — У каждого контейнера в поде заданы requests и limits для CPU и памяти — Для каждого ресурса requests равны limits — Правило распространяется и на init-контейнеры

resources:
  requests:
    cpu: "1"
    memory: "1Gi"
  limits:
    cpu: "1"
    memory: "1Gi"

Такие поды вытесняются последними и получают oom_score_adj: -997 — ядро убивает их процессы в самую последнюю очередь. Подходит для БД, брокеров очередей и всего, что нельзя терять при скачке нагрузки на соседей. 🥈 Burstable Промежуточный класс. Хотя бы у одного контейнера должен быть задан request или limit по CPU или памяти, но до критериев Guaranteed под не дотягивает.

resources:
  requests:
    cpu: "200m"
    memory: "256Mi"
  limits:
    memory: "1Gi"

Под может забирать ресурсы сверх requests, пока они свободны на ноде. Но при нехватке памяти он попадает под вытеснение раньше Guaranteed. Внутри класса порядок тоже не случайный: первыми уходят поды, которые потребляют больше, чем запросили. Самый частый класс в реальных кластерах и разумный выбор по умолчанию для stateless-приложений. 🎭 BestEffort Ни у одного контейнера в поде не указано ни одного request или limit.

# resources не задан вовсе

Такой под планируется куда угодно и потребляет всё, до чего дотянется. При нехватке памяти на ноде он уходит первым, а его oom_score_adj равен 1000 — максимальный приоритет для OOM Killer. Годится для разовых задач, где потеря пода ничего не стоит, и категорически не годится для продакшн-сервисов. ➡️ Важные нюансы — QoS-класс вычисляется один раз при создании пода и меняется только вместе с пересозданием — Классы влияют на вытеснение по памяти; CPU при превышении лимита не убивает под, а троттлит его — Guaranteed не защищает от аппаратного сбоя ноды и от вытеснения по нехватке места на диске — Один контейнер без resources внутри многоконтейнерного пода опускает весь под до Burstable #заметкиИнженера

⏳ systemd .timer — штатный планировщик задач в systemd, альтернатива cron. Таймер активирует полноценный .service. Каждый запуск попадает в journald, получает свой cgroup, лимиты по памяти и CPU, а также зависимости — задачу можно привязать к готовности сети или базы. ➡️ Пример

/etc/systemd/system/backup.service:
[Unit]
Description=Backup job

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

/etc/systemd/system/backup.timer
[Unit]
Description=Run backup daily

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer

Включается таймер, а не сервис. ➡️ Расписание Календарное, через OnCalendar= — формат DayOfWeek Year-Month-Day Hour:Minute:Second: — *-*-* 03:00:00 — ежедневно в 3 ночи — Mon..Fri 09:00 — по будням — *:0/15 — каждые 15 минут — daily, weekly, hourly — сокращения ➡️ Монотонное, от событий — OnBootSec= — через N после загрузки — OnUnitActiveSec= — через N после прошлого запуска Связка OnBootSec=5min + OnUnitActiveSec=1h даёт запуск через пять минут после старта и дальше каждый час. ➡️ Полезные директивы — Persistent=true — пропущенный запуск (машина была выключена) отработает после загрузки. В cron такого нет — RandomizedDelaySec=300 — случайный разброс, спасает от одновременного старта на сотне нод — AccuracySec=1s — точность, по умолчанию минута — Unit= — запустить юнит с другим именем Для разовой мелочи cron по-прежнему быстрее. Там, где нужны логи, лимиты ресурсов и порядок запуска, таймеры выигрывают. #линуксятина

🖥 smartctl — утилита из пакета smartmontools для чтения диагностических данных накопителя через S.M.A.R.T. Диск часто предупреждает о скором отказе заранее: растёт число переназначенных секторов и ошибок чтения, повышается температура. smartctl помогает увидеть эти признаки до того, как дисковый массив перейдёт в состояние отказа. S.M.A.R.T. — это встроенная в накопитель система диагностики. Она собирает данные о его состоянии, а smartctl выводит их в понятном виде ➡️ Основные команды

# Общая информация
sudo smartctl -i /dev/sda

# Краткая оценка состояния
sudo smartctl -H /dev/sda

# Таблица показателей
sudo smartctl -A /dev/sda

# Полный отчёт
sudo smartctl -a /dev/sda

# Запуск короткого самотеста
sudo smartctl -t short /dev/sda

# Результаты самотестов
sudo smartctl -l selftest /dev/sda

➡️ На что смотреть у HDD — Reallocated_Sector_Ct — переназначенные секторы. Рост значения — повод менять диск; — Current_Pending_Sector — секторы, которые не читаются, но ещё не переназначены; — Offline_Uncorrectable — неисправимые ошибки; — UDMA_CRC_Error_Count — ошибки передачи данных. Причина может быть в кабеле или дисковой корзине; — Power_On_Hours — наработка; — Temperature_Celsius — температура. ➡️ У SSD дополнительно проверяют — Wear_Leveling_Count — износ ячеек; — Media_Wearout_Indicator — износ памяти NAND; — Total_LBAs_Written — общий объём записанных данных. ➡️ У NVMe основные показатели — percentage_used — израсходованный ресурс; — available_spare — резерв запасных блоков; — media_errors — ошибки носителя; — critical_warning — критические предупреждения. 😎 Главное — смотреть не только на текущее значение, но и на его изменение. Если число проблемных секторов или ошибок растёт, диск лучше заменить планово, не дожидаясь отказа. #линуксятина

⚠️ Что делать после категорирования объекта КИИ После присвоения категории объект становится частью живого контура: его нужно не только описать в документах, но и постоянно контролировать в эксплуатации. Важно понимать: 🔵 что входит в контур объекта и кто за него отвечает; 🔵 кто имеет доступ и на каком основании; 🔵 какие изменения в инфраструктуре могут повлиять на работу системы; 🔵 как команда узнаёт о сбое, атаке или ошибке; 🔵 где хранятся резервные копии и как будет проходить восстановление; 🔵 когда нужно пересматривать сведения по объекту. 👉 Что меняется после категорирования объекта КИИ и какие требования 187-ФЗ важно учесть дальше — разобрали в новом материале. #статья

🐧 nftables — современный фреймворк для фильтрации пакетов и NAT в Linux, пришедший на смену связке iptables/ip6tables/arptables/ebtables. Зачем менять iptables на nftables — Единый синтаксис для IPv4, IPv6, ARP и Ethernet-фреймов вместо четырёх отдельных утилит — Правила применяются атомарно — нет промежуточного состояния с частично применённым набором — Встроенные структуры данных (sets, maps) вместо десятков однотипных правил — Меньше накладных расходов на большом количестве правил за счёт более эффективной модели обработки в ядре 🟡 Структура: таблицы → цепочки → правила — Таблица (table) — контейнер верхнего уровня, привязан к семейству адресов: ip, ip6, inet (сразу для v4 и v6), arp, bridge, netdev — Цепочка (chain) — набор правил внутри таблицы. Бывает базовой (base chain, подключена к хукам ядра) или обычной — Правило (rule) — конкретное условие + действие (accept, drop, jump, counter и т.д.) Хуки для базовых цепочек: prerouting, input, forward, output, postrouting — те же точки, что и в iptables, но привязка задаётся явно при создании цепочки. 🟡 Базовая структура набора правил

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        ct state established,related accept
        iifname "lo" accept
        tcp dport 22 accept
    }
}

— table inet filter — таблица для v4/v6 с именем filter — chain input — базовая цепочка на хуке input, приоритет 0, политика по умолчанию — drop — ct state established,related accept — разрешить пакеты уже установленных соединений — tcp dport 22 accept — разрешить входящий SSH 🟡 Пример: NAT для проброса порта (DNAT)

table ip nat {
    chain prerouting {
        type nat hook prerouting priority -100;
        tcp dport 8443 dnat to 10.0.0.5:443
    }
    chain postrouting {
        type nat hook postrouting priority 100;
        oifname "eth0" masquerade
    }
}

Входящий трафик на порт 8443 перенаправляется на внутренний сервер 10.0.0.5:443, а masquerade подменяет исходящий адрес для трафика, уходящего через eth0 — типичная схема для VPS с внутренними сервисами за одним внешним IP. 🟡 Полезные команды

nft list ruleset
nft -f /etc/nftables.conf
nft add table inet filter
nft flush ruleset

nftables — не косметическая замена iptables, а другая модель работы с пакетным фильтром: декларативная, атомарная и заметно менее многословная на нетривиальных наборах правил. #линуксятина

💻 HPA: автоскейлинг по метрикам Horizontal Pod Autoscaler (HPA) — встроенный контроллер Kubernetes, который автоматически изменяет количество реплик Deployment, StatefulSet или ReplicaSet в зависимости от текущей нагрузки. Задача HPA — держать нагрузку на под в заданных рамках, не привлекая к этому человека. 🔺 HPA работает в цикле (по умолчанию — раз в 15 секунд): — Получает текущие метрики из metrics-server (или внешнего адаптера метрик, если используются custom/external metrics) — Сравнивает текущее значение метрики со значением, заданным в спецификации HPA — Вычисляет желаемое количество реплик по формуле:

desiredReplicas = ceil(currentReplicas * (currentMetricValue / desiredMetricValue))

— Обновляет поле replicas у целевого объекта (Deployment/StatefulSet) Контроллер не действует резко: изменения сглаживаются, а между операциями масштабирования выдерживается пауза (stabilization window), чтобы избежать «дребезга» — постоянных колебаний числа реплик туда-обратно. 🔺 Источники метрик — Resource metrics — CPU и память пода, собираются через metrics-server. Базовый и самый распространённый вариант. — Custom metrics — метрики приложения (например, число запросов в очереди), поставляются через Prometheus или аналогичный адаптер. — External metrics — метрики внешних систем, не привязанные к объектам Kubernetes Минимальная настройка Предполагается, что для пода заданы resources.requests.cpu — без них HPA не сможет посчитать процент утилизации.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Частые ошибки — Отсутствие requests у контейнеров — метрика Utilization считается относительно запроса ресурсов, без него HPA не сработает — Слишком узкий диапазон minReplicas–maxReplicas — контроллеру физически негде масштабироваться — Игнорирование stabilization window при настройке — резкие пики нагрузки могут вызывать частые колебания без её корректной настройки в behavior — Использование HPA и VPA на одних и тех же метриках ресурсов одновременно — контроллеры начинают конфликтовать между собой HPA закрывает базовый сценарий эластичности — реакцию на изменение нагрузки без ручного вмешательства. Для более тонких сценариев (масштабирование по внешним очередям, множественные метрики, кастомная логика) конфигурация расширяется, но принцип остаётся тем же: контроллер сравнивает текущее состояние с целевым и приводит систему к балансу. #заметкиИнженера

Как ИИ-агенты снижают нагрузку: кейсы 👨‍💻Переход к агентам начинается с осознания, что ИИ – лишь инструмент, а не универсальное решение. Вместо того чтобы держать 10 вкладок Claude Code в браузере, DevOps-инженер Евгений Дехтярёв создал автономную систему на базе оркестратора Paperclip и моделей Claude (Opus/Sonnet). Ниже мы описали, как агенты справляются с задачами команды из 50 разработчиков и менеджеров. ⏺Рутина под ключ На практике агенты отлично справляются с рутиной для оптимизации времени и ресурсов. Так, Claude Code самостоятельно создает техническое задание с соблюдением логики и контекста и по нему выполняет простую инфраструктурную задачу. За месяц 34 тикета были отданы агентам: ⁃ GitLab CI/ Runners – 7 ⁃ Kubernetes – 6 ⁃ Storage/S3 – 6 ⁃ Базы данных – 6 ⁃ VM lifecycle – 4 ⁃ Бэкапы. Домены – 4 ⁃ Мониторинг (Grafana) – 1 ⏺Разбор алертов Получив RO доступ к stage- и prod-средам, а также общий контекст системы, SRE-агент запускает разбор ошибок в системе оповещений. После диагностики он ставит гипотезу о первопричине ошибки и сообщает о результатах в тредах Slack-каналов. Так, разработчики сразу видят RCA и могут сразу приступить к внесению изменений. ⏺FinOps по нескольким облакам Для оптимизации облачных расходов команда должна держать руку на пульсе и обосновывать каждое техническое решение. Агент-аналитик упрощает ведение отчетности, собирает биллинг по всем провайдерам. С его помощью Евгений обнаружил подключенные мониторинг и логирование от Google. После отказа от сервисов команда сэкономила 400$ ежемесячно. 👀Подробнее о ролях и задачах агентов, подводных камнях в работе – в записи выступления. #devops #ai #агенты #кейс

⚙️ jq и yq — два похожих инструмента для работы со структурированными данными прямо в терминале: jq для JSON, yq для YAML. Оба решают одну и ту же боль — вытащить, отфильтровать или изменить нужное поле из структуры данных без написания скрипта. 🟢 jq — Принимает JSON на входе, применяет фильтр-выражение, отдаёт результат — тоже JSON (или текст). Базовый синтаксис:

команда | jq 'фильтр'

Пример исходных данных (response.json):

{
  "status": "ok",
  "pods": [
    {"name": "nginx-1", "ready": true, "restarts": 0},
    {"name": "nginx-2", "ready": false, "restarts": 5}
  ]
}

Достать конкретное поле:

cat response.json | jq '.status'

"ok:"

Пройтись по массиву и вытащить имена:

cat response.json | jq '.pods[].name'

"nginx-1"
"nginx-2"

Фильтрация по условию:

cat response.json | jq '.pods[] | select(.ready == false)'

{
  "name": "nginx-2",
  "ready": false,
  "restarts": 5
}

🟢 yq — по духу — тот же jq, только для YAML синтаксис фильтров почти идентичен jq. Пример файла (deployment.yaml):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: nginx
          image: nginx:1.25

Достать значение:

yq '.spec.replicas' deployment.yaml

3

Сменить образ контейнера:

yq -i '.spec.template.spec.containers[0].image = "nginx:1.27"' deployment.yaml

🟢 jq и yq — база для любого, кто работает с API, Kubernetes или CI/CD: они превращают ручной разбор JSON/YAML в одну команду, которую легко засунуть в скрипт. #линуксятина

💻 PV, PVC и StorageClass: как под получает диск в Kubernetes Контейнеры по умолчанию эфемерны — при перезапуске пода всё содержимое файловой системы исчезает. Для баз данных, очередей и любых сервисов с состоянием это неприемлемо, поэтому в Kubernetes существует отдельная модель работы с хранилищем, отвязанная от жизненного цикла пода. 🔺Persistent Volume (PV) — Объект кластера, описывающий конкретный кусок хранилища: диск в облаке, LUN, NFS-шару или локальный volume. — Существует независимо от пода — создаётся и удаляется отдельно, имеет свой жизненный цикл. — Содержит параметры реального хранилища: размер, режим доступа, драйвер, точки монтирования. 🔺Persistent Volume Claim (PVC) — Запрос приложения на хранилище: «нужно 10Gi с доступом ReadWriteOnce». — PVC не знает, где физически лежат данные — это уровень абстракции для разработчика. — Kubernetes сопоставляет PVC с подходящим PV (bind), и только после этого том можно смонтировать в под. 🔺 StorageClass — Описывает «класс» хранилища и параметры его создания: тип диска, зону, файловую систему, политику удаления. — Позволяет не создавать PV вручную — при появлении PVC с указанным StorageClass том создаётся автоматически. — Именно StorageClass связывает Kubernetes с конкретным драйвером хранилища через CSI. 🔺 CSI (Container Storage Interface) — Стандартизированный API, через который Kubernetes общается с системами хранения без встроенной поддержки в ядре kubelet. — Каждый провайдер (Ceph, облачный диск, NFS и т.д.) поставляет свой CSI-драйвер как набор подов в кластере. — Драйвер отвечает за создание, подключение (attach) и монтирование (mount) томов по запросу Kubernetes. Как это работает вместе (динамическое провижининг)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-pvc
spec:
  storageClassName: fast-ssd
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

— Приложение создаёт PVC с указанием StorageClass. — Контроллер провижининга (часть CSI-драйвера) видит PVC без привязанного PV и создаёт новый PV через API стораджа. — Kubernetes связывает созданный PV с PVC (bind). — Под с этим PVC планируется на узел, kubelet через CSI-драйвер выполняет монитрование тома. Без CSI и динамического провижининга администратору пришлось бы вручную создавать PV под каждый запрос приложения. Эта связка убирает ручной шаг и делает хранилище таким же декларативным ресурсом, как Deployment или Service. #заметкиИнженера

🖥 ip / iproute2 — стандарт для управления сетью в современном Linux. Пришёл на смену устаревшему net-tools (ifconfig, route, arp), которые давно не входят в базовую установку большинства дистрибутивов. Всё, что раньше делалось десятком разных утилит, теперь собрано в одной команде с единым синтаксисом. 🟣 Как устроено? Команда ip работает по схеме:

ip [объект] [команда]

Где объект — это то, чем управляем (link, addr, route, neigh и т.д.), а команда — действие над ним (show, add, del, set). 🟣 Основные объекты link — сетевые интерфейсы (физические и виртуальные) address (a) — IP-адреса на интерфейсах route (r) — таблица маршрутизации neighbour (n) — ARP/NDP-таблица (соседи) rule — правила policy routing netns — сетевые неймспейсы 🟣 Примеры команд Посмотреть список всех интерфейсов:

ip link show

Поднять/выключить интерфейс:

sudo ip link set eth0 up
sudo ip link set eth0 down

Посмотреть адреса на интерфейсах:

ip addr show

1: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
    inet 192.168.1.10/24 brd 192.168.1.255 scope global eth0

Добавить маршрут:

sudo ip route add 10.0.0.0/24 via 192.168.1.1 dev eth0

Добавить маршрут по умолчанию:

sudo ip route add default via 192.168.1.1

Удалить маршрут:

sudo ip route del 10.0.0.0/24

✔️ iproute2 — это единый интерфейс ко всему сетевому стеку ядра: линки, адреса, маршруты, правила, туннели, неймспейсы. Знание ip вместо разрозненных legacy-утилит экономит время. #линуксятина

📝 Шпаргалка по Logging, Tracing и Metrics. Помогает понять, как устроен мониторинг в распределённых системах: что измерять, где искать события и как восстанавливать путь запроса между сервисами. ➡️ Три компонента мониторинга — Metrics (метрики) Числовые показатели системы во времени: загрузка CPU и памяти, RPS, задержка, процент ошибок, количество запросов, доступность сервисов. Метрики хорошо подходят для дашбордов, алертов и быстрой оценки состояния системы. — Logging (логирование) События, которые происходят внутри приложения или инфраструктуры: ошибки, предупреждения, действия пользователя, сбои интеграций, системные сообщения. Логи помогают разбирать конкретные инциденты и понимать, что произошло внутри сервиса. — Tracing (трассировка запросов) Путь одного запроса через несколько сервисов. Особенно полезно в микросервисной архитектуре, где один пользовательский запрос может пройти через API, очередь, базу данных и несколько внутренних сервисов. ➡️ Как это обычно собирается — Метрики сервисов отправляются в базы данных для мониторинга: Prometheus, InfluxDB, VictoriaMetrics — Логи собираются с хостов и приложений, затем передаются в хранилище и систему анализа: Logstash, Elasticsearch, Kibana. — Трейсы собираются через OpenTelemetry: SDK, API, auto instrumentation и OTel Collector. — Дальше данные можно передавать в разные системы анализа и визуализации: Grafana, DataSet, Lightstep, Honeycomb, Jaeger. ➡️ Где что использовать ➡️ метрики — чтобы быстро увидеть состояние системы; ➡️ логи — чтобы разобрать конкретную ошибку; ➡️ трейсы — чтобы проследить путь запроса между сервисами; ➡️ OpenTelemetry — чтобы стандартизировать сбор телеметрии и сохранить свободу выбора инструментов. - вот это лишнее, потому что тоже самое что и трейсы, но по факту это инструмент для трейсов. В рабочей системе эти три слоя обычно используются вместе: метрики показывают отклонение, логи дают детали, а трейсы помогают найти участок, где запрос начал тормозить или завершился ошибкой. #полезное

💻 Job и CronJob: разовые и периодические задачи в Kubernetes Deployment создан для приложений, которые должны работать постоянно: упал под — контроллер тут же поднимет новый. Но не всякая нагрузка такая. Миграция базы, генерация отчёта, очистка старых данных — задачи, которые должны выполниться до конца и завершиться. Для них в Kubernetes есть Job и CronJob. 💬 Job — задача, которая должна завершиться успешно Job создаёт под (или несколько) и следит не за тем, чтобы он работал, а за тем, чтобы он успешно завершился (exit code 0). Если под упал — Job перезапустит его, пока задача не выполнится или не исчерпается лимит попыток.

apiVersion: batch/v1
kind: Job
metadata:
  name: db-migration
spec:
  backoffLimit: 3            # максимум 3 повторные попытки
  activeDeadlineSeconds: 600 # убить задачу, если не уложилась в 10 минут
  ttlSecondsAfterFinished: 3600 # удалить Job через час после завершения
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: migrate
        image: myapp:1.07
        command: ["python", "manage.py", "migrate"]

Ключевые параметры: — backoffLimit — сколько раз перезапускать упавшую задачу (по умолчанию 6, с экспоненциальной задержкой); — completions и parallelism — сколько успешных выполнений требуется и сколько подов могут работать одновременно. Так реализуется параллельная обработка очереди; — activeDeadlineSeconds — жёсткий таймаут на всю задачу; — ttlSecondsAfterFinished — автоочистка завершённых Job. Без него завершённые поды и объекты Job копятся в кластере бесконечно. 💬 CronJob — Job по расписанию CronJob — это контроллер, который по расписанию (классический cron-синтаксис) создаёт объекты Job. Сам он ничего не выполняет — только штампует Job'ы в нужный момент.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: report-generator
spec:
  schedule: "0 3 * * *"          # каждый день в 03:00
  concurrencyPolicy: Forbid       # не запускать новый, пока работает старый
  startingDeadlineSeconds: 300
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 5
  jobTemplate:
    spec:
      backoffLimit: 2
      template:
        spec:
          restartPolicy: Never
          containers:
          - name: report
            image: reports:2.1

➡️ На что обратить внимание: — concurrencyPolicy — что делать, если предыдущий запуск ещё не завершился: Allow (запускать параллельно), Forbid (пропустить новый), Replace (убить старый и запустить новый). Для долгих задач Allow по умолчанию — частый источник проблем; — startingDeadlineSeconds — если запуск был пропущен (например, control plane был недоступен), в течение этого окна CronJob ещё попытается его выполнить; — расписание считается в часовом поясе kube-controller-manager, но можно задать явно через поле timeZone. Job и CronJob закрывают целый класс задач, для которого Deployment не предназначен: конечные и периодические процессы. Правильно выставленные лимиты попыток, таймауты и политики очистки превращают их в надёжный инструмент автоматизации внутри кластера. #заметкиИнженера

💻 Job и CronJob: разовые и периодические задачи в Kubernetes Deployment создан для приложений, которые должны работать постоянно: упал под — контроллер тут же поднимет новый. Но не всякая нагрузка такая. Миграция базы, генерация отчёта, очистка старых данных — задачи, которые должны выполниться до конца и завершиться. Для них в Kubernetes есть Job и CronJob. 💬 Job — задача, которая должна завершиться успешно Job создаёт под (или несколько) и следит не за тем, чтобы он работал, а за тем, чтобы он успешно завершился (exit code 0). Если под упал — Job перезапустит его, пока задача не выполнится или не исчерпается лимит попыток. apiVersion: batch/v1 kind: Job metadata: name: db-migration spec: backoffLimit: 3 # максимум 3 повторные попытки activeDeadlineSeconds: 600 # убить задачу, если не уложилась в 10 минут ttlSecondsAfterFinished: 3600 # удалить Job через час после завершения template: spec: restartPolicy: Never containers: - name: migrate image: myapp:1.07 command: ["python", "manage.py", "migrate"] Ключевые параметры: — backoffLimit — сколько раз перезапускать упавшую задачу (по умолчанию 6, с экспоненциальной задержкой); — completions и parallelism — сколько успешных выполнений требуется и сколько подов могут работать одновременно. Так реализуется параллельная обработка очереди; — activeDeadlineSeconds — жёсткий таймаут на всю задачу; — ttlSecondsAfterFinished — автоочистка завершённых Job. Без него завершённые поды и объекты Job копятся в кластере бесконечно. 💬 CronJob — Job по расписанию CronJob — это контроллер, который по расписанию (классический cron-синтаксис) создаёт объекты Job. Сам он ничего не выполняет — только штампует Job'ы в нужный момент. apiVersion: batch/v1 kind: CronJob metadata: name: report-generator spec: schedule: "0 3 * * *" # каждый день в 03:00 concurrencyPolicy: Forbid # не запускать новый, пока работает старый startingDeadlineSeconds: 300 successfulJobsHistoryLimit: 3 failedJobsHistoryLimit: 5 jobTemplate: spec: backoffLimit: 2 template: spec: restartPolicy: Never containers: - name: report image: reports:2.1 ➡️ На что обратить внимание: — concurrencyPolicy — что делать, если предыдущий запуск ещё не завершился: Allow (запускать параллельно), Forbid (пропустить новый), Replace (убить старый и запустить новый). Для долгих задач Allow по умолчанию — частый источник проблем; — startingDeadlineSeconds — если запуск был пропущен (например, control plane был недоступен), в течение этого окна CronJob ещё попытается его выполнить; — расписание считается в часовом поясе kube-controller-manager, но можно задать явно через поле timeZone. Job и CronJob закрывают целый класс задач, для которого Deployment не предназначен: конечные и периодические процессы. Правильно выставленные лимиты попыток, таймауты и политики очистки превращают их в надёжный инструмент автоматизации внутри кластера. #заметкиИнженера

🤑 Как заработать с инфраструктуры больше? Мы подняли партнёрское вознаграждение до 100% первого платежа клиента и гарантируем регулярный доход до 20% с дальнейших оплат. Если назрела задача по VPS, облаку, бэкапам, каналам или чувствительным данным — можно дополнительно заработать в CORTEL : ребята подключатся, разберут задачу, подготовят решение, запустят инфраструктуру и будут поддерживать её 24/7, а вы получите регулярный дополнительный доход. Выплаты не отменяются через год — вы продолжаете зарабатывать, пока клиент с нами. А сумма заработка не ограничена сверху 😊 📣 Полные условия и регистрация тут.

🇷🇺 Импортозамещение VMware: куда и как переезжать в 2026 году Как перестроить виртуальную инфраструктуру так, чтобы она пережила требования регуляторов, отсутствие западного саппорта, смену поколений железа, рост требований к сети и хранению — и при этом не убила эксплуатацию. Разобрали в новом материале. #статья

🖥 AWK — мощный язык обработки текста, заточенный под построчный разбор данных по колонкам. Назван по фамилиям создателей (Aho, Weinberger, Kernighan). Незаменим там, где нужно вытащить, отфильтровать или пересчитать данные из таблиц, логов и вывода других утилит. В отличие от grep (ищет строки) и sed (правит текст потоком), AWK мыслит записями и полями. Каждая строка — это запись, разбитая на колонки. Это превращает обработку структурированного вывода (ps, df, /etc/passwd, CSV, логи) в простые однострочники. Программа на AWK — это набор правил вида:

awk 'паттерн { действие }' файл 

— паттерн — условие, при котором срабатывает действие (можно опустить — тогда срабатывает на каждой строке) — действие — что сделать с записью (можно опустить — тогда печатается строка целиком) ➡️ Ключевые встроенные переменные: $0 — вся строка целиком $1, $2, ... — поля (колонки) по порядку NF — количество полей в строке (Number of Fields) NR — номер текущей строки (Number of Records) FS — разделитель полей на входе (по умолчанию — пробелы/табы) OFS — разделитель полей на выходе ➡️ Основные параметры -F — задать разделитель полей (-F: для /etc/passwd, -F, для CSV) -v — передать переменную внутрь программы (-v threshold=80) -f — взять программу из файла, а не из строки 🔵Блоки BEGIN и END BEGIN выполняется до чтения файла, END — после. Удобно для заголовков и итогов. ✅ Примеры Вывести только нужные колонки (имя пользователя и shell из passwd):

awk -F: '{print $1, $7}' /etc/passwd

root /bin/bash
daemon /usr/sbin/nologin

Найти процессы, потребляющие больше 50% CPU:

ps aux | awk '$3 > 50 {print $2, $11}' 

Отфильтровать строки лога по коду ответа nginx и посчитать количество 5xx:

awk '$9 ~ /^5/ {count++} END{print "5xx errors:", count}' access.log 

AWK — это полноценный мини-язык. Для разовых однострочников он экономит десятки строк на grep | cut | sort, а в скриптах закрывает всю обработку табличных данных без выхода в Python. #линуксятина

🤔 Сколько стоит контур по 152-ФЗ ? Минимальный набор на 50 рабочих мест: Secret Net Studio — около 303 тыс. ₽ Kaspersky — около 136 тыс. ₽ ViPNet для 20 пользователей — около 237 тыс. ₽ Континент 4 — около 1,2 млн ₽ Аудит соответствия — от 250 тыс. ₽ Итого — примерно 2,1 млн ₽. С техподдержкой межсетевого экрана — уже больше 2,4 млн ₽. ❗️ И это без серверов, СХД, резервного копирования, второй площадки, аттестации, проектной документации и работы специалистов. 👉 В новом материале разобрали, когда свой контур по 152-ФЗ оправдан, а когда защищённое облако оказывается выгоднее и удобнее. #статья

💸 Как ДИТу говорить с бизнесом на языке денег TCO, RTO, RPO, SLA, MTTR сами по себе ничего не объясняют. Как обосновать бюджет на инфраструктуру через влияние на продажи, логистику, клиентский сервис и другие критичные процессы. Как перевести ИТ-метрики в деньги, узнать цену простоя, какие риски и последствия допустимы и почему бездействие тоже имеет свою цену. 😎 Смотрите в выпуске по ссылке на любой удобной платформе ▶️ Rutube ▶️ YouTube ▶️ VK Видео

💻 StatefulSet vs Deployment vs DaemonSet: три способа управлять подами В Kubernetes важно не просто запустить под, а выбрать правильный контроллер. Не тот контроллер может привести к потерянным данным, лишним подам на нодах или странному поведению БД. 💬 Deployment — для stateless-нагрузок Управляет ReplicaSet'ом, который поддерживает заданное число одинаковых, взаимозаменяемых подов. — Поды получают случайные имена (app-7d4b9c8f6-x2k9p) — При обновлении старые поды удаляются, новые создаются с нуля — история не важна — Поддерживает RollingUpdate и Recreate — стратегии обновления — Любой под может заменить любой другой без последствий Подходит для: API, фронтенд, воркеры без сохраняемого состояния. 💬 StatefulSet — для нагрузок с сохранением состояния Гарантирует стабильную идентичность каждого пода — то, чего Deployment принципиально не даёт. — Имена подов предсказуемы и постоянны (db-0, db-1, db-2) — Каждый под получает свой PersistentVolumeClaim, который сохраняется при пересоздании пода — Поды создаются и удаляются строго по порядку (0 → 1 → 2 и обратно) — Требует headless Service для сетевой идентичности — DNS-имя вида db-0.db-service.namespace.svc.cluster.local Подходит для: БД (PostgreSQL, MongoDB), очереди (Kafka), etcd — всё, где важны порядок запуска, стабильный сетевой адрес и привязка к своему тому. 💬 DaemonSet — для нагрузок на каждой ноде Гарантирует, что копия пода будет запущена на каждой (или на выбранном подмножестве) ноде кластера — не больше и не меньше. — Число подов = число подходящих нод, а не заданное значение replicas — При добавлении новой ноды под создаётся автоматически — При удалении ноды под удаляется вместе с ней — Игнорирует обычный scheduler в пользу собственной логики размещения, учитывает nodeSelector и taints/tolerations Подходит для: агенты мониторинга (node-exporter), сборщики логов, CNI-плагины на каждом хосте. 👀 Выбор контроллера — Если поды одинаковые и могут спокойно заменять друг друга — это Deployment. — Если каждому поду нужны своё имя, сетевой адрес и отдельное хранилище — это StatefulSet. — Если под должен запускаться на каждой подходящей ноде — это DaemonSet. #заметкиИнженера

🛠 Поддержка инфраструктуры «Поддержка 24/7» — чтобы понять, что это значит на самом деле, нужно заглянуть в договор. В нём должно быть понятно, что входит в контур сопровождения и какие границы ответственности зафиксированы. Если этого нет, то круглосуточная поддержка остаётся общей формулировкой, а в момент аварии начинается ручное управление и поиск того, кто должен включаться в работу. 👉 В новом материале разобрали, что должно стоять за поддержкой инфраструктуры 24/7, как отличить зрелую эксплуатацию от формальной техподдержки и какие вопросы задать подрядчику до подписания договора. #статья