Kubernetes: архитектура и основы
Архитектура кластера, control plane, etcd, Pod как единица планирования, namespace и путь kubectl apply через цикл согласования.
11 вопросов
JuniorТеорияОчень частоЧто такое Pod и почему это наименьшая планируемая единица, а не отдельный контейнер?
Что такое Pod и почему это наименьшая планируемая единица, а не отдельный контейнер?
Pod — наименьшая единица, которую планирует Kubernetes: один или несколько контейнеров, делящих сетевой namespace, IP и тома, всегда на одном узле. Планируются именно Pod, а не отдельные контейнеры, чтобы sidecar делил localhost и цикл с приложением.
Типичные ошибки
- ✗Приравнивать Pod к ровно одному контейнеру, а не к одному и более, делящим namespace
- ✗Думать, что контейнеры Pod могут попасть на разные узлы, а не размещаться на одном
- ✗Считать, что каждый контейнер Pod получает свой IP, а не делит IP Pod
Уточняющие вопросы
- →Почему два контейнера одного Pod общаются через
localhost? - →Когда стоит поместить второй контейнер в Pod, а не в отдельный Pod?
JuniorТеорияОчень частоЧто такое Kubernetes и какую проблему он решает по сравнению с запуском контейнеров вручную?
Что такое Kubernetes и какую проблему он решает по сравнению с запуском контейнеров вручную?
Kubernetes — оркестратор контейнеров: вы описываете желаемое состояние нагрузок, а он непрерывно планирует, перезапускает, масштабирует и балансирует контейнеры по кластеру под него. Он автоматизирует размещение, самовосстановление и сеть, иначе делаемые вручную.
Типичные ошибки
- ✗Называть Kubernetes средой выполнения вроде Docker, а не оркестратором поверх неё
- ✗Думать, что он выполняет команды один раз, а не непрерывно сводит к желаемому состоянию
- ✗Считать, что он управляет одним хостом, а не кластером машин
Уточняющие вопросы
- →Что значит «желаемое состояние» и как Kubernetes держит фактическое состояние равным ему?
- →Чем Kubernetes отличается от простого запуска
docker runна нескольких серверах?
JuniorТеорияЧастоЧто такое namespace в Kubernetes и что он изолирует, а что нет?
Что такое namespace в Kubernetes и что он изолирует, а что нет?
namespace — логическая область, разбивающая объекты, так что имя уникально лишь внутри неё; к нему привязаны квоты и RBAC. Сам он не изолирует сеть или ядро — Pod из разных namespace достигают друг друга, пока не ограничит NetworkPolicy.
Типичные ошибки
- ✗Считать namespace сетевой границей или границей безопасности сам по себе
- ✗Думать, что трафик между namespace блокируется по умолчанию
- ✗Верить, что имена объектов уникальны глобально, а не в пределах namespace
Уточняющие вопросы
- →Как на деле остановить трафик между двумя namespace?
- →Какие объекты являются cluster-scoped и живут вне любого namespace?
JuniorТеорияЧастоОбъясните модель согласования в Kubernetes — желаемое состояние против фактического.
Объясните модель согласования в Kubernetes — желаемое состояние против фактического.
Желаемое состояние вы описываете в объектах api-server; контроллеры крутят непрерывные control loop: наблюдают фактическое, сравнивают с желаемым и закрывают разрыв. Level-triggered, поэтому упавший или удалённый Pod пересоздаётся сам, без команд.
Типичные ошибки
- ✗Описывать Kubernetes как императивные разовые команды, а не непрерывное согласование
- ✗Думать, что control loop срабатывает один раз (edge-triggered), а не работает постоянно
- ✗Верить, что упавший Pod надо пересоздавать вручную, а не что это делает контроллер
Уточняющие вопросы
- →Почему удаление Pod у Deployment ведёт к пересозданию, а удаление одиночного Pod — нет?
- →Что значит «level-triggered» по сравнению с «edge-triggered»?
MiddleТеорияЧастоНазовите компоненты control plane в Kubernetes и скажите, за что отвечает каждый.
Назовите компоненты control plane в Kubernetes и скажите, за что отвечает каждый.
api-server — единственная точка входа: все чтения и записи идут через него в etcd, хранилище состояния. scheduler назначает неразмещённые Pod на узлы, а controller-manager крутит циклы согласования, приводящие фактическое состояние к желаемому.
Типичные ошибки
- ✗Помещать kubelet или kube-proxy в control plane, а не на рабочие узлы
- ✗Менять местами роли scheduler (размещение) и controller-manager (согласование)
- ✗Забывать, что только api-server общается с etcd
Уточняющие вопросы
- →Почему по замыслу только api-server напрямую общается с etcd?
- →Что продолжает работать в кластере, если control plane ненадолго упал?
MiddleТеорияЧастоЧто работает на рабочем узле Kubernetes и за что отвечают kubelet, kube-proxy и container runtime?
Что работает на рабочем узле Kubernetes и за что отвечают kubelet, kube-proxy и container runtime?
kubelet — агент узла: он следит за api-server на предмет Pod своего узла и поручает runtime запускать и проверять их. Runtime (containerd, CRI-O) запускает контейнеры, а kube-proxy программирует маршрутизацию IP Service к нужным Pod.
Типичные ошибки
- ✗Думать, что Pod размещает kubelet, а не scheduler из control plane
- ✗Путать kube-proxy (маршрутизация Service) с container runtime (запуск контейнеров)
- ✗Считать, что рабочие узлы локально запускают etcd или api-server
Уточняющие вопросы
- →Откуда kubelet узнаёт, какие Pod он должен запускать?
- →Чем kube-proxy отличается в режимах iptables и IPVS?
MiddleТеорияИногдаПроследите от начала до конца, что происходит при запуске kubectl apply -f deploy.yaml.
Проследите от начала до конца, что происходит при запуске kubectl apply -f deploy.yaml.
kubectl отправляет манифест в api-server, тот валидирует его и пишет желаемое состояние в etcd. Контроллер Deployment создаёт ReplicaSet, а тот — Pod; scheduler назначает каждому Pod узел, чей kubelet тянет образы и запускает контейнеры.
Типичные ошибки
- ✗Думать, что kubectl общается с узлами или kubelet напрямую, а не только с api-server
- ✗Верить, что в etcd пишет scheduler или kubelet, а не только api-server
- ✗Пропускать ReplicaSet — считать, что Deployment создаёт Pod напрямую
Уточняющие вопросы
- →Чем
applyотличается отcreate, когда объект уже существует? - →На каком шаге на самом деле работает цикл согласования желаемого и фактического?
MiddleТеорияИногдаКакова роль etcd в Kubernetes и почему важно, что это единственный компонент с состоянием?
Какова роль etcd в Kubernetes и почему важно, что это единственный компонент с состоянием?
etcd — консистентное key-value хранилище кластера со всем желаемым и наблюдаемым состоянием. Как единственный stateful-компонент control plane, он позволяет остальным быть stateless; потеря etcd без бэкапа — потеря всего состояния кластера.
Типичные ошибки
- ✗Думать, что состояние кластера живёт на узлах, а не в etcd
- ✗Считать etcd одноразовым кешем, которому не нужен бэкап
- ✗Полагать, что несколько компонентов control plane держат каждый своё состояние
Уточняющие вопросы
- →Почему etcd разворачивают нечётным кластером из 3 или 5 участников?
- →Каков путь восстановления, если данные etcd повреждены?
MiddleТеорияИногдаЧто такое pause (infra) контейнер и почему он есть в каждом Pod?
Что такое pause (infra) контейнер и почему он есть в каждом Pod?
pause-контейнер — крошечный контейнер, запускаемый в Pod первым; он лишь держит открытыми общие namespace (network, IPC) этого Pod. Прикладные контейнеры входят в них, деля один IP и localhost, и перезапускаются, не отнимая у Pod сетевую идентичность.
Типичные ошибки
- ✗Думать, что pause-контейнер выполняет код приложения, а не просто держит namespace
- ✗Путать pause-контейнер с init-контейнером, который отрабатывает и выходит
- ✗Верить, что он тормозит или ставит на паузу прикладные контейнеры, как намекает имя
Уточняющие вопросы
- →Почему прикладной контейнер может упасть и перезапуститься без смены IP у Pod?
- →Чем pause-контейнер отличается от init-контейнера?
SeniorТеорияИногдаЧто такое static Pod, чем они отличаются от Pod, управляемых через API, и где они задаются?
Что такое static Pod, чем они отличаются от Pod, управляемых через API, и где они задаются?
static Pod запускает напрямую kubelet узла из файлов-манифестов в каталоге (/etc/kubernetes/manifests), а не api-server. kubelet перезапускает их и показывает read-only mirror Pod, но kubectl ими управлять не может. Так и поднимается сам control plane.
Типичные ошибки
- ✗Думать, что static Pod задаются в api или etcd, а не в локальных файлах-манифестах узла
- ✗Верить, что kubectl управляет static Pod, а не лишь видит его mirror-объект
- ✗Путать «static» с фиксированным IP, а не с локальным управлением через kubelet
Уточняющие вопросы
- →Как сам kube-apiserver запускается до того, как api-server существует?
- →Что произойдёт с mirror-объектом static Pod, если сделать
kubectl delete?
SeniorТеорияРедкоКак api-server остаётся единственным источником истины и что ломается, если etcd теряет кворум?
Как api-server остаётся единственным источником истины и что ломается, если etcd теряет кворум?
Все компоненты читают и пишут состояние только через api-server, единственного писателя в etcd, поэтому истина одна. etcd использует Raft и требует кворума для записи; при потере кворума он становится read-only — работающие Pod живут, но новое не сохранить.
Типичные ошибки
- ✗Думать, что компоненты читают состояние peer-to-peer, а не только через api-server
- ✗Верить, что потеря кворума etcd удаляет работающие Pod, а не блокирует новые записи
- ✗Полагать, что меньшинство участников etcd всё ещё может фиксировать записи
Уточняющие вопросы
- →Почему etcd из 3 участников переживает один сбой, а из 2 — ни одного?
- →Каково практическое восстановление, когда etcd из 3 узлов теряет два?
