Как маршрутизировать на разные Redis и другие сервисы через один LoadBalancer по SNI TCP routing используя Gateway API

https://habr.com/ru/articles/987652/

#resources

📦 Что происходит после нажатия кнопки Power? Как загружается Linux?

Каждый день мы запускаем серверы, контейнеры и виртуальные машины.
Но что на самом деле происходит между нажатием кнопки Power и появлением логина? 🤔
Разберём путь по шагам.

⚡ 1. BIOS / UEFI
Первым запускается BIOS (или UEFI).
Он проверяет оборудование:
• память;
• процессор;
• диски;
• устройства.
После этого ищет загрузчик.

🚀 2. GRUB
Обычно это GRUB.
Его задача проста:
• найти ядро Linux;
• загрузить initramfs;
• передать управление ядру.

🐧 3. Ядро Linux
Ядро распаковывает себя в память и начинает инициализацию системы:
• загружает драйверы;
• монтирует initramfs как временную файловую систему;
• находит настоящий root-раздел;
• выполняет switch_root;
• освобождает временную файловую систему из памяти.

⚙️ 4. PID 1 - systemd
Теперь запускается первый процесс в системе.
У него всегда PID = 1.
Сегодня почти во всех современных дистрибутивах это systemd.

🔥 Чем systemd отличается от старого init?

Он не запускает сервисы по очереди.
Вместо этого строит граф зависимостей и поднимает всё, что возможно, параллельно.
Затем система достигает нужного состояния:
🖥 graphical.target - рабочий стол.
🖧 multi-user.target - серверный режим.

Что такое Unit?

Очень многие думают, что Unit = Service.
На самом деле service - лишь один из типов unit.
Unit - это любой объект, которым умеет управлять systemd.
Самые популярные:

🔹 Service - запускает процессы.
🔹 Socket - открывает порт ещё до запуска сервиса (socket activation).
🔹 Target - объединяет несколько unit в одну цель.
🔹 Timer - выполняет задачи по расписанию (аналог cron).
🔹 Mount - монтирует файловые системы.

Посмотреть состояние unit

systemctl status nginx.service

Увидите:
• состояние сервиса;
• PID процесса;
• последние записи журнала;
• причины возможных ошибок.

📌 Вот и весь путь:

Power → BIOS/UEFI → GRUB → Kernel → initramfs → switch_root → systemd → ваши сервисы.
Именно так Linux проходит путь от кнопки питания до работающего приложения.

#linux
#career

📦 ОТ 1 СЕРВЕРА ДО 1 000 000 ПОЛЬЗОВАТЕЛЕЙ

Как на практике масштабируется система?

Многие думают, что высоконагруженный проект сразу начинается с Kubernetes, микросервисов и десятков серверов.

На деле всё проще.

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

Разберём этот путь по шагам 👇

1️⃣ ОДИН СЕРВЕР

Приложение и база данных работают на одной машине.

Для первых тысяч пользователей этого часто достаточно.

Главное правило: не усложняй архитектуру раньше времени.

2️⃣ БАЗА ДАННЫХ НА ОТДЕЛЬНОМ СЕРВЕРЕ

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

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

Теперь приложение и БД можно масштабировать независимо.

3️⃣ LOAD BALANCER И НЕСКОЛЬКО APP-СЕРВЕРОВ

Одного экземпляра приложения становится недостаточно.

Перед несколькими серверами появляется балансировщик:

• Nginx
• HAProxy
• облачный Load Balancer

Он распределяет запросы по алгоритму round robin или least connections.

Но есть важный нюанс: приложение должно быть stateless.

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

Обычно сессии выносят в Redis или используют JWT.

4️⃣ READ-РЕПЛИКИ БАЗЫ ДАННЫХ

В большинстве приложений чтений намного больше, чем записей.

Поэтому основная база принимает запись, а реплики обслуживают чтение.

Это снижает нагрузку на основной сервер.

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

5️⃣ КЭШ ПЕРЕД БАЗОЙ

Следующее узкое место - повторяющиеся запросы.

Решение - Redis и схема cache-aside:

1. Проверяем кэш.
2. Если данных нет, идём в базу.
3. Сохраняем результат в Redis.

При высоком hit rate база почти перестаёт чувствовать нагрузку.

6️⃣ CDN ДЛЯ СТАТИКИ

Картинки, CSS, JavaScript и видео начинают раздаваться через CDN.

Пользователь получает контент с ближайшей точки присутствия.

Это уменьшает задержку и снимает нагрузку с основных серверов.

7️⃣ ГЕОРАСПРЕДЕЛЕНИЕ

Когда пользователи находятся в разных странах и регионах, одного дата-центра становится недостаточно.

Появляются:

• несколько дата-центров
• GeoDNS
• маршрутизация в ближайший регион

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

8️⃣ MESSAGE QUEUE

Когда сервисы напрямую зависят друг от друга, система становится хрупкой.

Поэтому между ними появляется очередь сообщений:

• Kafka
• RabbitMQ

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

9️⃣ ШАРДИНГ БАЗЫ

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

Например, по user_id.

Но здесь появляется celebrity problem.

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

Поэтому шардинг требует продуманного ключа распределения, consistent hashing и механизма решардинга.

💡 ГЛАВНОЕ

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

Сначала найди реальное узкое место:

• сервер не справляется
• база тормозит на чтении
• сессии рвутся при деплое
• один сервис блокирует остальные

И только потом добавляй следующий уровень сложности.

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

💬 Какой этап, по твоему мнению, самый сложный в реальных проектах?

Сохрани пост. Он пригодится перед собеседованием или при проектировании системы.

#library

📦 Root не может удалить свой же файл. И это абсолютно нормально.

Кажется, что root в Linux может всё.

Удалить любой файл.
Изменить любую настройку.
Остановить любой процесс.

Но есть один механизм, который способен сказать root простое:

❌ Operation not permitted.

Разберёмся почему.

🔍 Проверяем на практике

Создадим файл и попробуем удалить его от имени root:

sudo rm file.txt

Получим неожиданную ошибку:

rm: cannot remove 'file.txt': Operation not permitted

Почему?

Ведь это же root.

👀 Смотрим атрибуты файла

Выполняем:

lsattr file.txt

Получаем:

----i--------e-- file.txt

Буква i означает Immutable.

Именно она запрещает любые изменения файла.

Нельзя:

❌ удалить;
❌ переименовать;
❌ изменить содержимое;
❌ создать жёсткую ссылку.

Даже если вы работаете под root.

🤔 Но ведь root может всё?

Не совсем.

Большинство думает, что root обходит любые ограничения.

На самом деле это работает только с правами доступа.

Immutable вообще не относится к rwx.

Он находится уровнем ниже, на уровне файловой системы.

Ядро сначала проверяет атрибуты файла.

И только потом смотрит владельца и права.

💡 Запомнить очень просто

Права доступа (rwx) - это ключ от двери.

Immutable - это дверь, которую наглухо заварили.

Root способен открыть любую дверь.

Но если двери больше нет, открывать уже нечего.

🔓 Как снять Immutable?

Только root (или процесс с capability CAP_LINUX_IMMUTABLE) может убрать этот атрибут.

Достаточно выполнить:

sudo chattr -i file.txt

После этого файл снова можно удалить обычным:

rm file.txt

🔥 Где это используют в реальной жизни?

Immutable часто ставят на критически важные файлы:

• /etc/passwd
• /etc/shadow
• /etc/resolv.conf
• важные конфигурации приложений

Это дополнительная защита даже на случай, если кто-то уже получил root-доступ.

Есть и похожий атрибут append-only (a).

Такой файл можно только дополнять.

Изменить или удалить его нельзя.

Поэтому этот флаг часто используют для логов.

🎯 Это любят спрашивать на собеседованиях

Очень часто кандидат уверенно рассказывает про:

• chmod
• chown
• rwx
• ACL

Но после вопроса:

> Почему root не может удалить файл?

...начинается тишина.

А ответ оказывается в одном маленьком флаге.

💬 Полезно?

Напишите sudo в комментариях.

Разберём полностью chattr и lsattr: все атрибуты, реальные кейсы использования и вопросы, которые любят задавать на Linux / DevOps собеседованиях.

📦 Kubernetes Secret не зашифрован. Вот что нужно знать.

Название Secret создаёт ощущение, что Kubernetes надёжно хранит ваши пароли.

На самом деле по умолчанию это не шифрование.

Это обычный Base64.

Любой, у кого есть доступ к Secret, сможет получить пароль за несколько секунд.

Проверим.

🔍 Создаём Secret

kubectl create secret generic mypass \
  --from-literal=password=SuperSecret123

Теперь попробуем прочитать его.

kubectl get secret mypass \
-o jsonpath='{.data.password}' | base64 -d

Результат:

SuperSecret123

Пароль получен в открытом виде.

🤔 Почему так происходит?

Многие путают Base64 с шифрованием.

Но Base64 - это всего лишь кодировка.

Она не использует:

❌ ключ;

❌ алгоритм шифрования;

❌ секрет для расшифровки.

Она просто меняет представление тех же самых байтов.

Любой человек сможет выполнить:

base64 -d

...и получить исходное значение.

💡 Что хранится в etcd?

По умолчанию Kubernetes сохраняет Secret в etcd именно в таком виде.

Это означает, что любой, кто:

• имеет право выполнить kubectl get secret;

• получил доступ к API Kubernetes;

• имеет доступ к etcd;

сможет прочитать содержимое практически мгновенно.

Поэтому Secret ≠ Encryption.

🔥 Как защищают Secrets в production?

### 1️⃣ Encryption at Rest

Самый правильный способ.

Настраивается через EncryptionConfiguration на API Server.

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration

resources:
- resources:
  - secrets

  providers:
  - kms:
      apiVersion: v2
      name: aws-encryption
      endpoint: unix:///run/kmsplugin/socket.sock

  - identity: {}

Используются:

• AWS KMS

• Azure Key Vault

• Google Cloud KMS

• HashiCorp Vault

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

━━━━━━━━━━━━━━━━━━

### 2️⃣ RBAC

Не давайте всем подряд право выполнять:

kubectl get secrets

На практике большинство утечек происходит не через взлом etcd.

А потому, что слишком много пользователей имеют доступ к Secret.

Минимально необходимые права всегда безопаснее.

━━━━━━━━━━━━━━━━━━

### 3️⃣ External Secret Manager

Лучше вообще не хранить секреты в Kubernetes.

Для этого используют:

• External Secrets Operator

• AWS Secrets Manager

• HashiCorp Vault

• Azure Key Vault

В этом случае Kubernetes Secret становится всего лишь кэшем.

Настоящий источник данных остаётся во внешнем Secret Manager.

Там доступны:

✅ ротация секретов;

✅ аудит;

✅ контроль доступа.

━━━━━━━━━━━━━━━━━━

### 4️⃣ GitOps

Если секреты лежат в Git:

используйте

• SOPS

или

• Sealed Secrets.

Секреты шифруются до коммита.

Расшифровывает их уже контроллер внутри Kubernetes.

В репозитории никогда не хранится открытый пароль.

🔎 Как проверить, включено ли шифрование?

ETCDCTL_API=3 etcdctl get \
/registry/secrets/default/mypass | hexdump -C

Если увидите:

k8s:enc:kms

Значит всё хорошо.

Если увидите обычный Base64 - шифрование не включено.

🎯 Главное, что стоит запомнить

Kubernetes Secret - это не сейф.

Это контейнер для хранения чувствительных данных.

По умолчанию он защищён только механизмами доступа Kubernetes.

Если не включить Encryption at Rest и не настроить RBAC, ваши секреты могут оказаться гораздо доступнее, чем кажется.

💬 А вы уже включали EncryptionConfiguration в своих кластерах?

Или до сих пор храните Secrets "как есть"?

Пишите в комментариях 👇

📦 Все сетевые драйверы Docker за 10 минут

На собеседованиях по Docker почти всегда спрашивают:

❓ Чем bridge отличается от host?
❓ Когда нужен overlay?
❓ В чём разница macvlan и ipvlan?
❓ Почему контейнеры не видят друг друга по имени?

Если ответы путаются в голове - сохраняй этот roadmap.

## 1️⃣ Bridge (по умолчанию)

Самый популярный драйвер Docker.

При запуске контейнера Docker:

• создаёт виртуальный мост docker0;
• подключает контейнер через veth;
• выдаёт IP из собственной подсети;
• выпускает трафик наружу через NAT.

Проверить:

docker network ls

docker network inspect bridge

⚠️ Важно

Контейнеры в default bridge не умеют искать друг друга по имени.

Для этого нужен user-defined bridge.

Создать сеть:

docker network create my-net

Запустить контейнеры:

docker run -d --network my-net \
--name app1 nginx

docker run -d --network my-net \
--name app2 nginx

Теперь контейнер app2 сможет обратиться к app1 просто по имени.

Когда использовать:

✅ локальная разработка

✅ микросервисы

✅ большинство приложений


## 2️⃣ Host

Контейнер использует сетевой стек самого Linux-хоста.

Без NAT.

Без docker0.

Без port mapping.

Запуск:

docker run --network host nginx

Плюсы:

✅ максимальная производительность

✅ минимум сетевых накладных расходов

Минусы:

❌ нет сетевой изоляции

❌ контейнер использует порты хоста

❌ работает только на Linux

Когда использовать:

• monitoring agents

• node exporters

• сетевые утилиты


## 3️⃣ Overlay

Соединяет контейнеры между несколькими серверами.

Основа Docker Swarm.

Работает через VXLAN.

Создать сеть:

docker swarm init

docker network create \
-d overlay \
--attachable \
my-overlay

⚠️ Важно

VXLAN добавляет дополнительный заголовок.

Если MTU равен 1500, полезная нагрузка уменьшается примерно до 1450 байт.

Из-за этого иногда появляются "непонятные" таймауты между нодами.

Когда использовать:

✅ Docker Swarm

✅ несколько серверов


## 4️⃣ Macvlan

Контейнер становится полноценным устройством в локальной сети.

У него появляются:

✅ собственный MAC

✅ собственный IP

Для роутера он выглядит как отдельный компьютер.

Создание сети:

docker network create \
-d macvlan \
--subnet=192.168.1.0/24 \
--gateway=192.168.1.1 \
-o parent=eth0 \
macvlan_net

⚠️ Особенность

Linux-хост не может напрямую обращаться к своим macvlan-контейнерам.

⚠️ Большинство облаков блокируют macvlan из-за защиты от MAC Spoofing.

Когда использовать:

• Legacy-системы

• приложения, которым нужен настоящий IP в LAN


## 5️⃣ IPvlan

Очень похож на macvlan.

Но есть отличие.

Все контейнеры используют один MAC-адрес хоста.

При этом каждый получает собственный IP.

Создание сети:

docker network create \
-d ipvlan \
--subnet=192.168.1.0/24 \
--gateway=192.168.1.1 \
-o parent=eth0 \
my-ipvlan

Когда использовать:

✅ если на коммутаторе есть ограничение на количество MAC

✅ большие корпоративные сети


## 6️⃣ None

Максимально простой драйвер.

Контейнер получает только интерфейс:

lo

Проверить:

docker run \
--network none \
alpine ip addr

Никаких:

❌ Ethernet

❌ bridge

❌ NAT

❌ Интернета

Когда использовать:

• batch-задачи

• sandbox

• security-sensitive приложения

## 🚀 Что выбрать?

🟢 bridge

Обычные приложения.

🟢 host

Максимальная производительность.

🟢 overlay

Docker Swarm.

🟢 macvlan

Нужен настоящий IP в LAN.

🟢 ipvlan

Много контейнеров и ограничение по MAC.

🟢 none

Полная изоляция.


🎯 Что любят спрашивать на собеседовании?

❓ Почему default bridge не умеет DNS?

❓ Чем host быстрее bridge?

❓ Зачем overlay использует VXLAN?

❓ Почему host не видит macvlan?

❓ Чем macvlan отличается от ipvlan?

❓ Когда лучше использовать none?

Если можешь уверенно ответить на эти вопросы — Docker Networking уже вряд ли сможет тебя удивить на собеседовании.

💾 Сохрани этот roadmap.

Он пригодится и на практике, и перед следующим DevOps-интервью.

🌐 Модель OSI за 10 минут

На любом DevOps, SRE или Backend собеседовании рано или поздно спросят:

❓ Что происходит, когда ты открываешь сайт?

Правильный ответ почти всегда начинается с модели OSI.

Это не просто теория из университета.

Это удобная модель, которая помогает быстро понять, на каком уровне возникла проблема.

Разберём все 7 уровней на реальных примерах. 👇


## 1️⃣ Physical (Физический)

Самый нижний уровень.

Здесь ещё нет IP, TCP или HTTP.

Есть только передача битов по среде.

Работает:

• витая пара;
• оптика;
• Wi-Fi;
• разъёмы;
• сетевые карты.

Что проверять:

ip link

или

ethtool eth0

Типичные проблемы:

❌ оборван кабель;

❌ отключён порт;

❌ нет линка;

❌ плохой сигнал Wi-Fi.


## 2️⃣ Data Link (Канальный)

Здесь появляются MAC-адреса.

Передаются уже не биты, а Ethernet-кадры.

Именно здесь работает коммутатор.

Он смотрит только на MAC-адрес получателя.

IP ему вообще не интересен.

Посмотреть MAC:

ip link show

или

ip addr

Типичные устройства:

✅ Switch

Типичные проблемы:

❌ неправильный VLAN;

❌ MAC Flapping;

❌ STP Loop.


## 3️⃣ Network (Сетевой)

Здесь появляются IP-адреса.

Работают:

• IPv4;

• IPv6;

• маршрутизация;

• ICMP.

Именно здесь работает роутер.

Он выбирает маршрут до сети назначения.

Проверить маршрут:

ip route

Проверить доступность:

ping google.com

или

traceroute google.com

Типичные проблемы:

❌ нет маршрута;

❌ неправильный Gateway;

❌ ACL;

❌ Firewall.


## 4️⃣ Transport (Транспортный)

Здесь появляются:

• TCP;

• UDP;

• порты.

TCP умеет:

✅ подтверждать доставку;

✅ повторно отправлять потерянные пакеты;

✅ соблюдать порядок.

UDP ничего не гарантирует.

Зато работает быстрее.

Проверить соединение:

ss -tulpn

или

netstat -tulpn

Типичные проблемы:

❌ порт закрыт;

❌ Firewall блокирует TCP;

❌ потеря пакетов.


## 5️⃣ Session (Сеансовый)

Отвечает за создание и поддержку соединения между приложениями.

В современной сети редко существует как отдельный протокол.

Чаще его функции выполняют:

• TCP;

• RPC;

• SMB;

• SSH.

Проще говоря:

именно этот уровень отвечает за "разговор" двух приложений.


## 6️⃣ Presentation (Представления)

Этот уровень отвечает за то, как выглядят данные.

Именно здесь появляются:

🔐 TLS

🔐 SSL

🗜️ Сжатие

🔤 Кодировки

Например:

Когда открываешь HTTPS-сайт, именно здесь происходит TLS Handshake.

Проверить сертификат:

openssl s_client \
-connect google.com:443

Типичные проблемы:

❌ просроченный сертификат;

❌ неподдерживаемый TLS;

❌ ошибка шифрования.

## 7️⃣ Application (Прикладной)

Самый верхний уровень.

Именно с ним работают разработчики.

Здесь находятся:

🌍 HTTP

🌍 HTTPS

🌍 DNS

🌍 SSH

🌍 FTP

🌍 SMTP

🌍 MQTT

Например:

curl https://example.com

или

dig google.com

или

ssh user@server

Типичные проблемы:

❌ 404

❌ 500

❌ DNS не отвечает

❌ API недоступно


## 🚀 Что происходит, когда открывается сайт?

1️⃣ Кабель передаёт биты.

2️⃣ Ethernet доставляет кадр.

3️⃣ IP находит маршрут.

4️⃣ TCP устанавливает соединение.

5️⃣ Создаётся сессия.

6️⃣ TLS шифрует данные.

7️⃣ HTTP получает страницу сайта.

И всё это происходит буквально за доли секунды.


## ⚠️ А теперь самое важное

Интернет не работает по OSI.

Реальный стек называется TCP/IP.

В нём всё намного проще:

📍 Link

📍 Internet

📍 Transport

📍 Application

То есть уровни 5, 6 и 7 модели OSI объединены в один.

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


## 🎯 Что любят спрашивать на собеседовании?

❓ На каком уровне работает Switch?

❓ Где работает Router?

❓ Где находится TCP?

❓ Где появляется TLS?

❓ Почему DNS относят к 7 уровню?

❓ Чем OSI отличается от TCP/IP?

Если можешь ответить на эти вопросы без подготовки - сеть уже не станет проблемой на собеседовании.

#linux

Забавный факт.

Меня отправили в вечный мут в достаточно известном канале "DevOps - русскоговорящее сообщество". Никаких объяснений я так и не получил.
Самое интересное, что я ничего не продавал, не спамил и не провоцировал конфликты - наоборот, регулярно бесплатно помогал людям с вопросами и делился своим опытом.

Получилось довольно показательно.

Выводы каждый сделает сам. 🙂

📦 curl висит, а ping работает. Как найти проблему за минуту

Классическая ситуация:

ping example.com

отвечает, хост вроде живой.

А вот:

curl https://example.com

зависает или падает по таймауту.

Причина простая: ping и curl проверяют разные уровни сети.

Чтобы не гадать, проходи цепочку по шагам.

1️⃣ Проверяем сеть и DNS

ping example.com

ping показывает, резолвится ли имя и доступен ли хост по ICMP.

Но важно помнить:

• успешный ping не означает, что нужный порт открыт;
• отсутствие ответа не всегда означает, что сервер недоступен;
• ICMP может быть просто запрещён firewall.

Поэтому ping нужен только как первая быстрая проверка.

2️⃣ Проверяем TCP-порт

nc -zv example.com 443

Флаги:

-z  проверить порт без передачи данных
-v  показать подробный результат

Возможные ответы:

succeeded

TCP-соединение установлено, порт доступен.

Connection refused

Хост доступен, но на порту никто не слушает либо соединение активно отклоняется.

Operation timed out

Пакеты могут блокироваться firewall, Security Group, ACL или теряться по пути.

На сервере проверяем:

ss -tlnp | grep ':443'
systemctl status nginx

3️⃣ Проверяем TLS

openssl s_client \
  -connect example.com:443 \
  -servername example.com

-servername передаёт SNI. Без него сервер с несколькими доменами может вернуть чужой сертификат или вообще разорвать соединение.

Если TCP-порт открыт, но TLS не проходит, возможные причины:

• сертификат истёк;
• сертификат выпущен не на тот домен;
• не совпадают версии TLS или cipher suites;
• reverse proxy настроен неправильно;
• DPI или firewall вмешивается в TLS-трафик;
• сервер ожидает правильный SNI.

Проверить даты сертификата:

openssl s_client \
  -connect example.com:443 \
  -servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates

4️⃣ Проверяем HTTP и приложение

curl -v https://example.com

curl -v показывает всю цепочку:

• DNS resolution;
• подключение к IP;
• TCP connection;
• TLS handshake;
• отправленный HTTP-запрос;
• заголовки ответа;
• HTTP status code.

Чтобы диагностика не зависла надолго:

curl -v \
  --connect-timeout 3 \
  --max-time 10 \
  https://example.com

Если TLS прошёл, но приложение не отвечает, проверяем:

502  backend недоступен reverse proxy
503  сервис не готов или перегружен
504  upstream не ответил вовремя
404  запрос дошёл, но маршрут не найден
500  ошибка внутри приложения

🔍 Быстрая последовательность

DNS / ICMP
    ↓
ping

TCP-порт
    ↓
nc -zv

TLS
    ↓
openssl s_client

HTTP / приложение
    ↓
curl -v

💡 Главное правило

Не проверяй всю систему одной командой.

Каждый инструмент отвечает на свой вопрос:

ping              доступна ли сеть по ICMP
nc -zv            устанавливается ли TCP-соединение
openssl s_client  проходит ли TLS-handshake
curl -v           отвечает ли HTTP-приложение

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

Сохрани. На следующем инциденте эта последовательность сэкономит время и нервы.

#devops #linux

📦 Вот что реально могут спросить на собесе

Тема: PgBouncer и Connection Pooling

Пиши pgbouncer / postgres / pooling в комментариях, если работаешь с этим стеком 👇

---

## ⚡ Почему Postgres не любит тысячи соединений

Многие думают, что проблема решается увеличением:

max_connections = 1000

Но это почти никогда не правильное решение.

Каждое новое подключение к PostgreSQL — это отдельный процесс операционной системы, а не поток.

На каждое соединение тратятся:

• создание процесса (`fork()`);
• аутентификация;
• собственная память (обычно 5–10 МБ);
• переключение контекста процессора.

Получается примерно так:

1000 клиентов
        │
        ▼
1000 процессов PostgreSQL
        │
        ▼
CPU ↑
RAM ↑
Context Switch ↑

Сервер начинает тратить ресурсы не на выполнение SQL-запросов, а на обслуживание тысяч процессов.

---

## 🚕 Что делает PgBouncer

Представь службу такси.

Есть:

- 1000 пассажиров (подключений приложения);
- всего 20 машин (реальных соединений с Postgres).

Каждый пассажир думает, что машина принадлежит только ему.

Но после поездки машина сразу возвращается обратно и используется следующим клиентом.

Получается:

1000 клиентов
        │
        ▼
 PgBouncer
        │
        ▼
20 соединений
        │
        ▼
 PostgreSQL

Именно поэтому база перестаёт захлёбываться под нагрузкой.

---

## 🔀 Три режима работы PgBouncer

### 1️⃣ Session mode

Client
   │
Connection
   │
Postgres

Соединение закрепляется за клиентом на всю сессию.

✅ максимально совместим

❌ экономия соединений небольшая

---

### 2️⃣ Transaction mode ⭐

Client
   │
Transaction
   │
Pool
   │
Postgres

Соединение выдаётся только на время транзакции.

После COMMIT или ROLLBACK сразу возвращается обратно в пул.

✅ лучший режим для большинства production-систем

✅ максимальная экономия соединений

---

### 3️⃣ Statement mode

Каждый SQL-запрос
        │
получает новое соединение

После каждого запроса соединение сразу возвращается в пул.

Максимальная производительность.

Но есть серьёзное ограничение:

❌ транзакции работать не будут.

Используется крайне редко.

---

## 🪤 Любимая ловушка на собеседовании

Почему в Transaction Mode ломаются некоторые вещи?

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

Из-за этого возникают проблемы.

### Advisory Locks

Плохой вариант:

pg_advisory_lock(...)

Блокировка живёт на соединении.

Соединение ушло обратно в пул → логика ломается.

Используйте:

pg_advisory_xact_lock(...)

Он живёт внутри транзакции.

---

### LISTEN / NOTIFY

Подписка тоже существует только на конкретном соединении.

В Transaction Mode соединение постоянно меняется.

И уведомления перестают приходить.

---

### Prepared Statements

Раньше это тоже была большая проблема.

Начиная с PgBouncer 1.21+ появилась поддержка через:

max_prepared_statements

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

---

## ❓ Что чаще всего спрашивают

✅ Зачем нужен PgBouncer, если есть max_connections?

✅ Чем отличаются Session, Transaction и Statement Mode?

✅ Почему Transaction Mode ломает Advisory Locks?

✅ Почему LISTEN / NOTIFY плохо работает через PgBouncer?

✅ Как подобрать размер пула?

✅ Что выбрать:

- PgBouncer
- или встроенный connection pool приложения?

---

💡 Главное, что стоит запомнить

PostgreSQL плохо масштабируется количеством соединений.

Он отлично масштабируется количеством запросов.

Поэтому задача PgBouncer - не ускорить базу, а не дать ей умереть от тысяч подключений.

Сохрани пост - этот вопрос встречается практически на каждом собеседовании уровня Middle/Senior.

#postgres #pgbouncer #database #devops #sre #backend

📦 Вот что реально могут спросить на собесе

Тема: процесс завис в D-state

Пиши dstate / wchan / iostat в комментариях, если сталкивался с таким на проде 👇

---

## 🔴 Задача с собеседования

У тебя завис процесс.

В top или htop он находится в состоянии D (Uninterruptible Sleep).

CPU почти не используется, но iostat показывает высокую нагрузку на диск.

Что делать?

---

## ⚠️ Главное, что нужно знать

Большинство кандидатов первым делом делают:

kill -9 <PID>

И удивляются, что ничего не произошло.

Почему?

Потому что процесс в D-state находится внутри операции ввода-вывода (I/O).

Пока ядро не получит ответ от диска или сетевого хранилища, процесс невозможно завершить даже через SIGKILL.

Именно поэтому kill -9 здесь не работает.

---

## 🔍 Шаг 1. Найти процессы в D-state

ps aux | awk '$8=="D"{print $2,$11}'

# или

top -b -n1 | grep " D "

Если процессов несколько, начинаем с тех, которые находятся в D-state дольше всего.

---

## 🔍 Шаг 2. Посмотреть, чего именно ждёт процесс

Самый полезный файл:

cat /proc/<PID>/wchan

Примеры:

io_schedule

➡️ ожидание дисковой операции

nfs_wait

➡️ ожидание NFS

futex_wait_queue

➡️ ожидание блокировки

Если нужно увидеть полный стек ядра:

cat /proc/<PID>/stack

Там можно встретить:

submit_bio
ext4_file_write_iter
blk_mq_get_tag

Это уже позволяет понять, где именно зависла операция.

---

## 🔍 Шаг 3. Узнать, с чем работает процесс

Какие файлы открыты:

lsof -p <PID>

Только обычные файлы и блочные устройства:

lsof -p <PID> | grep -E "REG|BLK"

Если процесс ещё выполняет системные вызовы:

strace -p <PID> \
-e trace=read,write,pread64,pwrite64 -T

Флаг:

-T

показывает время выполнения каждого вызова.

---

## 🔍 Шаг 4. Проверить диск

Общая нагрузка:

iostat -x 1

I/O конкретного процесса:

iotop -p <PID>

Статистика процесса:

cat /proc/<PID>/io

Смотри:

- количество чтений;
- количество записей;
- объём данных;
- скорость роста счётчиков.

---

## 🔍 Шаг 5. Если проблема в NFS

Проверяем подключённые файловые системы:

mount | grep nfs

Статистика клиента:

nfsstat -c

И снова смотрим:

cat /proc/<PID>/wchan

Если видишь:

nfs4_wait_bit_killable

Практически наверняка процесс ждёт ответа от NFS-сервера.

---

## 🪤 Любимая ловушка на собеседовании

Можно ли убить процесс в D-state?

Ответ:

❌ Нет.

Пока операция ввода-вывода не завершится, ядро не обработает сигнал.

Обычно остаются только три варианта:

- дождаться завершения I/O;
- принудительно размонтировать проблемную файловую систему (если это возможно):

umount -f -l /mnt/storage

- либо перезагрузить сервер.

---

## ❓ Что чаще всего спрашивают

✅ Чем D-state отличается от Sleeping и Running?

✅ Почему kill -9 не работает?

✅ Что показывает /proc/<PID>/wchan?

✅ Как определить, диск это или NFS?

✅ Какие команды используешь для диагностики?

---

## 💡 Главное правило

Если процесс находится в D-state, почти всегда проблема не в самом процессе.

Проблема ниже:

- диск;
- RAID;
- SAN;
- NFS;
- iSCSI;
- файловая система;
- драйвер;
- блочное устройство.

Именно их нужно искать в первую очередь.

Сохрани пост — вопрос про D-state регулярно встречается на собеседованиях Middle и Senior DevOps/SRE.

#linux #devops #sre #troubleshooting #kernel #interview

📦 401, 403, 404, 500, 502, 503, 504...

Если ты DevOps, Backend или SRE, то эти коды ошибок видишь почти каждый день.

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

Разбираемся.

---

## 🟢 2xx — Всё хорошо

200 OK — запрос успешно выполнен.

201 Created — ресурс создан.

204 No Content — операция успешна, но сервер ничего не возвращает.

---

## 🟠 4xx — Ошибка клиента

### 400 Bad Request

Неверный запрос.

Например:

- битый JSON;
- отсутствует обязательное поле;
- неверный формат данных.

---

### 401 Unauthorized

Сервер не знает, кто ты.

Причины:

- нет JWT;
- токен просрочен;
- отсутствует авторизация.

Запомнить просто:

> Сначала представься.

---

### 403 Forbidden

Сервер знает пользователя, но не разрешает доступ.

Например:

user → /admin

↓

403 Forbidden

💡 Мнемоника:

401 — не знает.

403 — знает, но не пускает.

---

### 404 Not Found

Ресурс не найден.

---

### 405 Method Not Allowed

URL существует, но этот HTTP-метод запрещён.

---

### 409 Conflict

Конфликт данных.

Например, пользователь с таким email уже существует.

---

### 429 Too Many Requests

Сработал Rate Limit.

Часто встречается в:

- Nginx
- Cloudflare
- API Gateway
- Kubernetes Ingress

---

## 🔴 5xx — Ошибка сервера

### 500 Internal Server Error

Ошибка внутри приложения.

Ищем логи Backend.

---

### 502 Bad Gateway

Очень любят спрашивать на собеседованиях.

Схема:

Client
   │
Nginx
   │
Backend

Nginx смог подключиться к Backend.

Но получил некорректный ответ.

Поэтому вернул:

502 Bad Gateway

---

### 503 Service Unavailable

Сервис временно недоступен.

Причины:

- приложение выключено;
- deployment обновляется;
- maintenance;
- backend исключён из балансировки.

---

### 504 Gateway Timeout

Самая частая путаница с 502.

При 504 Backend вообще не успел ответить.

Причины:

- долгий SQL;
- блокировки;
- зависший API;
- перегруженный сервер.

---

## 💡 Как отличить 502 и 504

Очень простой способ.

Открой логи Backend.

👉 Есть запись о запросе?

Скорее всего 502.

👉 Запроса нет вообще?

Почти наверняка 504.

Тогда ищем:

- timeout;
- сеть;
- firewall;
- балансировщик;
- перегруженный upstream.

---

## 🧠 Шпаргалка

200 ✔ Всё хорошо

400 ❌ Неверный запрос

401 🔑 Не знает кто ты

403 🚫 Знает, но не пускает

404 🔍 Не найдено

405 ✋ Метод запрещён

409 ⚠ Конфликт

429 🚦 Слишком много запросов

500 💥 Ошибка приложения

502 🔄 Backend ответил неправильно

503 🛠 Сервис недоступен

504 ⏳ Backend не успел ответить

💬 Какой HTTP-код чаще всего встречается у тебя в работе?

#devops #backend #sre #nginx #http

🚨 GitLab CI может обманывать. И большинство узнаёт об этом только после падения продакшена.

Есть опасное заблуждение:

> Pipeline зелёный = релиз успешный.

К сожалению, это не так.

GitLab CI не знает, работает ли ваше приложение. Он знает только одно: все команды в Job завершились без ошибок.

И это две большие разницы.

---

## Самая распространённая ошибка

Вот обычный Job:

deploy:
  stage: deploy
  script:
    - kubectl apply -f deployment.yaml

Pipeline станет зелёным, если команда выполнится успешно.

Но что будет дальше?

Возможны десятки сценариев:

❌ Pod ушёл в CrashLoopBackOff

❌ Образ не скачался (`ImagePullBackOff`)

❌ Приложение не прошло Readiness Probe

❌ Контейнер стартует 5 минут

❌ Deployment завис во время rollout

GitLab этого не проверяет.

Он уже считает, что деплой успешен.

---

## Как делают новички

deploy:
  script:
    - kubectl apply -f app.yaml

Получают:

✔ Pipeline Passed

И спокойно идут пить кофе.

Через пять минут приходит сообщение:

> Прод не работает.

---

## Как делают в production

После деплоя всегда ждут завершения rollout.

deploy:
  stage: deploy
  script:
    - kubectl apply -f deployment.yaml
    - kubectl rollout status deployment/my-app --timeout=300s

Теперь GitLab дождётся, пока Kubernetes действительно обновит приложение.

Если хотя бы один Pod не сможет подняться, Job завершится ошибкой.

Именно этого обычно и ждут на production.

---

## Ещё несколько причин, почему Pipeline зелёный, а приложение не работает

### 1. allow_failure

tests:
  allow_failure: true

Тесты могут полностью упасть.

Pipeline всё равно останется зелёным.

Используйте только там, где падение действительно допустимо.

---

### 2. Ошибка скрыта

./deploy.sh || true

Или

set +e

Такие конструкции скрывают реальные ошибки.

GitLab считает, что всё прошло успешно.

---

### 3. Нет проверки готовности

Deployment создан.

Но приложение ещё не готово принимать трафик.

Если сразу завершить Job, пользователи могут получить ошибки, хотя Pipeline уже зелёный.

---

### 4. Используется старый образ

Очень частая проблема:

image: latest

или

kubectl set image ...

с тем же тегом.

Kubernetes может вообще не скачать новую версию.

Pipeline успешный.

Код старый.

---

### 5. Нет smoke-тестов

Deployment закончился.

Но никто не проверил:

curl https://service/health

Иногда один простой запрос после деплоя спасает больше, чем десятки тестов до него.

---

## Что чаще всего спрашивают на собеседовании

✅ Что означает зелёный Pipeline?

✅ Почему kubectl apply не гарантирует успешный релиз?

✅ Для чего нужен kubectl rollout status?

✅ Чем отличается успешный Job от успешного Deployment?

✅ Какие проверки должны выполняться после деплоя?

---

## 💡 Главное правило

GitLab CI проверяет команды.

Production проверяет результат.

Поэтому хороший pipeline заканчивается не на:

kubectl apply

А на проверке того, что приложение действительно работает:

kubectl rollout status deployment/my-app

или

kubectl wait \
--for=condition=Ready \
pod \
-l app=my-app

или хотя бы

curl https://service/health

Именно эти несколько строк отличают учебный pipeline от production-ready CI/CD.

💬 А какие проверки после деплоя используете вы? Только rollout status или ещё добавляете smoke-тесты и проверки health endpoint?

#gitlab #gitlabci #devops #kubernetes #cicd #sre #linux

🐳 Docker - 15 вопросов, которые реально спрашивают на собеседованиях

Если готовишься на DevOps, SRE или Backend - эти вопросы стоит знать без запинки.

В видео разобрал:

✅ Что такое образ и контейнер
✅ Dockerfile и слои образов
✅ CMD vs ENTRYPOINT
✅ COPY vs ADD
✅ bind mount, volume и tmpfs
✅ bridge, host и overlay сети
✅ Почему контейнер завершается сразу после запуска
✅ Разница между docker stop и docker kill
✅ Как уменьшить размер образа
✅ Multi-stage build
✅ Практические вопросы, которые действительно встречаются на собеседованиях

Без воды - только теория, практика и реальные вопросы.

🎬 Смотреть:
⁠https://www.youtube.com/watch?v=pOGJ0Tlt3P4

💬 А какой вопрос по Docker на собеседовании был самым неожиданным для вас?

#docker #devops #kubernetes #linux #backend #sre #собеседование #it #programming #dockerfile

🔥 Сохраняй, пригодится каждому, кто работает с Linux

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

Внутри:
• навигация по файловой системе;
• поиск файлов;
• права доступа;
• процессы;
• сеть;
• архивы;
• логи;
• диски;
• системная информация;
• полезные сочетания и лайфхаки.

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

💾 Сохрани, чтобы не искать команды каждый раз.

#linux #devops #sysadmin #backend #docker #kubernetes #terminal #cheatsheet #собеседование