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

В проде нужен веб-сервис из трёх одинаковых реплик. Почему не стоит создавать три Pod вручную и что в этой задаче даёт Deployment?

как ответить Pod — отдельный экземпляр приложения, а не контроллер желаемого состояния. Deployment через ReplicaSet поддерживает нужное число взаимозаменяемых Pod, создаёт замену при их потере и управляет постепенным обновлением шаблона. Поэтому в проде обычно описывают Deployment, а не набор Pod вручную.

Pod запущен, но Service не отправляет на него трафик. Что не так в манифестах и как ты проверишь гипотезу?

apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector:
    app: api
  ports:
    - port: 80
      targetPort: 8080
---
apiVersion: v1
kind: Pod
metadata:
  name: api-1
  labels:
    app: backend
spec:
  containers:
    - name: api
      image: example/api:1
      ports:
        - containerPort: 8080

как ответить Селектор Service ищет app: api, а у Pod стоит app: backend, поэтому контроллер не добавит его адрес в EndpointSlice. Я бы сравнил селектор и метки, затем посмотрел kubectl get endpointslice -l kubernetes.io/service-name=api. После исправления метки проверил бы readiness и соответствие targetPort порту, который действительно слушает приложение.

Чем readiness probe отличается от liveness probe и зачем отдельно нужна startup probe?

как ответить Readiness отвечает, можно ли сейчас направлять трафик в контейнер: при провале Pod исключают из обычного обслуживания через Service, но контейнер не перезапускают. Liveness ищет состояние, из которого нужен перезапуск контейнера. Startup probe защищает медленный старт: пока она не прошла, liveness и readiness не запускаются.

На дашборде узлы почти пусты, но Pod с такими resources остаётся Pending с Insufficient cpu. Почему scheduler не смотрит на текущую загрузку и какую роль играют requests и limits?

resources:
  requests:
    cpu: 250m
    memory: 256Mi
  limits:
    cpu: 500m
    memory: 512Mi

как ответить Scheduler сравнивает сумму requests с allocatable узла, а не с мгновенной загрузкой: для этого Pod ему нужны 250m CPU и 256 MiB памяти. Limit задаёт границу использования во время работы, но его уменьшение само по себе не освобождает планировочную ёмкость. Нужно проверить фактический манифест после admission, requests всех контейнеров и уже зарезервированные requests на узлах.

Что положишь в ConfigMap, а что в Secret? Почему Kubernetes Secret нельзя считать шифрованием секрета по умолчанию?

как ответить ConfigMap хранит несекретную конфигурацию, а Secret предназначен для паролей, токенов и ключей. Значения Secret обычно представлены в base64, но кодирование не даёт конфиденциальности; без отдельной настройки данные в etcd могут храниться незашифрованными. Нужны шифрование at rest, минимальный RBAC и ограничение того, какие контейнеры получают Secret.

Новый Deployment не завершает rollout. В каком порядке ты будешь искать причину и когда решишь откатываться?

kubectl rollout status deployment/api --timeout=2m
kubectl describe deployment/api
kubectl get rs,pods -l app=api -o wide

# Подставь имя Pod из нового ReplicaSet:
NEW_POD=api-newhash-abcde
kubectl describe pod "$NEW_POD"
kubectl logs "$NEW_POD" --all-containers
kubectl logs "$NEW_POD" --all-containers --previous
kubectl get events --sort-by=.metadata.creationTimestamp

как ответить Сначала смотрю состояние Deployment и его новый ReplicaSet, затем конкретные Pod: scheduling, pull образа, состояние контейнеров, probes, события и текущие либо предыдущие логи. Так отделяю ошибку манифеста от нехватки ресурсов и падения приложения. Откат оправдан, если новая ревизия ухудшает сервис и предыдущая совместима с уже выполненными изменениями, но сам progressDeadlineSeconds автоматический rollback не запускает.

Нужно запускать очистку один раз после релиза и отчёт каждый час. Когда возьмёшь Job, когда CronJob и почему обе задачи должны быть идемпотентными?

как ответить Job подходит для конечной задачи: контроллер добивается нужного числа успешных завершений. CronJob создаёт Job по расписанию и добавляет правила для пропущенных и пересекающихся запусков. Идемпотентность нужна потому, что при сбоях и гонках один логический запуск может фактически выполнить работу повторно.

Pod должен запускаться только на GPU-узлах, защищённых taint. Как совместить node affinity и toleration и почему одной toleration недостаточно?

как ответить Taint отталкивает Pod, а toleration лишь снимает этот запрет: она не притягивает workload к GPU-узлу. Нужна ещё обязательная node affinity или nodeSelector по доверенной метке GPU-пула. Scheduler проверит и остальные условия, поэтому такая пара разрешает и направляет размещение, но не гарантирует его при отсутствии ёмкости.

Pod работает с ServiceAccount diagnostics, но API отвечает Forbidden на чтение Pod, хотя Role и RoleBinding созданы. Как найдёшь ошибку в RBAC?

как ответить Сначала проверю фактическую identity — system:serviceaccount:<namespace>:diagnostics — и воспроизведу решение авторизатора через kubectl auth can-i. Затем сопоставлю verb, API group, resource или subresource и namespace запроса с правилами Role и областью RoleBinding. Частые причины — неверный namespace у subject, другой serviceAccountName, отсутствие отдельного pods/log или привязка не той роли.

Ingress создан, но публичный URL не отвечает. Как проходит HTTP-запрос до Pod и на каких участках ты будешь искать разрыв?

как ответить Ingress хранит HTTP(S)-правила, но сам по себе ничего не обслуживает: нужен ingress controller, который реализует выбранный IngressClass. Запрос проходит через внешний адрес контроллера, правило host/path, Service и его EndpointSlice к готовому Pod. Я проверяю эту цепочку по порядку, включая DNS, TLS, статус Ingress, controller logs, порты Service и endpoints.

При rolling update часть запросов обрывается на завершающихся Pod. Как спроектировать graceful shutdown и что Kubernetes делает при удалении Pod?

как ответить При удалении Pod получает deletion timestamp, EndpointSlice помечает его завершающимся, а kubelet начинает graceful termination. Весь preStop и обработка TERM должны уложиться в terminationGracePeriodSeconds, после чего процесс будет принудительно остановлен. Приложение само прекращает принимать новые запросы и завершает активные, потому что мгновенное исключение endpoint из всех слоёв балансировки не гарантировано.

Когда StatefulSet действительно нужен вместо Deployment и какие гарантии он не даёт базе данных?

как ответить StatefulSet нужен, когда репликам важны стабильные ordinal-имена, постоянная сетевая идентичность, связанный с каждой репликой том или упорядоченные операции. Он сохраняет идентичность Pod при пересоздании и обычно использует headless Service для DNS. Но StatefulSet не настраивает репликацию, кворум, backup или согласованность самой базы — это делает приложение либо оператор.