Приложения: запуск, ресурсы и обновление

Практика через терминал портала

1. Открой готовое упражнение

   Открой практикум Deployment в соседней вкладке. Если первый модуль уже зачтён, используй его наблюдения; повторная подготовка создаёт новое упражнение и сбрасывает его рабочее состояние.

   kubectl -n interview-lab get deployment,pods,service
   kubectl -n interview-lab get resourcequota

   Что должно получиться. В подготовленном упражнении виден portal-demo. Все изменения этой части ограничены interview-lab.

   Если результат отличается

   Если пространство пустое, нажми «Подготовить». Не создавай объекты в default.

2. Разбери настройки контейнера

   Прочитай шаблон Deployment. Найди requests, limits и readinessProbe. В исходном portal-demo отдельная livenessProbe не задана: отсутствие проверки тоже важно заметить. Сравни с описанием трёх видов проверок в теории.

   kubectl -n interview-lab get deployment portal-demo -o yaml
   kubectl -n interview-lab describe deployment portal-demo

   Что должно получиться. Ты можешь показать конкретные поля, а не только пересказать названия проверок.

   Если результат отличается

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

3. Исправь приложение и получи зачёт

   Выполни шаги первого модуля: две реплики, правильный selector Service и замена одного Pod. Нажми «Проверить результат» до следующих экспериментов.

   kubectl -n interview-lab scale deployment portal-demo --replicas=2
   kubectl -n interview-lab patch service portal-demo -p '{"spec":{"selector":{"app":"portal-demo"}}}'
   kubectl -n interview-lab rollout status deployment/portal-demo --timeout=90s

   Что должно получиться. Две готовые реплики и успешная серверная проверка. История зачёта сохраняется отдельно от галочек урока.

   Если результат отличается

   Если quota запрещает третью копию при обновлении, сначала посмотри стратегию и текущие Pod; не увеличивай общую квоту.

4. Увидь конкретную причину Pending

   После зачёта временно задай в шаблоне заведомо отсутствующую метку ноды. Старые готовые копии не удаляй. Смотри события нового ожидающего Pod.

   kubectl -n interview-lab patch deployment portal-demo -p '{"spec":{"template":{"spec":{"nodeSelector":{"course.example/missing":"yes"}}}}}'
   kubectl -n interview-lab get pods
   kubectl -n interview-lab get events --sort-by=.metadata.creationTimestamp

   Что должно получиться. Событие FailedScheduling объясняет несовпадение метки. Если сначала мешает квота, запиши и эту причину: это отдельное ограничение.

   Если результат отличается

   Не исправляй это добавлением метки общей ноде. Следующий шаг убирает только учебное ограничение.

5. Верни размещение и попробуй обновление

   Удали только добавленную метку из шаблона, затем инициируй замену копий. Это упражнение меняет шаблон, но не версию программы. После замены сравни имена и возраст Pod в том же терминале.

   kubectl -n interview-lab patch deployment portal-demo --type=json -p '[{"op":"remove","path":"/spec/template/spec/nodeSelector/course.example~1missing"}]'
   kubectl -n interview-lab rollout status deployment/portal-demo --timeout=90s
   kubectl -n interview-lab rollout restart deployment/portal-demo
   kubectl -n interview-lab rollout status deployment/portal-demo --timeout=90s
   kubectl -n interview-lab get pods -o wide

   Что должно получиться. Новые Pod готовы; rollout завершён. Отличай замену Pod от выпуска нового образа.

   Если результат отличается

   Если операция зависла, проверь Events, Ready и resourcequota. Не удаляй все копии одновременно.

6. Сравни готовность и перезапуск

   Для наглядного разбора разных проверок используй следующий практикум «Диагностика» после зачёта сетевого задания. В нём неправильный путь readiness исправляется отдельно от ошибок образа и конфигурации.

   kubectl -n interview-lab get pods
   kubectl -n interview-lab get events --sort-by=.metadata.creationTimestamp

   Что должно получиться. В журнале есть сравнение: потеря Ready и увеличение RESTARTS — разные события. Не отмечай проверку probes до выполнения практики.

   Если результат отличается

   Практикумы последовательные. Заверши и очисти текущее упражнение перед следующим.

7. Проверь обслуживание на отдельном стенде

   Открой инструкцию отдельного стенда. Только после проверки контекста kind-kaas-lab создай две реплики из demo.yaml и бюджет minAvailable: 1. На нём можно выполнять drain; на портальном кластере этот шаг не выполняется.

   kubectl --context kind-kaas-lab -n kaas-lab apply -f https://test.igorhome.ru/static/learning/demo.yaml
   kubectl --context kind-kaas-lab -n kaas-lab create poddisruptionbudget demo --selector=app=demo --min-available=1
   kubectl --context kind-kaas-lab -n kaas-lab get pdb
   kubectl --context kind-kaas-lab drain kaas-lab-worker --ignore-daemonsets --delete-emptydir-data --timeout=120s
   kubectl --context kind-kaas-lab uncordon kaas-lab-worker

   Что должно получиться. В журнале записано, разрешил ли бюджет удаление и хватило ли второй ноде ресурсов. Команда удаляет временные emptyDir-данные только учебного стенда.

   Если результат отличается

   При блокировке сначала проверь доступные реплики и свободное место. Не используй --disable-eviction для обхода бюджета.

8. Заверши и сохрани выводы

   Верни ноды отдельного стенда в доступное состояние. На портале очисти упражнение штатной кнопкой. Запиши причину Pending и порядок действий при заблокированном обслуживании.

   kubectl --context kind-kaas-lab get nodes

   Что должно получиться. Учебные ноды Ready, SchedulingDisabled отсутствует. Есть собственное объяснение, почему бюджет не защищает от аварии сервера.

   Если результат отличается

   Если отдельный стенд ещё не создан, оставь критерий обслуживания неотмеченным. Теорию и доступную практику можно пройти раньше.

Открыть терминал ↗ · Скачать файлы лаборатории →

Файлы и подготовка к этой работе

• Подготовка отдельного стенда и правила работы ↗

Критерии готовности

Отмечай только то, что проверил на указанном стенде. Эти галочки сохраняются в браузере. Для готовых упражнений зачёт выдаёт отдельная серверная проверка практикума; остальные задания подтверждай журналом и доказательствами. Учебная модель не заменяет реальный облачный опыт.

Что сохранить в портфолио

• Журнал: исходное состояние → команда или действие → ожидаемый результат → фактическое наблюдение.
• Доказательства по критериям ниже: очищенный от секретов вывод, схема или ссылка на проверенный коммит.
• Отдельный список: что пока не запускалось, почему и какой стенд нужен для продолжения.

Проверь понимание

8 вопросов по этому модулю. Проходной результат — 7 из 8. После ответа — объяснения и ссылки на разделы, к которым стоит вернуться.