Подготовка к собеседованию — DevOps-инженер

Короткий ответ: OSI — это эталонная (теоретическая) модель, разбивающая сетевое взаимодействие на 7 уровней, где каждый уровень предоставляет услуги вышестоящему и пользуется услугами нижестоящего. На практике используется реже, чем TCP/IP, но удобна для обсуждения и диагностики.

Подробно:

Уровни снизу вверх (мнемоника: «Please Do Not Throw Sausage Pizza Away»):

№	Уровень	Что делает	Единица данных	Примеры
7	Application (Прикладной)	Взаимодействие с приложением	Data	HTTP, DNS, FTP, SMTP
6	Presentation (Представления)	Кодирование, шифрование, сжатие	Data	TLS, JPEG, ASCII
5	Session (Сеансовый)	Установка/управление сессией	Data	sockets, RPC
4	Transport (Транспортный)	Доставка между процессами, порты	Segment (TCP)/Datagram (UDP)	TCP, UDP
3	Network (Сетевой)	Логическая адресация, маршрутизация	Packet	IP, ICMP
2	Data Link (Канальный)	Передача в пределах сегмента сети, MAC	Frame	Ethernet, Wi-Fi, ARP
1	Physical (Физический)	Биты по среде передачи	Bit	кабели, радио, оптика

Каждый уровень при отправке добавляет свой заголовок (инкапсуляция), при получении — снимает его (декапсуляция). Например, HTTP-данные оборачиваются в TCP-сегмент, тот — в IP-пакет, тот — в Ethernet-кадр.

Схема инкапсуляции:

[ Ethernet [ IP [ TCP [ HTTP-данные ] ] ] ]
   L2        L3   L4      L7

⚠️ Ловушка: TLS/шифрование часто относят к уровню 6 (Presentation) в OSI, но в реальной модели TCP/IP его помещают между транспортом и приложением. Не путайте «теоретический» уровень с практикой. Также MAC-адрес — это L2, а IP-адрес — L3; их часто смешивают.

Короткий ответ: Почти наверняка нет. Linux сознательно занимает «лишнюю» память под page cache — она отдаётся приложениям мгновенно. Смотреть надо на колонку available, а не free; о реальном дефиците говорят swap-in и major page faults.

Подробно:

Метрика	Что означает	Тревожиться?
free	память, не занятая вообще ничем	нет — у здорового сервера близка к нулю
buff/cache	page cache: кэш файлов и блоков	нет — вытесняется по требованию
available	сколько реально можно выдать без свопа	да, если стабильно стремится к нулю

1. Пустая память — потерянная память — ядро кэширует диск, чтобы повторные чтения шли из RAM, а не с устройства.
2. Реальные признаки дефицита — растущий si в vmstat 1 (swap-in), major page faults, срабатывания OOM-killer в dmesg.

free -h       # смотрим available, не free
vmstat 1 5    # колонки si/so — идёт ли активный своппинг

⚠️ Частая ошибка: «свободной памяти нет — перезагрузим» или сброс кэша через drop_caches. Page cache — это фича: очистка только замедлит систему до повторного прогрева.

Короткий ответ: L4-балансировщик видит только IP и порт — раскидывает TCP/UDP-потоки, быстрый и дешёвый, но для него протокол непрозрачен. L7 разбирает HTTP: маршрутизация по пути и заголовкам, ретраи, терминация TLS, sticky-сессии — ценой CPU на парсинг.

Подробно:

	L4	L7
Видит	IP:порт, SYN	метод, путь, заголовки, куки
Маршрутизация	round-robin/хэш по потокам	/api → один пул, /static → другой
Ретраи и таймауты	нет — не знает, где кончается запрос	per-request ретраи, circuit breaking
TLS	пропускает насквозь (passthrough)	терминация, X-Forwarded-For
Цена	почти нулевая, миллионы pps	парсинг HTTP: CPU и латентность

Примеры: L4 — IPVS, AWS NLB; L7 — nginx, Envoy, AWS ALB. Частый каскад: L4 снаружи → L7 внутри.

⚠️ Частая ошибка: ждать от L4 ретраев и маршрутизации по пути — он не видит HTTP и в принципе не знает, где закончился один запрос и начался следующий.

Короткий ответ: Контейнер — это обычный процесс Linux, которому ядро подсунуло изолированный «вид» системы: неймспейсы прячут чужое, cgroups ограничивают ресурсы, слоёная файловая система даёт свой rootfs. Гостевого ядра нет — ядро одно на всех, и в этом настоящая разница с VM.

Подробно:

1. Namespaces — изоляция видимости: каждый тип прячет свой кусок системы.
2. cgroups — лимиты CPU, памяти, IO: сколько процессу можно, а не что он видит.
3. Слоёный rootfs (overlayfs) — собственная файловая система поверх общих read-only слоёв образа.

Неймспейс	Что изолирует
pid	дерево процессов: внутри свой PID 1
net	сетевой стек: интерфейсы, маршруты, свои порты
mnt	точки монтирования, свой rootfs
uts	hostname и domainname
ipc	System V IPC, POSIX-очереди
user	маппинг UID/GID: root внутри ≠ root снаружи
cgroup	видимую иерархию cgroups

⚠️ Частая ошибка: «контейнер — это лёгкая VM». У VM гипервизор и своё гостевое ядро; контейнер делит ядро хоста — поэтому стартует за миллисекунды, но изоляция слабее: уязвимость ядра пробивает все контейнеры сразу.

Короткий ответ: kubectl валидирует манифест и отправляет его в API server: authn → RBAC → admission-вебхуки → запись в etcd. На этом синхронная часть заканчивается — дальше контроллеры, scheduler и kubelet асинхронно замечают изменения через watch и приводят кластер к желаемому состоянию. Никто ничего не «пушит».

Подробно:

1. API server — аутентификация, авторизация (RBAC), admission (mutating → validating вебхуки), объект сохранён в etcd.
2. Deployment-контроллер — видит новый Deployment (watch) и создаёт ReplicaSet.
3. ReplicaSet-контроллер — создаёт Pod-объекты, пока без ноды.
4. Scheduler — находит поды с пустым nodeName, фильтрует и скорит ноды, делает bind.
5. kubelet — на выбранной ноде видит «свой» под: тянет образы, запускает контейнеры через CRI, сеть поднимает CNI-плагин.
6. Readiness — проба прошла → под попадает в EndpointSlice и получает трафик.

kubectl ──► API server (authn → RBAC → admission) ──► etcd
              ▲ watch      ▲ watch       ▲ watch      ▲ watch
  deploy-ctrl → RS    rs-ctrl → Pods   scheduler → bind   kubelet → CRI/CNI

⚠️ Частая ошибка: «API server шедулит под и запускает контейнеры». Он только хранит и раздаёт состояние — всю работу делают независимые контроллеры по модели watch/reconcile.