CORTEL
Відкрити в Telegram
Помогаем ИТ-директорам, DevOps и системным инженерам снижать TCO и поднимать SLA. Кейсы, инструменты и гайды. Сайт: https://cortel.cloud Cотрудничество: @ivan_cmo
Показати більше4 041
Підписники
-124 години
-47 днів
-1630 день
Триває завантаження даних...
Схожі канали
Хмара тегів
Вхідні та вихідні згадування
---
---
---
---
---
---
Залучення підписників
серпень '26
серпень '26
+5
в 0 каналах
липень '26
+17
в 5 каналах
Get PRO
червень '26
+18
в 1 каналах
Get PRO
травень '26
+23
в 2 каналах
Get PRO
квітень '26
+17
в 0 каналах
Get PRO
березень '26
+55
в 4 каналах
Get PRO
лютий '26
+53
в 2 каналах
Get PRO
січень '26
+74
в 2 каналах
Get PRO
грудень '25
+147
в 7 каналах
Get PRO
листопад '25
+72
в 4 каналах
Get PRO
жовтень '25
+139
в 6 каналах
Get PRO
вересень '25
+80
в 6 каналах
Get PRO
серпень '25
+87
в 7 каналах
Get PRO
липень '25
+135
в 7 каналах
Get PRO
червень '25
+116
в 6 каналах
Get PRO
травень '25
+160
в 3 каналах
Get PRO
квітень '25
+137
в 6 каналах
Get PRO
березень '25
+123
в 5 каналах
Get PRO
лютий '25
+203
в 6 каналах
Get PRO
січень '25
+152
в 5 каналах
Get PRO
грудень '24
+314
в 8 каналах
Get PRO
листопад '24
+141
в 7 каналах
Get PRO
жовтень '24
+192
в 5 каналах
Get PRO
вересень '24
+104
в 3 каналах
Get PRO
серпень '24
+216
в 8 каналах
Get PRO
липень '24
+219
в 7 каналах
Get PRO
червень '24
+163
в 3 каналах
Get PRO
травень '24
+185
в 11 каналах
Get PRO
квітень '24
+82
в 2 каналах
Get PRO
березень '24
+100
в 1 каналах
Get PRO
лютий '24
+223
в 3 каналах
Get PRO
січень '24
+130
в 4 каналах
Get PRO
грудень '23
+33
в 7 каналах
Get PRO
листопад '23
+110
в 1 каналах
Get PRO
жовтень '23
+127
в 7 каналах
Get PRO
вересень '23
+146
в 0 каналах
Get PRO
серпень '23
+104
в 0 каналах
Get PRO
липень '23
+147
в 0 каналах
Get PRO
червень '23
+229
в 0 каналах
Get PRO
травень '23
+107
в 0 каналах
Get PRO
квітень '23
+126
в 0 каналах
Get PRO
березень '23
+156
в 0 каналах
Get PRO
лютий '23
+384
в 0 каналах
Get PRO
січень '23
+40
в 0 каналах
Get PRO
грудень '22
+3
в 0 каналах
Get PRO
листопад '22
+2
в 0 каналах
Get PRO
жовтень '22
+76
в 0 каналах
Get PRO
вересень '22
+251
в 0 каналах
| Дата | Залучення підписників | Згадування | Канали | |
| 26 серпня | 0 | |||
| 25 серпня | 0 | |||
| 24 серпня | 0 | |||
| 23 серпня | 0 | |||
| 22 серпня | 0 | |||
| 21 серпня | 0 | |||
| 20 серпня | +1 | |||
| 19 серпня | 0 | |||
| 18 серпня | 0 | |||
| 17 серпня | 0 | |||
| 16 серпня | 0 | |||
| 15 серпня | 0 | |||
| 14 серпня | +1 | |||
| 13 серпня | +1 | |||
| 12 серпня | 0 | |||
| 11 серпня | 0 | |||
| 10 серпня | 0 | |||
| 09 серпня | +1 | |||
| 08 серпня | 0 | |||
| 07 серпня | 0 | |||
| 06 серпня | 0 | |||
| 05 серпня | 0 | |||
| 04 серпня | 0 | |||
| 03 серпня | 0 | |||
| 02 серпня | +1 | |||
| 01 серпня | 0 |
Дописи каналу
💻 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"
resources:
requests:
cpu: "200m"
memory: "256Mi"
limits:
memory: "1Gi"
# resources не задан вовсе| 2 |  ⏳ 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 по-прежнему быстрее.
Там, где нужны логи, лимиты ресурсов и порядок запуска, таймеры выигрывают.
#линуксятина | 570 |
| 3 |  🖥 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 — критические предупреждения.
😎 Главное — смотреть не только на текущее значение, но и на его изменение. Если число проблемных секторов или ошибок растёт, диск лучше заменить планово, не дожидаясь отказа.
#линуксятина | 804 |
| 4 |  ⚠️ Что делать после категорирования объекта КИИ
После присвоения категории объект становится частью живого контура: его нужно не только описать в документах, но и постоянно контролировать в эксплуатации.
Важно понимать:
🔵 что входит в контур объекта и кто за него отвечает;
🔵 кто имеет доступ и на каком основании;
🔵 какие изменения в инфраструктуре могут повлиять на работу системы;
🔵 как команда узнаёт о сбое, атаке или ошибке;
🔵 где хранятся резервные копии и как будет проходить восстановление;
🔵 когда нужно пересматривать сведения по объекту.
👉 Что меняется после категорирования объекта КИИ и какие требования 187-ФЗ важно учесть дальше — разобрали в новом материале.
#статья | 857 |
| 5 |  🐧 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, а другая модель работы с пакетным фильтром: декларативная, атомарная и заметно менее многословная на нетривиальных наборах правил.
#линуксятина | 901 |
| 6 |  💻 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 закрывает базовый сценарий эластичности — реакцию на изменение нагрузки без ручного вмешательства. Для более тонких сценариев (масштабирование по внешним очередям, множественные метрики, кастомная логика) конфигурация расширяется, но принцип остаётся тем же: контроллер сравнивает текущее состояние с целевым и приводит систему к балансу.
#заметкиИнженера | 649 |
| 7 |  Как ИИ-агенты снижают нагрузку: кейсы
👨💻Переход к агентам начинается с осознания, что ИИ – лишь инструмент, а не универсальное решение. Вместо того чтобы держать 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 #агенты #кейс | 688 |
| 8 |  ⚙️ 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 в одну команду, которую легко засунуть в скрипт.
#линуксятина | 794 |
| 9 |  💻 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.
#заметкиИнженера | 762 |
| 10 |  🖥 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-утилит экономит время.
#линуксятина | 883 |
| 11 |  📝 Шпаргалка по 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 — чтобы стандартизировать сбор телеметрии и сохранить свободу выбора инструментов. - вот это лишнее, потому что тоже самое что и трейсы, но по факту это инструмент для трейсов.
В рабочей системе эти три слоя обычно используются вместе: метрики показывают отклонение, логи дают детали, а трейсы помогают найти участок, где запрос начал тормозить или завершился ошибкой.
#полезное | 915 |
| 12 |  💻 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 не предназначен: конечные и периодические процессы. Правильно выставленные лимиты попыток, таймауты и политики очистки превращают их в надёжный инструмент автоматизации внутри кластера.
#заметкиИнженера | 957 |
| 13 | 💻 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 не предназначен: конечные и периодические процессы. Правильно выставленные лимиты попыток, таймауты и политики очистки превращают их в надёжный инструмент автоматизации внутри кластера.
#заметкиИнженера | 1 |
| 14 |  🤑 Как заработать с инфраструктуры больше?
Мы подняли партнёрское вознаграждение до 100% первого платежа клиента и гарантируем регулярный доход до 20% с дальнейших оплат.
Если назрела задача по VPS, облаку, бэкапам, каналам или чувствительным данным — можно дополнительно заработать в CORTEL : ребята подключатся, разберут задачу, подготовят решение, запустят инфраструктуру и будут поддерживать её 24/7, а вы получите регулярный дополнительный доход.
Выплаты не отменяются через год — вы продолжаете зарабатывать, пока клиент с нами. А сумма заработка не ограничена сверху 😊
📣 Полные условия и регистрация тут. | 2 054 |
| 15 |  🇷🇺 Импортозамещение VMware: куда и как переезжать в 2026 году
Как перестроить виртуальную инфраструктуру так, чтобы она пережила требования регуляторов, отсутствие западного саппорта, смену поколений железа, рост требований к сети и хранению — и при этом не убила эксплуатацию.
Разобрали в новом материале.
#статья | 972 |
| 16 |  🖥 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.
#линуксятина | 1 122 |
| 17 |  🤔 Сколько стоит контур по 152-ФЗ ?
Минимальный набор на 50 рабочих мест:
Secret Net Studio — около 303 тыс. ₽
Kaspersky — около 136 тыс. ₽
ViPNet для 20 пользователей — около 237 тыс. ₽
Континент 4 — около 1,2 млн ₽
Аудит соответствия — от 250 тыс. ₽
Итого — примерно 2,1 млн ₽.
С техподдержкой межсетевого экрана — уже больше 2,4 млн ₽.
❗️ И это без серверов, СХД, резервного копирования, второй площадки, аттестации, проектной документации и работы специалистов.
👉 В новом материале разобрали, когда свой контур по 152-ФЗ оправдан, а когда защищённое облако оказывается выгоднее и удобнее.
#статья | 360 |
| 18 |  💸 Как ДИТу говорить с бизнесом на языке денег
TCO, RTO, RPO, SLA, MTTR сами по себе ничего не объясняют.
Как обосновать бюджет на инфраструктуру через влияние на продажи, логистику, клиентский сервис и другие критичные процессы.
Как перевести ИТ-метрики в деньги, узнать цену простоя, какие риски и последствия допустимы и почему бездействие тоже имеет свою цену.
😎 Смотрите в выпуске по ссылке на любой удобной платформе
▶️ Rutube
▶️ YouTube
▶️ VK Видео | 1 188 |
| 19 |  💻 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.
#заметкиИнженера | 1 034 |
| 20 |  🛠 Поддержка инфраструктуры
«Поддержка 24/7» — чтобы понять, что это значит на самом деле, нужно заглянуть в договор.
В нём должно быть понятно, что входит в контур сопровождения и какие границы ответственности зафиксированы.
Если этого нет, то круглосуточная поддержка остаётся общей формулировкой, а в момент аварии начинается ручное управление и поиск того, кто должен включаться в работу.
👉 В новом материале разобрали, что должно стоять за поддержкой инфраструктуры 24/7, как отличить зрелую эксплуатацию от формальной техподдержки и какие вопросы задать подрядчику до подписания договора.
#статья | 1 026 |
