📝 Шпаргалка по проектированию безопасных систем.

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

🔐 Основные направления защиты

— Authentication
Проверка того, кто входит в систему. Сюда относятся парольная политика, MFA, доступ сотрудников к внутренним сервисам и защита учётных записей.

— Authorization
Управление правами после входа. Роли, уровни доступа, принцип минимальных привилегий и регулярный пересмотр выданных прав.

— Encryption
Защита данных при передаче и хранении. TLS, шифрование чувствительной информации, управление ключами и контроль доступа к ним.

— Vulnerability Management
Работа с уязвимостями. Патчи, регулярное сканирование, мониторинг и проверка критичных обновлений.

— Audit & Compliance
Журналы, проверки и соответствие требованиям. Для российской инфраструктуры сюда можно отнести 152-ФЗ, 187-ФЗ, требования ФСТЭК/ФСБ и внутренние регламенты компании.

— Network Security
Защита сети. Межсетевые экраны, сегментация, IDS/IPS, защищённый DNS и контроль сетевых потоков между системами.

— Endpoint Security
Защита рабочих станций, ноутбуков и других конечных устройств. Антивирус, EDR, управление устройствами и шифрование дисков.

— Incident Response
Реагирование на инциденты. План действий при атаке, утечке, DDoS или компрометации учётной записи, а также регулярные тренировки команды.

— Container Security — безопасность самих контейнеров: доверенные реестры и образы, сканирование на уязвимости, минимальная база, запуск без root, контроль runtime.

— Kubernetes Security — безопасность кластера: RBAC, network policies, Pod Security Standards, защита control plane и etcd, управление секретами.

— API Security
Защита публичных и внутренних API. OAuth 2.0, API-ключи, rate limiting, валидация входных данных и контроль подозрительной активности.

— Third-Party Management
Работа с подрядчиками и внешними сервисами. Оценка поставщиков, безопасный обмен данными, контроль интеграций и внешних доступов.

— Disaster Recovery
Восстановление после сбоя или атаки. DR-план, резервное копирование, резервирование систем и регулярная проверка восстановления.

Такая карта хорошо показывает, что безопасность системы начинается ещё на этапе архитектуры. Чем раньше эти направления учтены в проектировании, тем меньше хаоса будет при эксплуатации, проверках и реальных инцидентах.

#полезное

💻 Probes в Kubernetes:
как кластер понимает, что под работает и готов принимать запросы

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

Для этого и существуют probes — проверки, по результатам которых kubelet принимает решения о перезапуске и направлении трафика.

➡️ Виды probe

— livenessProbe — контролирует работоспособность контейнера. При провале kubelet перезапускает контейнер. Применяется, когда приложение может «зависнуть» без падения процесса.
— readinessProbe — проверяет, готов ли контейнер принимать трафик. При провале под убирается из конечных точек сервиса, но не перезапускается. Используется для прогрева, ожидания зависимостей (БД, кеш).
— startupProbe — проверяет, успело ли приложение стартовать. Пока она не пройдена, liveness и readiness заморожены. Нужна для медленно стартующих приложений, чтобы их не убивало раньше времени.

➡️ Как работают?

Каждая probe выполняется одним из трёх способов:

— httpGet — HTTP-запрос на путь и порт, успех при коде 200–399
— tcpSocket — проверка, что порт открыт
— exec — выполнение команды внутри контейнера, успех при коде возврата 0

containers:
- name: app
  image: my-app
  startupProbe:
    httpGet:
      path: /healthz
      port: 8080
    failureThreshold: 30
    periodSeconds: 10
  livenessProbe:
    httpGet:
      path: /healthz
      port: 8080
    initialDelaySeconds: 0
    periodSeconds: 10
    failureThreshold: 3
  readinessProbe:
    httpGet:
      path: /ready
      port: 8080
    periodSeconds: 5
    failureThreshold: 2

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

— initialDelaySeconds — задержка перед первой проверкой
— periodSeconds — как часто выполнять проверку
— timeoutSeconds — таймаут одной проверки
— successThreshold — сколько успехов подряд считать восстановлением (для liveness/startup всегда 1)
— failureThreshold — сколько провалов подряд считать отказом

Пример со startupProbe выше даёт приложению до 30 × 10 = 300 секунд на запуск, после чего управление переходит к liveness.

Probes — это не формальность в манифесте, а контракт между приложением и кластером. Liveness помогает kubelet принять решение о перезапуске контейнера, readiness показывает, можно ли направлять на pod трафик, startup даёт приложению время на корректный запуск. Разделение этих ролей напрямую влияет на стабильность сервиса при деплоях и сбоях.

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

💪 Анатомия высоких нагрузок:
как строится отказоустойчивая инфраструктура

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

И на это есть разные причины.
Сервис может тормозить из-за нехватки ресурсов, длинных запросов к базе данных, слабой сетевой схемы, конкуренции бэкапов с рабочей нагрузкой или проблем с балансировкой.

Поэтому архитектуру нельзя считать только по количеству серверов, виртуальных машин и терабайт хранения.

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

👉 В новом материале разобрали, как строится инфраструктура под высокие нагрузки: от первого запроса и инженерного разбора до проектирования, тестирования, запуска и передачи в эксплуатацию.

#статья

🖥 logrotate — утилита для автоматической ротации, сжатия и удаления логов в Linux.

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

logrotate не работает постоянно в фоне.
Его запускает cron (/etc/cron.daily/logrotate) или systemd-таймер (logrotate.timer), обычно раз в сутки.

При запуске утилита читает конфиги, проверяет условия ротации и выполняет действия, если файл подходит под заданные правила.

➡️ Где лежат конфиги?

— /etc/logrotate.conf — основной файл с глобальными настройками.
— /etc/logrotate.d/ — каталог с отдельными конфигами для каждого сервиса (nginx, postgres и т.д.)

➡️ Пример конфига для приложения:

Допустим, нужно ротировать логи своего приложения в /var/log/myapp/.
Создаётся файл /etc/logrotate.d/myapp:

    daily
    rotate 14
    size 100M
    compress
    delaycompress
    missingok
    notifempty
    create 0640 myapp myapp
    sharedscripts
    postrotate
        systemctl reload myapp >/dev/null 2>&1 || true
    endscript
}

➡️Что задано:

— daily — проверять ротацию каждый день.
— rotate 14 — хранить 14 архивных копий.
— maxsize 100M — ротировать файл при проверке, если он превысил 100 МБ.
— compress — сжимать старые логи.
— delaycompress — сжимать файл на следующем цикле ротации.
— missingok — продолжать работу, если лог-файл отсутствует.
— notifempty — не ротировать пустой файл.
— create 0640 myapp myapp — создать новый лог-файл с нужными правами и владельцем.
— sharedscripts — выполнить postrotate один раз для всей группы файлов.
— postrotate ... endscript — выполнить команду после ротации.

➡️ Полезные команды

➡️ Проверить конфиг без изменений (dry-run):

logrotate -d /etc/logrotate.d/myapp 

➡️ Принудительно запустить ротацию, игнорируя расписание:

logrotate -f /etc/logrotate.conf 

➡️ Подробный вывод того, что происходит:

logrotate -v /etc/logrotate.conf 

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

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

⚠️ SLA на инфраструктуру

В этом договоре важны не общие обещания, а конкретные метрики, границы ответственности и последствия за нарушение.

Здесь важно не смешивать доступность сервиса с RTO, RPO, DR, бэкапами и поддержкой всего подряд.

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

Всё остальное — гостевые ОС, доступы, приложения, интеграции и изменения внутри контура — нужно отдельно фиксировать в договоре.

👉 В новом материале разобрали, что на самом деле измеряет SLA, чем отличаются модели сопровождения, почему изменения часто становятся причиной конфликтов и какие вопросы стоит задать подрядчику до аварии.

#статья

💻 kube-controller-manager: компонент, который следит за состоянием кластера

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

За это отвечает kube-controller-manager — компонент control plane, который запускает встроенные контроллеры и непрерывно сверяет желаемое состояние с фактическим.

Технически это единый бинарник, внутри которого крутятся десятки контроллеров. Они объединены в один процесс ради экономии ресурсов и упрощения эксплуатации, но логически независимы.

🔢 Контроллер — это бесконечный цикл согласования (reconciliation loop).

Его работа сводится к трём шагам:
— Наблюдение — через watch-механизм API-сервера контроллер получает события об изменении ресурсов.
— Сравнение — сопоставляет желаемое состояние (spec) с текущим (status).
— Действие — если есть расхождение, создаёт, удаляет или изменяет объекты, чтобы устранить разницу.

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

💬 Внутри kube-controller-manager работают:
— Deployment / ReplicaSet controller — поддерживает заданное число реплик. Именно он разворачивает ReplicaSet из Deployment, а тот создаёт поды.
— Node controller — следит за состоянием узлов. Если нода перестаёт слать heartbeat, помечает её NotReady и инициирует выселение подов.
— Job / CronJob controller — управляет жизненным циклом задач и их запуском по расписанию.
— EndpointSlice controller — связывает Service с подами, обновляя списки эндпоинтов при изменении состава подов.
— ServiceAccount & Token controller — создаёт сервис-аккаунты и связанные с ними секреты в новых namespace.
— Namespace controller — корректно удаляет все ресурсы внутри namespace при его удалении.

➡️ Пример: выполнение масштабирования

kubectl scale deployment nginx --replicas=5 

Дальше происходит цепочка:

➡️ kubectl отправляет запрос на kube-apiserver, тот записывает новое значение replicas=5 в etcd.
➡️Через watch событие об изменении Deployment получает kube-controller-manager.
➡️Deployment controller обновляет связанный ReplicaSet.
➡️ReplicaSet controller видит: желаемо 5 подов, фактически 3. Создаёт 2 новых пода через API-сервер.
➡️Новые поды попадают в очередь — их подхватывает kube-scheduler и назначает на ноды.
➡️kubelet на этих нодах запускает контейнеры и докладывает о статусе обратно в API.

Сам controller-manager при этом не запускает контейнеры и не назначает поды на ноды — он лишь приводит число объектов к нужному, а грязную работу делают scheduler и kubelet.

kube-controller-manager — это целый цех автономных регуляторов, каждый из которых отвечает за свой кусочек кластера.
Именно он превращает декларативный манифест в живую, самовосстанавливающуюся систему.

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

🛠 Поддержка инфраструктуры

«Поддержка 24/7» — чтобы понять, что это значит на самом деле, нужно заглянуть в договор.

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

Если этого нет, то круглосуточная поддержка остаётся общей формулировкой, а в момент аварии начинается ручное управление и поиск того, кто должен включаться в работу.

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

#статья

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

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

💸 Как ДИТу говорить с бизнесом на языке денег

TCO, RTO, RPO, SLA, MTTR сами по себе ничего не объясняют.

Как обосновать бюджет на инфраструктуру через влияние на продажи, логистику, клиентский сервис и другие критичные процессы.
Как перевести ИТ-метрики в деньги, узнать цену простоя, какие риски и последствия допустимы и почему бездействие тоже имеет свою цену.

😎 Смотрите в выпуске по ссылке на любой удобной платформе
▶️ Rutube
▶️ YouTube
▶️ VK Видео

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

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

🇷🇺 Импортозамещение VMware: куда и как переезжать в 2026 году

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

Разобрали в новом материале.

#статья

🤑 Как заработать с инфраструктуры больше?

Мы подняли партнёрское вознаграждение до 100% первого платежа клиента и гарантируем регулярный доход до 20% с дальнейших оплат.

Если назрела задача по VPS, облаку, бэкапам, каналам или чувствительным данным — можно дополнительно заработать в CORTEL : ребята подключатся, разберут задачу, подготовят решение, запустят инфраструктуру и будут поддерживать её 24/7, а вы получите регулярный дополнительный доход.

Выплаты не отменяются через год — вы продолжаете зарабатывать, пока клиент с нами. А сумма заработка не ограничена сверху 😊

📣 Полные условия и регистрация тут.

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

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

📝 Шпаргалка по 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.

➡️ Где что использовать

➡️ метрики — чтобы быстро увидеть состояние системы;
➡️ логи — чтобы разобрать конкретную ошибку;
➡️ трейсы — чтобы проследить путь запроса между сервисами.

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

#полезное

🖥 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-утилит экономит время.

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

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

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

⚙️ 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 в одну команду, которую легко засунуть в скрипт.

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

💻 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 закрывает базовый сценарий эластичности — реакцию на изменение нагрузки без ручного вмешательства. Для более тонких сценариев (масштабирование по внешним очередям, множественные метрики, кастомная логика) конфигурация расширяется, но принцип остаётся тем же: контроллер сравнивает текущее состояние с целевым и приводит систему к балансу.

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

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

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