Как устроен Kubernetes
Что проверяют
Понимаете ли вы декларативную модель и роль контроллеров, а не только знаете слова Pod и Deployment.
Как отвечать
Ключевая идея: вы описываете желаемое состояние в манифесте, а кластер непрерывно приводит к нему фактическое. Контроллер сравнивает то, что должно быть, с тем, что есть, и устраняет разницу. Отсюда самовосстановление: удалили под, контроллер создал новый.
Управляющий слой: kube-apiserver (единственная точка входа, всё идёт через него), etcd (хранилище состояния), scheduler (решает, на каком узле разместить под), controller-manager (те самые контроллеры).
На каждом узле: kubelet (запускает контейнеры и следит за ними), kube-proxy (сетевые правила), среда выполнения контейнеров (containerd).
Основные объекты: Pod (наименьшая единица, один или несколько контейнеров с общей сетью), Deployment (нужное число реплик и стратегия обновления), Service (стабильный адрес и балансировка по подам), Ingress (вход снаружи по домену и пути), ConfigMap и Secret (конфигурация), PersistentVolume (хранилище), HPA (автомасштабирование).
Что важно на практике: requests и limits определяют, куда планировщик поставит под и когда его убьют по памяти; readiness решает, слать ли трафик, liveness решает, перезапускать ли. Смешивать их нельзя, иначе под перезапускается вместо временного вывода из балансировки.
Где спотыкаются
Считают Pod аналогом контейнера.
Не задают requests и limits.
Используют одинаковые пробы для liveness и readiness.
Не могут объяснить, зачем нужен Service, если у пода есть адрес: адрес меняется при каждом пересоздании.