Образ не является запущенным процессом
Образ контейнера содержит файлы и зависимости, необходимые для запуска. Он служит шаблоном, из которого создают контейнеры. Контейнер является работающим или остановленным экземпляром с собственным жизненным циклом; наличие образа ещё не означает, что приложение обслуживает запросы. Из одного образа можно создать несколько экземпляров. Сборка нового образа и перезапуск существующего контейнера также не равнозначны. Если изменился код, нужно понимать, какой именно образ используется после обновления. Тег удобен как имя, но для точного указания содержимого применяют digest. Учебная ошибка состоит в ожидании, что любое изменение файла на компьютере автоматически окажется внутри ранее созданного образа. Способ передачи файлов зависит от выбранной конфигурации.
Kubernetes поддерживает описанное состояние
В Kubernetes минимальной единицей развёртывания является Pod, который включает один или несколько связанных контейнеров. Обычно приложение описывают через ресурс более высокого уровня, например Deployment. Пользователь задаёт желаемое состояние, а контроллер сопоставляет его с наблюдаемым и предпринимает действия для сближения. Если требуются три экземпляра, исчезновение одного управляемого Pod обычно приводит к созданию замены. Но это не означает восстановления содержимого его временной файловой системы или исправления ошибки программы. Оркестрация поддерживает инфраструктурные условия, а не угадывает смысл бизнес-данных. Для хранения, резервного копирования и корректного завершения работы нужны отдельные решения. Также важно учитывать доступные ресурсы: декларация трёх экземпляров не создаёт дополнительную память на узлах.
Сеть и готовность проверяются отдельно
Адрес отдельного Pod не стоит считать постоянным адресом приложения. Service предоставляет устойчивую абстракцию доступа к выбранным экземплярам. В типичном случае связь определяется метками и селектором, поэтому несовпадение этих значений может оставить Service без нужных получателей трафика. Само создание ресурса не гарантирует доступность приложения извне. Разделяйте запуск процесса и готовность обслуживать запросы. Программа может уже работать, но ещё загружать данные или ожидать зависимость. Проверки готовности помогают не направлять трафик туда, где его пока нельзя корректно обработать. При диагностике двигайтесь по уровням: нужный образ, состояние Pod, готовность приложения, выбор получателей Service и дальнейший сетевой путь. Это эффективнее случайного изменения нескольких настроек одновременно.
Попробуйте на практике
Смоделируйте развёртывание на бумаге. Установка программ, регистрация в облаке и запуск платных ресурсов не нужны.
- Нарисуйте карточку образа версии A и три карточки Pod, использующих этот образ. Рядом запишите желаемое число экземпляров: три.
- Уберите одну карточку Pod. Опишите действие контроллера и отдельно перечислите сведения, которые нельзя восстановить только из образа.
- Добавьте карточку Service с условием выбора app=demo. Пометьте два Pod этой меткой, а третий другой, и определите, какие подходят под селектор.
- Нарисуйте версию B образа и план постепенной замены. Запишите, как будете отличать созданный экземпляр от готового обслуживать запросы.
Как проверить результат. В модели не смешаны образ и экземпляр, восстановление количества и сохранность данных. Вы можете объяснить, почему существующий Service ещё не доказывает успешную работу приложения.
Частые вопросы
Обязателен ли Kubernetes для каждого контейнера?
Нет. Сам факт контейнеризации не требует кластера. Способ запуска выбирают по масштабу, требованиям к эксплуатации и возможностям команды.
Перезапуск исправляет неисправное приложение?
Иногда он временно снимает симптом, но не устраняет причину. Ошибки конфигурации, недоступные зависимости и проблемы данных требуют отдельного анализа.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.