сеньорчикОткрыть в Telegram
← все вопросывопросы для собеседований · Kubernetes

Вопросы по Kubernetes на собеседовании DevOps

Для инженера эксплуатации Kubernetes это самый частый блок собеса, и спрашивают его глубже, чем разработчика. Спрашивают не команды kubectl, а понимание: почему под висит в Pending, чем провал liveness отличается от readiness, что произойдёт с нагрузкой, если ляжет управляющий слой.

67 вопросов в банке·10 подтем·ниже разбор 9

Что спрашивают

Из чего состоит тема

Так тема разложена в тренажёре: движок ведёт прогресс по каждой подтеме отдельно и возвращает те, где вы ошибаетесь.

Разборы подтем

Конспект по каждой: что это, как отвечать вслух, на чём валятся, плюс вопросы для самопроверки.

Примеры вопросов с разбором

  1. #dvo_k8s_arch1 / 9
    Почему единица запуска в Kubernetes — под, а не контейнер?
    A)Под нужен для отказоустойчивости: это две копии одного контейнера
    B)Группа контейнеров с общей сетью и томами
    C)Под — обёртка для образа, из которой оркестратор читает манифест
    D)Под задаёт версию приложения, а контейнер — конкретный процесс
    показать ответ и разбор
    +B)Группа контейнеров с общей сетью и томами

    // разбор: Под — минимальная планируемая единица: контейнеры внутри делят сетевой namespace (общий localhost и порты) и могут делить тома. Отсюда паттерны с sidecar: прокси, сборщик логов, init-контейнер рядом с приложением. Планировщик размещает под целиком на одну ноду, а масштабируют не контейнер внутри, а число подов.

  2. #dvo_k8s_config2 / 9
    Пароль положили в Secret вместо ConfigMap. Насколько он теперь защищён?
    A)Значение лишь закодировано base64
    B)Значение шифруется кластером, ключ хранится на control plane
    C)Значение шифруется на ноде и расшифровывается только приложением
    D)Значение хранится вне etcd, в отдельном защищённом хранилище
    показать ответ и разбор
    +A)Значение лишь закодировано base64

    // разбор: Secret отличается от ConfigMap не шифрованием, а обращением: кодирование base64, отдельный тип, монтирование в tmpfs, отсутствие вывода значений в описании объекта. Кто имеет право читать секреты в namespace, увидит содержимое одной командой. Реальная защита — ограничения RBAC, шифрование данных в etcd (EncryptionConfiguration) и вынос секретов во внешнее хранилище с подстановкой через оператор.

  3. #dvo_k8s_network3 / 9
    У каждого пода есть свой IP. Зачем тогда Service ClusterIP?
    A)Чтобы поды получили доступ в интернет через NAT
    B)Чтобы шифровать трафик между подами внутри кластера
    C)Чтобы ограничить, кто с кем может общаться в кластере
    D)Адреса подов эфемерны, а сервис даёт стабильные имя и адрес
    показать ответ и разбор
    +D)Адреса подов эфемерны, а сервис даёт стабильные имя и адрес

    // разбор: Под пересоздаётся при каждой выкатке и получает новый адрес — прибивать к нему клиентов нельзя. Service даёт постоянный виртуальный адрес и DNS-имя, а список живых бэкендов держит в EndpointSlice, обновляя его по readiness подов. Трафик разводит kube-proxy правилами на ноде. Ограничения доступа — задача NetworkPolicy, а не сервиса.

  4. #dvo_k8s_scheduling4 / 9
    Чем requests отличаются от limits при размещении пода?
    A)Планировщик считает requests, limits — рантайм
    B)Планировщик считает limits, requests нужны лишь для отчётности
    C)Оба параметра равнозначны: планировщик берёт их среднее
    D)requests задают минимум для автоскейлера, планировщик их не читает
    показать ответ и разбор
    +A)Планировщик считает requests, limits — рантайм

    // разбор: Планировщик ищет ноду, где сумма requests уже размещённых подов плюс запрос нового влезает в ёмкость. Limits в это не входят: они превращаются в ограничения cgroup и работают в рантайме — превышение памяти даёт OOM-kill, превышение CPU даёт троттлинг. Отсюда типовой перекос: маленькие requests и щедрые limits дают плотную упаковку и внезапную нехватку под нагрузкой.

  5. #dvo_k8s_workloads5 / 9
    Что берут для базы с диском на под: Deployment или StatefulSet?
    A)Deployment с томом: он умеет закреплять диск за репликой
    B)Deployment с реплика-сетом на одну реплику, иначе диск разъедется
    C)StatefulSet: стабильные имена подов и свой том у каждой реплики
    D)DaemonSet: так под с базой окажется на каждой ноде
    показать ответ и разбор
    +C)StatefulSet: стабильные имена подов и свой том у каждой реплики

    // разбор: У Deployment поды одноразовые и взаимозаменяемые: имя случайное, том общий или отсутствует. StatefulSet даёт устойчивую идентичность — имена вида db-0, db-1, отдельный PVC на каждую реплику через volumeClaimTemplates, предсказуемый порядок запуска и остановки. Именно это нужно базам, брокерам и всему, что хранит состояние на диске.

  6. #dvo_k8s_probes6 / 9
    Чем liveness-проба отличается от readiness по последствиям?
    A)Liveness перезапускает, readiness убирает из сервиса
    B)Провал liveness убирает под из балансировки, readiness перезапускает контейнер
    C)Обе перезапускают контейнер, readiness просто ждёт дольше
    D)Обе только помечают под, а решение принимает контроллер деплоя
    показать ответ и разбор
    +A)Liveness перезапускает, readiness убирает из сервиса

    // разбор: Liveness отвечает на вопрос «жив ли процесс»: провал — рестарт контейнера. Readiness отвечает «готов ли принимать трафик»: провал — под исчезает из EndpointSlice сервиса, но продолжает работать. Отсюда разное наполнение: в liveness — дешёвая проверка самого процесса, в readiness — готовность зависимостей, прогретый кэш, открытые пулы.

  7. #dvo_k8s_rbac7 / 9
    Чем Role отличается от ClusterRole?
    A)Role описывает права людей, ClusterRole — права сервисных аккаунтов
    B)Role работает на чтение, ClusterRole разрешает и запись
    C)Role действует в своём namespace, ClusterRole — на весь кластер
    D)Role назначается напрямую, ClusterRole — только через группы
    показать ответ и разбор
    +C)Role действует в своём namespace, ClusterRole — на весь кластер

    // разбор: Role живёт в namespace и раздаёт права на объекты внутри него. ClusterRole описывает права на уровне кластера и на объекты вне namespace — ноды, PV, сами namespace. При этом ClusterRole можно связать RoleBinding'ом внутри одного namespace: удобный приём, когда набор прав общий, а область применения узкая.

  8. #dvo_k8s_resources8 / 9
    Контейнер упёрся в свои limits по памяти и по CPU. Что произойдёт в каждом случае?
    A)И там, и там контейнер перезапустится
    B)И там, и там процесс просто замедлится
    C)По памяти — троттлинг, по CPU — убийство процесса
    D)По памяти — OOM-kill, по CPU — троттлинг
    показать ответ и разбор
    +D)По памяти — OOM-kill, по CPU — троттлинг

    // разбор: Память неэластична: выделить сверх лимита нельзя, поэтому ядро убивает процесс — контейнер получает статус OOMKilled и рестарт по политике. CPU эластичен: превышение квоты не убивает, а притормаживает — планировщик ядра не даёт задаче ресурс до конца текущего периода. Отсюда разные симптомы: рестарты против выросших задержек при нормальной загрузке.

  9. #dvo_k8s_scaling9 / 9
    HPA настроен на целевые 70% CPU. Процент считается от чего?
    A)От физической ёмкости ноды, где размещён под
    B)От суммы requests контейнеров пода
    C)От лимита CPU, заданного в манифесте
    D)От пикового потребления за прошлый час
    показать ответ и разбор
    +B)От суммы requests контейнеров пода

    // разбор: Целевая утилизация в HPA считается как отношение фактического потребления к сумме requests пода: 70% при запросе 500m означает 350m. Отсюда практическое следствие: без заданных requests метрика не считается и автоскейлер не работает. И второе: изменив requests, вы автоматически меняете точку срабатывания HPA, даже если формально его не трогали.

это 9 из 67

Ещё 58 вопросов по теме — в тренажёре, с движком повторения

Прочитать разбор и ответить самому — разные навыки. В Сеньорчике вопросы идут сессиями, а движок возвращает подтемы, где вы ошибаетесь, пока они не начнут отскакивать. Бесплатно, лимит по энергии.

Открыть тренажёрДругие темы

Частые вопросы

куда дальше