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

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

⚠️ Частая ошибка: «контейнер — это лёгкая 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.

Короткий ответ: Continuous deployment реален только при trunk-based + фиче-флаги: маленькие батчи, ветки живут часы, main всегда выкатываем. GitFlow с долгоживущими develop/release-ветками — большие батчи и merge-ад; его место — коробочный софт с версиями.

Подробно:

1. Флаги разделяют deploy и release — код едет в прод выключенным; включение — это конфиг, а не выкатка. Это снимает страх мержить незавершённое в main.
2. Аргумент — размер батча, а не вкус: чем дольше живёт ветка, тем больше конфликтов, длиннее lead time и страшнее откат — DORA-метрики ровно об этом.

⚠️ Частая ошибка: отвечать «кому что удобнее». Это не вопрос вкуса: долгие ветки → большие батчи → длинный lead time — аргумент измеримый.

Короткий ответ: С локом второй apply заблокируется или упадёт с ошибкой «Error acquiring the state lock» — стейт залочен первым. Без лока — гонка: оба читают одну версию стейта и перетирают записи друг друга, стейт становится неконсистентным.

Подробно:

с локом:    A: apply ──► lock OK ──► работает ──► unlock
            B: apply ──► Error acquiring the state lock ✗

без лока:   A: read state v1 ──► write v2a ─┐
            B: read state v1 ──► write v2b ─┴─► кто записал
                                                последним, тот и «прав»

1. Последствия гонки — потерянные записи: ресурс создан в облаке, но его нет в стейте (сирота), или стейт бит и его чинят руками через state rm/import.
2. Механика — backend берёт лок на время операции (для S3 — таблица DynamoDB), force-unlock только для зависших локов.
3. Правильный ответ целиком — apply выполняет только CI-пайплайн, последовательно; люди локально запускают plan.

⚠️ Частая ошибка: считать лок опциональной мелочью «для больших команд» — достаточно одного пересечения apply, чтобы потом разгребать стейт руками.