92. Собеседование и резюме

Незнакомый термин? Откройте словарь Kubernetes и терминов курса.

Назначение, предварительные знания и результаты обучения

Нужны лабораторные работы и итоговый проект: эта глава переводит выполненную работу в точные объяснения, а не заученные лозунги.

После главы вы сможете:

• за 90 секунд объяснить ментальную модель Kubernetes;
• отвечать через механизм → последствие → доказательство → компромисс;
• решить задачу с YAML, диагностикой и проектированием системы в реальном времени;
• рассказать две STAR истории;
• написать пункты резюме, которые не выдают локальную лабораторию за промышленную эксплуатацию.

Ментальная модель хорошего ответа

Определение → механизм → эксплуатационное следствие → данные/команда → компромисс

Пример: «Проверка readiness показывает, можно ли направлять трафик. Kubelet обновляет condition Ready Pod, и EndpointSlice Service перестаёт считать endpoint готовым. Проверю condition Pod, Events и EndpointSlice. Readiness, слишком зависимая от внешних систем, может одновременно убрать все реплики».

Плохой ответ: «readiness проверяет, что Pod жив». Он смешивает readiness и liveness и не показывает причинность.

90-секундное представление

Адаптируйте только после выполнения:

Я Python-бэкенд-разработчик и закрыл пробел по Kubernetes практическим проектом: упаковал FastAPI-сервис, развернул его в kind с тремя узлами через Deployment и Service, добавил доставку конфигурации и секретов, проверки, корректный drain, запросы/лимиты ресурсов, HPA, PDB, SecurityContext restricted и RBAC с минимальными привилегиями. Я проверял не только успешный путь: расследовал Pending, CrashLoopBackOff, ImagePullBackOff, ошибки проверок, селектор, DNS, политику, OOM и PVC через Events, status, журналы и EndpointSlices. Доставка собрана наложениями Kustomize и имеет rollback и регламент. Я чётко различаю выполненную локальную лабораторию и пробелы промышленной эксплуатации: реальные CNI/CSI и внешний вход, телеметрию SLO, менеджер секретов и тренировку восстановления.

Если вы не выполнили действие, удалите его. «Изучил» не превращается в «эксплуатировал промышленный кластер».

Основные вопросы собеседования

Архитектура и API

1. Что делает Kubernetes декларативным? spec объекта хранит желаемое состояние; контроллеры циклически сравнивают его с наблюдаемым и выполняют согласование. Повторное применение идемпотентно по намерению.
2. YAML — источник истины? В GitOps источником служит Git или артефакт, в кластере авторитетным работающим объектом служат API и etcd, а процесс среды исполнения относится к наблюдаемому состоянию.
3. Кто создаёт Pod Deployment? Контроллер Deployment создаёт ReplicaSet, контроллер ReplicaSet — Pod; scheduler выбирает узел; kubelet запускает.
4. spec против status? Желаемые поля пользователя против полей, наблюдаемых контроллером. observedGeneration показывает обработанное generation.
5. Метки против аннотаций? Метки идентифицируют и выбирают, аннотации несут неидентифицирующие метаданные. Селектор — контракт идентичности.
6. Что при отказе сервера API? Новые записи, планирование и контроллеры могут остановиться; существующие Pods и плоскость данных узлов иногда продолжают обслуживать трафик.

Рабочие нагрузки и жизненный цикл

7. Pod против контейнера? Pod — единица планирования, сети, хранилища и общей судьбы; контейнеры делят сеть и жизненный цикл Pod.
8. Deployment против StatefulSet? Взаимозаменяемые реплики и rollout против стабильных порядкового номера, сети и идентичности PVC. StatefulSet не реализует кворум БД.
9. Job против Deployment? Выполнение до завершения и повторы против долгоживущего желаемого числа реплик.
10. Init-контейнер против сайдкара? Init-контейнер выполняет ограниченную работу до приложения; нативный сайдкар — перезапускаемый init-контейнер с restartPolicy: Always, работающий вместе с приложением.
11. CrashLoopBackOff — фаза? Нет, это причина ожидания и увеличивающейся задержки. Смотрю restartCount, lastState, код завершения и logs --previous.

Сеть и хранение данных

12. Зачем Service? Стабильная виртуальная идентичность выбирает временные готовые целевые Pods; EndpointSlices публикуют адреса.
13. Service есть, трафика нет? Проверяю селектор и EndpointSlice, readiness, порты, DNS и политику, прослушивание в Pod; иду по каждому переходу.
14. Ingress достаточно? Нет, ресурс требует контроллер и класс; Ingress API заморожен, Gateway API рекомендован для новых возможностей.
15. NetworkPolicy принята — значит работает? Нет, CNI должен её применять; проверяю разрешённый и запрещённый контрольные запросы.
16. RWO означает один Pod? Нет, монтирование на одном узле; RWOP ближе к одному Pod. Ни один режим не даёт блокировку и репликацию приложения.
17. Снимок равен резервной копии? Нет: нужны независимая область отказа, согласованность приложения, срок хранения и доказательство восстановления.

Здоровье, ресурсы и доступность

18. Readiness против liveness? Участие в трафике против перезапуска контейнера. Startup защищает медленный запуск от преждевременной liveness.
19. Запрос против лимита ресурсов? Резервирование и доля scheduler против верхней границы среды исполнения. CPU подвергается ограничению, память может вызвать завершение по OOM.
20. Почему HPA нужен запрос ресурсов? Утилизация CPU равна потреблению, делённому на запрос; запрос — знаменатель.
21. Что защищает PDB? Добровольные eviction, но не отказ узла, прямое удаление или OOM.
22. Как ломается rollout без простоя? Нет запаса maxSurge, новые Pods не Ready, приложение и схема несовместимы, внешний вход или соединения не дренируются.
23. Rollback Deployment откатывает БД? Нет; нужны расширение/сужение схемы и восстановление с учётом данных.

Безопасность и эксплуатация

24. Аутентификация/авторизация/admission? Кто → разрешена ли операция → допустимо ли содержимое объекта.
25. Почему Secret с base64 небезопасен? Кодировка обратима; защита строится на RBAC, KMS для хранимых данных, доставке, ротации и запрете журналирования.
26. Как доказать минимальные привилегии? Положительными и отрицательными auth can-i и фактическими проверками нагрузки, а не визуальным отсутствием шаблон *.
27. PSS restricted? Запуск без root и повышения привилегий, seccomp, удаление capabilities, безопасные тома и ограничения хоста; применяется через метки PSA namespace.
28. Совместимость версий? kubelet не новее сервера API и может быть до трёх версий старее; kubectl — ±1; промежуточные версии плоскости управления нельзя пропускать.
29. Резервная копия etcd содержит данные PVC? Нет, только объекты и состояние плоскости управления Kubernetes; данные приложения копируются отдельно.
30. Управляемый сервис означает отсутствие эксплуатации? Нет: рабочие нагрузки, узлы, дополнения, CNI/CSI, ёмкость, политики, резервные копии и обновления остаются разделённой ответственностью.

Задача по проектированию системы

Задача: «Разверните Python API с 500 RPS, PostgreSQL, 99,9%, безопасным rollout и двумя командами в кластере».

Ответ строится:

1. Уточнить SLI задержки и ошибок, регионы и зоны, RPO/RTO данных, форму запросов, всплески трафика, требования соответствия и доверие арендаторов.
2. Deployment минимум с тремя репликами по зонам, измеренные запросы ресурсов, проверки и льготный период, maxSurge rollout и PDB.
3. Service и контроллер Gateway/Ingress, TLS, ограничения частоты и тайм-ауты; NetworkPolicy.
4. Внешний управляемый PostgreSQL с несколькими зонами, бюджет пула, миграции расширение/сужение схемы, резервные копии и восстановление.
5. HPA по CPU и, возможно, пользовательской метрике RPS или очереди; autoscaler узлов autoscaler и запас; защита БД.
6. Namespace, RBAC, квота, PSS и default-deny; отдельный кластер для враждебных арендаторов.
7. Менеджер Secret и идентичность рабочей нагрузки, отсутствие широкого токена; digest и подпись образа.
8. Метрики, журналы, трассировки, пользовательские сигналы SLO, контрольный rollout и rollback.
9. Обновление, совместимость, владение дополнениями, стоимость и упражнения с отказами.

Компромисс называйте явно: maxUnavailable: 0 сохраняет доступность, но требует запаса ёмкости maxSurge; общий Gateway дешевле, но увеличивает радиус поражения.

Практика с манифестом в реальном времени

Полная безопасная базовая конфигурация:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: python-api-interview
  namespace: kube-course
  labels:
    app.kubernetes.io/name: python-api
    app.kubernetes.io/instance: interview
spec:
  replicas: 3
  strategy:
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: python-api
      app.kubernetes.io/instance: interview
  template:
    metadata:
      labels:
        app.kubernetes.io/name: python-api
        app.kubernetes.io/instance: interview
    spec:
      automountServiceAccountToken: false
      terminationGracePeriodSeconds: 30
      securityContext:
        runAsNonRoot: true
        runAsUser: 10001
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: api
          image: kube-python-course:1.0.0
          ports:
            - name: http
              containerPort: 8000
          readinessProbe:
            httpGet: {path: /health/ready, port: http}
            periodSeconds: 3
          livenessProbe:
            httpGet: {path: /health/live, port: http}
            periodSeconds: 10
          resources:
            requests: {cpu: 100m, memory: 128Mi}
            limits: {cpu: 500m, memory: 256Mi}
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop: ["ALL"]
          volumeMounts:
            - {name: tmp, mountPath: /tmp}
            - {name: data, mountPath: /data}
      volumes:
        - name: tmp
          emptyDir: {sizeLimit: 64Mi}
        - name: data
          emptyDir: {sizeLimit: 64Mi}

Объясните каждое поле через предотвращаемый отказ, а не словами «лучшая практика». Проверка:

kubectl apply --dry-run=client -f /tmp/interview.yaml
kubectl apply --dry-run=server -f /tmp/interview.yaml

Ожидается created в dry-run и код 0 при существующем namespace; образ не имеет значения для dry-run. Сервер не проверяет загрузку образа и среду исполнения.

Учебное собеседование

Запишите 30-минутное пробное собеседование:

• 2 минуты представления;
• 8 минут архитектуры и API;
• 8 минут диагностики Pending и пустого EndpointSlice;
• 8 минут проектной задачи;
• 4 минуты вопросов интервьюера.

Оцените каждый ответ от 0 до 2: правильный механизм, доказательство и компромисс. Перезапишите только ответы с оценкой ниже 2. Запрещена фраза «Kubernetes сам всё делает» без указания контроллера и condition.

Истории по STAR

Расследование отказа

• S — ситуация: управляемый сломанный rollout или инцидент, пользовательский симптом.
• T — задача: локализовать без разрушающего перезапуска.
• A — действие: Events → состояние и предыдущие журналы → EndpointSlice; гипотеза; точное исправление.
• R — результат: измеренное восстановление и проверка; предотвращение.

Улучшение надёжности и безопасности

• S — ситуация: один Pod без базовых ресурсов и безопасности.
• T — задача: сделать результат уровня job-ready.
• A — действие: Deployment, проверки, ресурсы, PDB, HPA, PSS, RBAC, Kustomize и регламент.
• R — результат: выполненные упражнения и объективные критерии.

Не придумывайте влияние на команду или бизнес. Результат локальной лаборатории так и называйте.

Пункты резюме

Используйте только после получения доказательств:

• «Собрал и проверил лабораторию kind с тремя узлами для FastAPI-сервиса с Deployment, Service, ссылками ConfigMap/Secret, проверками, контролем ресурсов, PDB, HPA, RBAC, Pod Security Restricted и наложениями Kustomize».
• «Диагностировал восемь видов отказов Kubernetes через Events, conditions, предыдущие журналы контейнеров, EndpointSlices, проверки авторизации и доказательства PVC; задокументировал регламенты восстановления и очистки».
• «Спроектировал ориентированное на эксплуатацию развёртывание с корректным завершением, rollback, моделью угроз, явным контрактом хранилища без состояния и проверочным списком обновлений и совместимости версий».

Если HPA, NetworkPolicy или PVC не были проверены в работающем кластере, замените «проверил» на «спроектировал» и назовите ограничение. Не пишите «промышленный Kubernetes» о kind.

Самостоятельная задача

Попросите коллегу дать одну случайную тему и один сломанный манифест. За 15 минут объясните механизм, предскажите status или Event, назовите первые три команды, найдите исправление и эксплуатационный компромисс. Критерий приёмки: ни один ответ не опирается на перезапуск первым действием или cluster-admin.

Упражнение со сломанным манифестом

apiVersion: v1
kind: Service
metadata:
  name: python-api-interview
  namespace: kube-course
spec:
  selector:
    app.kubernetes.io/name: python-ap1
    app.kubernetes.io/instance: interview
  ports:
    - name: http
      port: 80
      targetPort: web

Найдите две независимые ошибки: опечатку в имени селектора и targetPort: web, когда имя порта контейнера — http. Ожидается, что Service будет принят, а EndpointSlice сначала окажется пустым. После исправления селектора endpoints появятся, но соединение не установится из-за неразрешённого неверного именованного целевого порта. Доказательства:

kubectl get service,endpointslice -n kube-course
kubectl get pods -n kube-course --show-labels
kubectl describe service python-api-interview -n kube-course

Исправьте оба поля; проверьте порт 8000 в EndpointSlice и HTTP. Это показывает, почему первая найденная ошибка не гарантирует полного восстановления.

Дерево решений для ответа

Вопрос на собеседовании
├─ определение? → точная область, затем механизм
├─ «что происходит?» → последовательность контроллера/запроса/пути данных
├─ диагностика? → слой + три различающие команды для сбора данных
├─ проектирование? → требования/SLO → примитивы → зависимости → сбои/компромиссы
├─ безопасность? → угроза/идентификация/контроль/проверка/остаточный риск
└─ точная версия неизвестна? → обозначить неопределённость, проверить официальную документацию цели

Типичные ошибки: называть объекты без механизма; путать дополнение с ядром; приравнивать Running к здоровью; считать PDB защитой от отказа узла; считать base64 шифрованием; считать HPA масштабированием узлов; считать StatefulSet высокой доступностью БД; заявлять опыт промышленной эксплуатации; давать команды без контекста и namespace; не называть компромисс стоимости и безопасности.

Заметка об эксплуатации, безопасности и стоимости

Проектный ответ на собеседовании без безопасности и стоимости неполон, но простое перечисление инструментов тоже слабо. Связывайте причины: три реплики расходуют ёмкость; внешний LB, телеметрия и хранилище имеют постоянную стоимость; строгие PDB и admission могут блокировать обслуживание; общий кластер и внешний вход дешевле, но увеличивают радиус поражения; управляемая плоскость управления не снимает ответственность за рабочую нагрузку.

Самопроверка

1. Какой шаблон сильного ответа?
2. Можно ли назвать kind опытом промышленной эксплуатации?
3. Как доказать RBAC?
4. Что назвать при неизвестной текущей версии?
5. Почему пункт резюме должен различать «спроектировал» и «проверил»?

Ответы: 1) механизм → последствие → доказательство → компромисс; 2) нет; 3) положительный и отрицательный can-i и фактический запрос; 4) обозначить неопределённость и обратиться к официальной документации целевой версии, выпуску и правилам совместимости; 5) честность и воспроизводимая область.

Резюме и источники

Уверенность идёт из причинной модели и выполненных упражнений. Завершите проверочный список навыков.

• Концепции Kubernetes
• Справочник Kubernetes API
• Диагностика приложений
• Правила совместимости версий
• Проверочный список безопасности приложения