Контейнеры и Kubernetes
Контейнеры, Linux namespaces, cgroups, основы Kubernetes и процессная модель pod.
5 вопросов
JuniorТеорияЧастоЧто такое контейнер и чем он отличается от виртуальной машины?
Что такое контейнер и чем он отличается от виртуальной машины?
Контейнер — это виртуализация на уровне ОС: процесс, который разделяет ядро хоста, но получает изолированное представление через Linux namespaces и ограниченные ресурсы через cgroups. Виртуальная машина запускает полноценную гостевую ОС на виртуализированном железе, поэтому она намного тяжелее.
Типичные ошибки
- ✗Считать, что контейнер запускает собственное ядро — он разделяет ядро хоста
- ✗Думать, что контейнер — это только формат упаковки без изоляции во время выполнения
- ✗Полагать, что стоимость старта и накладные расходы контейнера и VM примерно равны
Уточняющие вопросы
- →Какие возможности ядра Linux делают изоляцию контейнеров возможной?
- →Почему контейнер может запускать только бинарники, собранные под ОС ядра хоста?
JuniorТеорияЧастоЧто делает Kubernetes, и что такое pod и Deployment?
Что делает Kubernetes, и что такое pod и Deployment?
Kubernetes — это оркестратор контейнеров: он размещает контейнеры на узлах и поддерживает их работу. Pod — наименьшая разворачиваемая единица: один или несколько контейнеров с общим network namespace и лимитами ресурсов через cgroups. Deployment управляет набором реплик и обновлениями.
Типичные ошибки
- ✗Думать, что pod — это всегда ровно один контейнер: он может содержать несколько с общим network namespace
- ✗Путать Deployment с pod — Deployment управляет репликами и плавающими обновлениями
- ✗Считать, что Kubernetes собирает образы контейнеров, а не размещает и запускает их
Уточняющие вопросы
- →Что добавляет Service поверх Deployment?
- →Как Deployment выполняет плавающее обновление без простоя?
MiddleТеорияЧастоЧто контролируют cgroups и как они ограничивают ресурсы контейнера?
Что контролируют cgroups и как они ограничивают ресурсы контейнера?
Cgroup ограничивает и учитывает CPU, память и I/O группы процессов. Лимит CPU урезает долю группы в планировщике; лимит памяти ограничивает резидентную память — его превышение запускает OOM killer внутри этого cgroup. Контейнеры отображают каждый лимит ресурсов в настройку cgroup.
Типичные ошибки
- ✗Путать cgroups с namespaces — cgroups ограничивают ресурсы, namespaces изолируют видимость
- ✗Думать, что превышение лимита памяти логируется, а не запускает OOM killer
- ✗Считать, что лимит CPU закрепляет ядра, а не урезает долю в планировщике
Уточняющие вопросы
- →Как CPU-cgroup урезает процесс, не отбирая у него ядра?
- →Почему процесс может быть убит OOM killer, когда у хоста ещё есть свободная память?
MiddleТеорияЧастоКак Linux namespaces обеспечивают изоляцию процессов для контейнера?
Как Linux namespaces обеспечивают изоляцию процессов для контейнера?
Каждый namespace изолирует один класс ресурсов ядра и даёт группе процессов собственное представление о нём. PID скрывает другие процессы, net даёт приватный сетевой стек, mnt — дерево файловой системы, UTS — собственный hostname, плюс IPC и user. Контейнер имеет свежий набор таких namespaces.
Типичные ошибки
- ✗Путать namespaces с cgroups — namespaces изолируют видимость, cgroups ограничивают ресурсы
- ✗Думать, что один namespace покрывает все ресурсы, а не по одному классу каждый
- ✗Считать, что изоляция namespace обеспечивается в userspace, а не ядром
Уточняющие вопросы
- →Что user namespace позволяет делать непривилегированному процессу?
- →Как заставить два контейнера разделять один network namespace?
SeniorТеорияИногдаКак процесс выглядит изнутри Kubernetes-pod, если смотреть через ps или top?
Как процесс выглядит изнутри Kubernetes-pod, если смотреть через ps или top?
Главный процесс контейнера — это PID 1 в собственном PID namespace. Будучи PID 1, он обязан реапить процессы-зомби и принимать сигналы — наивный бинарник часто не делает ни того, ни другого. ps и top внутри контейнера видят только процессы этого pod; хост видит те же процессы под другими PID.
Типичные ошибки
- ✗Забывать, что главный процесс контейнера — PID 1 и обязан реапить зомби и обрабатывать сигналы
- ✗Думать, что
psвнутри контейнера перечисляет процессы хоста — PID namespace их скрывает - ✗Считать, что процесс сохраняет один и тот же PID внутри контейнера и на хосте
Уточняющие вопросы
- →Почему отсутствие обработки SIGTERM в PID 1 приводит к медленному завершению pod?
- →Какую проблему решает минимальный init вроде
tiniв роли PID 1?
