CORTEL

💻 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, как отличить зрелую эксплуатацию от формальной техподдержки и какие вопросы задать подрядчику до подписания договора. #статья

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

⚠️ SLA на инфраструктуру В этом договоре важны не общие обещания, а конкретные метрики, границы ответственности и последствия за нарушение. Здесь важно не смешивать доступность сервиса с RTO, RPO, DR, бэкапами и поддержкой всего подряд. Подрядчик отвечает за тот слой, который проектирует, контролирует, мониторит и может менять по регламенту. Всё остальное — гостевые ОС, доступы, приложения, интеграции и изменения внутри контура — нужно отдельно фиксировать в договоре. 👉 В новом материале разобрали, что на самом деле измеряет SLA, чем отличаются модели сопровождения, почему изменения часто становятся причиной конфликтов и какие вопросы стоит задать подрядчику до аварии. #статья

🖥 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 уже настроен при установке сервисов. Но его правила стоит проверять: от них зависит, как долго хранятся логи, когда они сжимаются и сколько места занимают на диске. #линуксятина

💪 Анатомия высоких нагрузок: как строится отказоустойчивая инфраструктура 🔍 Обычно всё начинается с симптомов: сервисы проседают в пиковые часы, восстановление после сбоя занимает непредсказуемое время, новый продукт сложно запустить, а текущий контур уже не выдерживает рост. И на это есть разные причины. Сервис может тормозить из-за нехватки ресурсов, длинных запросов к базе данных, слабой сетевой схемы, конкуренции бэкапов с рабочей нагрузкой или проблем с балансировкой. Поэтому архитектуру нельзя считать только по количеству серверов, виртуальных машин и терабайт хранения. Нужно понимать профиль нагрузки, критичность сервисов, допустимый простой, потери данных, требования к безопасности и уровень эксплуатации после запуска. 👉 В новом материале разобрали, как строится инфраструктура под высокие нагрузки: от первого запроса и инженерного разбора до проектирования, тестирования, запуска и передачи в эксплуатацию. #статья

💻 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 даёт приложению время на корректный запуск. Разделение этих ролей напрямую влияет на стабильность сервиса при деплоях и сбоях. #заметкиИнженера

Приглашаем инженеров на DevOps Lab: ML in Production! Не планируйте ничего на 26 июня! Открыли регистрацию на закрытую встречу в Новосибирске, где DevOps-инженеры и технические руководители разберут, как выстроить безопасную инфраструктуру для ML-сервисов на практике. 🟡Что вас ждет? • инфраструктура инференса • безопасность ML-пайплайнов • наблюдаемость моделей в производственной среде • Кофе-брейк и возможность задать неудобные вопросы напрямую На DevOps Lab мы соберёмся небольшим кругом, чтобы послушать три практических доклада, обсудить кейсы и немного подебажить с коллегами из индустрии. Регистрируйтесь, количество билетов ограничено :) 📌 26 июня, 18:00 | г. Новосибирск, офис Никсис 📌 Регистрация: по ссылке #девопс #никсис #митап

📝 Шпаргалка по проектированию безопасных систем. Помогает быстро проверить, какие направления защиты нужно учесть при проектировании ИТ-системы: доступы, данные, сеть, 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-план, резервное копирование, резервирование систем и регулярная проверка восстановления. Такая карта хорошо показывает, что безопасность системы начинается ещё на этапе архитектуры. Чем раньше эти направления учтены в проектировании, тем меньше хаоса будет при эксплуатации, проверках и реальных инцидентах. #полезное

💰 Экономия на архитектуре, которая увеличивает TCO Самые дорогие ошибки в инфраструктуре часто выглядят как разумная экономия на старте. Обычно сокращают то, что кажется необязательным прямо сейчас: резервирование сети, запас по СХД, мониторинг, тесты восстановления, документацию и план масштабирования. А последствия появляются позже: — Сетевую схему приходится менять уже после запуска. — СХД не выдерживает реальный профиль нагрузки: растут задержки, проседают сервисы. — Проблемы с инфраструктурой становятся заметны по жалобам пользователей. — Бэкапы есть, но восстановление не проверялось — в момент инцидента это превращается в отдельный риск. Так экономия превращается в рост TCO. Потому что в стоимость инфраструктуры входят эксплуатация, риски, восстановление, масштабирование и цена будущих переделок. 👉 В новом материале разобрали, где компании чаще всего экономят при построении ИТ-инфраструктуры, как эти решения возвращаются дополнительными расходами и почему иногда «дешевле на старте» означает дороже в три раза. #статья