Курс · RU93-skill-checklist.md

93. Проверочный список навыков и итоговый практический экзамен

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

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

Это не список «знаю термин». Ставьте [x], только если выполнили команду, сохранили нечувствительные доказательства и объяснили наблюдаемое поведение. Нужны все главы и итоговый проект.

После проверочного списка у вас будет:

проверяемая матрица навык → команда → доказательство → объяснение;
90-минутный практический экзамен;
список пробелов промышленной эксплуатации, которые локальный kind не может закрыть;
объективное решение: повторить основы, перейти к job-ready или к треку промышленной эксплуатации.

Требования к доказательствам

Для каждого пункта запишите:

Дата/версия кластера/контекст:
Команда(ы) и код выхода:
Наблюдаемый инвариант (без скопированного ожидаемого вывода):
Почему это произошло (контроллер/путь данных):
Сбой/восстановление:
Ограничение:

Не прикладывайте kubeconfig, токены, данные Secret или непроверенный пакет поддержки. Снимок экрана без команды, объекта и версии слабее текстового доказательства.

1. Окружение и модель API

Я проверил ОС, CPU, RAM, диск, cgroup и сервер провайдера контейнеров.
Я проверил контрольную сумму закреплённых исполняемых файлов kubectl и kind.
Я создал и удалил конкретный kube-course, не изменив чужой кластер.
Я могу объяснить путь kubectl → сервер API → etcd/контроллер.
Я показал spec.replicas, status.readyReplicas, generation и observedGeneration.
Я доказал цепочку владения Deployment → ReplicaSet → Pod.
Я удалил управляемый Pod и назвал контроллер, создавший замену.
Я отличаю метку, селектор, аннотацию, namespace и ownerReference.

Команды для доказательств:

kubectl version
kubectl get deployment python-api -n kube-course -o yaml
kubectl get rs,pod -n kube-course \
  -l app.kubernetes.io/instance=course -o jsonpath=...

Критерий: объяснить, почему повторное применение не удваивает число реплик.

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

Я запускал отдельный Pod и видел, что после удаления он не заменяется.
Я запускал Deployment и просматривал историю rollout.
Я получил текущее и предыдущее состояние контейнера и restartCount.
Я выполнил Job до Complete и объяснил повторы и идемпотентность.
Я показал порядок и отказ init-контейнера.
Я объясняю нативный сайдкар со стабильным статусом с v1.33 и эфемерный контейнер со стабильным статусом с v1.25.
Я выбираю Deployment, StatefulSet, DaemonSet или Job по контракту.
Я не называю StatefulSet высокой доступностью базы данных.

Критерий: для новой рабочей нагрузки за две минуты выбрать контроллер и назвать два вида отказа.

3. Конфигурация и секреты

Я обновил ConfigMap и наблюдал старое окружение и новый смонтированный файл.
Я вызвал управляемый rollout и увидел новое окружение.
Я создавал Secret без сохранения и вывода настоящего значения.
Я доказал, что base64 обратим и не является шифрованием, не раскрывая секрет.
Я вызвал CreateContainerConfigError отсутствующим ключом и нашёл Event.
Я объясняю шифрование хранимых данных через KMS и раскрытие во время исполнения.
Я могу спроектировать внешнюю ротацию и обновление секрета.

Критерий: предсказать UID Pod, число перезапусков, окружение и файл после изменения ConfigMap.

4. Сеть

Критерий: нарисовать путь запроса от клиента до процесса Python и доказательство каждого перехода.

5. Хранение данных

Я сравнил жизненные циклы файловой системы контейнера, emptyDir и PVC.
Я получил PVC Bound и доказательства PV, класса, provisioner и политики возврата.
Я сохранил счётчик после замены Pod.
Я вызвал непривязанный PVC и диагностировал его по Events PVC.
Я объясняю RWO (узел) против RWOP (Pod).
Я не считаю режим доступа блокировкой или репликацией приложения.
Я записал различия снимка, резервной копии и восстановления.
Я знаю, что снимок etcd не содержит байты PVC.
Я обосновал Deployment без состояния и внешнюю БД для итогового проекта.

Критерий: назвать судьбу данных при перезапуске контейнера, удалении Pod, удалении PVC с Delete/Retain и потере кластера.

6. Проверки, ресурсы и планирование

Критерий: по симптому Pending назвать первые три команды доказательств без журналов.

7. Развёртывание, масштабирование и нарушения доступности

Критерий: за 15 минут провести неудачный rollout → доказательства → undo → отмена исходника → проверка пользовательского пути.

8. Безопасность

Критерий: найти риск повышения привилегий в чужом манифесте и предложить проверяемую меру защиты, а не cluster-admin.

9. Наблюдаемость и диагностика

Критерий: случайный инцидент — влияние, гипотеза, три команды, исправление, проверка и очистка за 10 минут.

10. Доставка и промышленная эксплуатация

Критерий: одностраничный план обновления содержит контрольную группу, SLO, резервную копию и восстановление, rollback и владельцев.

Финальный проверочный манифест

Этот Job проверяет Service после развёртывания:

apiVersion: batch/v1
kind: Job
metadata:
  name: python-api-final-smoke
  namespace: kube-course
  labels:
    app.kubernetes.io/name: python-api-final-smoke
    app.kubernetes.io/part-of: kube-python-course
spec:
  backoffLimit: 1
  ttlSecondsAfterFinished: 300
  template:
    metadata:
      labels:
        app.kubernetes.io/name: python-api-final-smoke
    spec:
      restartPolicy: Never
      automountServiceAccountToken: false
      securityContext:
        runAsNonRoot: true
        runAsUser: 10001
        runAsGroup: 10001
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: smoke
          image: busybox:1.37.0
          command:
            - sh
            - -c
            - >-
              wget -qO- http://python-api/health/ready
              | grep -q '"status":"ready"'
          resources:
            requests: {cpu: 10m, memory: 16Mi}
            limits: {cpu: 100m, memory: 64Mi}
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop: ["ALL"]

kubectl apply --dry-run=server -f /tmp/final-smoke.yaml
kubectl apply -f /tmp/final-smoke.yaml
kubectl wait job/python-api-final-smoke -n kube-course \
  --for=condition=Complete --timeout=120s
kubectl logs job/python-api-final-smoke -n kube-course

Ожидаются Job в состоянии Complete и код завершения 0; пустые журналы допустимы, потому что используется grep -q. При ошибке нужны доказательства по Service, DNS, политики и readiness.

90-минутный практический экзамен

0–15: предварительная проверка контекста, рендеринг, серверный dry-run, развёртывание dev.
15–25: проверить три перехода: прямой Pod, Service внутри кластера и пользовательский port-forward.
25–40: изменение конфигурации, слепок окружения и файл, управляемый rollout.
40–60: два случайных сценария, восстановление на основе доказательств.
60–70: положительная и отрицательная проверки RBAC и запрет PSS.
70–80: неудачный rollout образа, rollback и исправление исходника.
80–90: финальная контрольная проверка, просмотр доказательств, очистка или передача устойчивого состояния.

Зачёт: завершено не менее восьми разделов, секреты не раскрыты, изменений в неверном контексте нет, оба инцидента локализованы на правильном уровне, rollback проверен. Для job-ready дополнительно: не более двух подсказок и причинно-следственное объяснение. Для эксплуатационной траектории: запуск в реальном целевом окружении с политиками, CNI/CSI, внешним входом, метриками, SLO и проверкой восстановления.

Практическое упражнение

Попросите коллегу наблюдать экзамен и ставить:

0 — только заявление без доказательств;
1 — команда успешна, объяснение неполно;
2 — предсказание, доказательство, механизм и восстановление или ограничение.

Сумма не менее 16/20 по десяти выбранным навыкам — зачёт. Повторите только слабые аспекты, а не весь курс.

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

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

Сломанный сценарий

Если финальная проверка находится в Pending, не читайте журналы Service первым действием. Решение:

kubectl get job,pod -n kube-course \
  -l app.kubernetes.io/name=python-api-final-smoke
kubectl describe pod <smoke-pod> -n kube-course
kubectl get events -n kube-course \
  --field-selector involvedObject.name=<smoke-pod>

Если Pod находится в Running или Failed, тогда проверяйте журналы и код Job, DNS и Service. Один симптом «контрольная проверка не прошла» имеет разные уровни; phase определяет следующее доказательство.

Проверочный список дерева диагностических решений

Не могу поставить [x]
├─ команда не выполнялась → лабораторная работа, а не проверка теории
├─ вывод есть, механизм не объясняю → перечитать нужную главу + воспроизвести
├─ ожидаемое не совпало → исследовать среду/версию, не копировать ожидаемый результат
├─ дополнение недоступно → записать пробел в зависимостях + установить/проверить или оставить без отметки
├─ ограничение kind → нужна среда эксплуатационной траектории
└─ данные чувствительны → повторно получить целевой/отредактированный вывод

Уровни завершения

Повторить основы: отмечено менее 60% или произошла любая критическая ошибка безопасности — неверный контекст, утечка секрета или принудительное удаление без решения о риске.
Job-ready: не менее 80%, практический зачёт, не менее шести сценариев отказа, 15–19 баллов итогового проекта, ограничения названы честно.
Эксплуатационная траектория завершена: не менее 90%, 20–24 балла итогового проекта в реальном целевом окружении, доказательства политик, сети, внешнего входа, метрик, восстановления, контрольного обновления и SLO. Это не означает конец обучения и готовности к дежурствам.

Типичные ошибки и заметка о безопасности и стоимости

Типичные ошибки: отметка за чтение; скопированный ожидаемый вывод; скрытая неудачная команда; снимок экрана Secret; локальный кластер назван промышленным; пробел дополнения отмечен пройденным; очистка без доказательства политики возврата. Хранение доказательств тоже стоит денег и несёт риск приватности: задайте срок хранения и маскирование. Повторные кластеры и образы занимают диск. Не проводите разрушающие упражнения эксплуатационного экзамена без ограниченной авторизации, окна изменений и rollback.

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

Что требуется кроме успешной команды?
Можно ли отметить NetworkPolicy без запрещающей контрольной проверки?
Что делать с пробелом дополнения?
Почему экзамен повторяется через неделю?
Какая критическая ошибка отменяет зачёт?

Ответы: 1) наблюдаемый инвариант, механизм и восстановление или ограничение; 2) нет; 3) записать и установить с проверкой либо оставить неотмеченным; 4) проверка самостоятельной воспроизводимости; 5) изменение в неверном контексте, раскрытие секрета или небезопасное разрушающее действие.

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

Проверочный список завершает курс доказательствами. Вернитесь к MAIN, критериям итогового проекта и таблице версий перед новым целевым кластером.