Что произойдет, если изменить версию приложения непосредственно в реплике

Механизм работы реплики и изменение данных "в обход" системы управления

Если вы напрямую измените версию приложения в работающей реплике, обойдя стандартные механизмы развертывания (например, kubectl, Helm, CI/CD пайплайн), вы нарушите фундаментальный принцип идемпотентности и желаемого состояния (desired state), который лежит в основе Kubernetes и аналогичных систем.

Давайте подробно разберем, что происходит на разных уровнях.

1. Немедленные последствия в поде (Pod)

При прямом изменении файлов в контейнере (например, обновлении JAR/WAR-файла, бинарника или конфигурации):

• Контейнер продолжит работу с измененными файлами. Если новое приложение совместимо с запущенным процессом и не требует перезагрузки, изменения могут даже "подхватиться" (например, в интерпретируемых языках). Однако в большинстве случаев для запуска новой версии требуется рестарт процесса или всего контейнера.
• Нарушается консистентность образа. Контейнер работает с файловой системой, которая представляет собой наложение слоев: неизменяемый образ + временный writable слой (container layer). Ваши изменения записываются в этот временный слой. Образ, указанный в Pod spec, остается прежним.
• Изменения являются временными и эпиhemeral. Как только под будет пересоздан (из-за обновления, сбоя, scaling-операции), он запустится с оригинальным, неизменным образом, и все ваши ручные правки будут безвозвратно утеряны.

# Пример: что происходит при прямом вмешательстве в под Kubernetes
# 1. Находим работающий под и контейнер
kubectl get pods
# 2. Получаем shell внутри контейнера (например, для отладки)
kubectl exec -it <pod-name> -- /bin/bash
# 3. ВНУТРИ КОНТЕЙНЕРА (НЕ РЕКОМЕНДУЕТСЯ ДЛЯ РЕАЛЬНЫХ ИЗМЕНЕНИЙ):
# Меняем бинарник приложения
cp /tmp/new-app-version /usr/local/bin/app
# Рестартуем процесс (если повезет и есть супервизор)
service app restart
# ИЛИ убиваем главный процесс, что приведет к рестарту контейнера
kill 1

Временные изменения в running-контейнере

2. Реакция контроллеров Kubernetes

Kubernetes постоянно работает в цикле reconcile (согласование). Контроллеры (например, DeploymentController, StatefulSetController) каждые несколько секунд сравнивают текущее состояние (current state) с желаемым состоянием (desired state), описанным в объектах API (Deployment, StatefulSet и т.д.).

• Deployment не обнаружит изменений. Он следит за такими параметрами, как количество реплик и, что критически важно, спецификация шаблона пода (Pod Template Spec), в частности, поле .spec.template.spec.containers[].image. Поскольку вы изменили файлы внутри уже запущенного контейнера, а не тег образа в манифесте, Deployment "не увидит" расхождений. Количество реплик совпадает, Pod Template не менялся — значит, все в порядке, с точки зрения Deployment.
• Readiness/Liveness пробы могут среагировать. Если ваше изменение приведет к сбою приложения (ошибке, зависанию, неверному ответу на HTTP-запрос пробы), kubelet на узле получит об этом от liveness-пробы. Это вызовет рестарт контейнера (а с ним и потерю ваших изменений) в рамках того же пода. Если сбойная версия не проходит readiness-пробу, под будет исключен из балансировщика нагрузки сервиса.

3. Системные и операционные риски

• Дрейф конфигурации (Configuration Drift): Реплика становится "уникальным снежинкой" (snowflake server), состояние которой не описано в коде (IaC — Infrastructure as Code). Это делает систему непредсказуемой, невоспроизводимой и сложной для отладки.
• Нарушение практик GitOps: Фактическое состояние кластера расходится с состоянием, задекларированным в Git-репозитории (источнике истины). Инструменты вроде ArgoCD или Flux будут показывать, что приложение синхронизировано, хотя это не так.
• Проблемы с безопасностью и аудитом: Невозможно отследить, кто, когда и какую версию развернул. Нарушаются процессы контроля доступа, построенные вокруг CI/CD и Pull Request.
• Сложность отката (Rollback): Стандартная команда kubectl rollout undo deployment/<name> будет бесполезна, так как она откатывает образ контейнера в Pod Template, а не файлы внутри running-пода. Чтобы вернуться к старой версии, вам придется вручную повторно вносить изменения или полностью пересоздать под.

4. Исключения и когда это (иногда) допустимо

Прямое изменение в контейнере может быть оправдано исключительно в целях отладки (debugging) или исследования на временных, не production-окружениях. Даже в этом случае предпочтительнее использовать:

• Ephemeral Debug Containers (функция Kubernetes) для диагностики.
• Перенаправление трафика отладки на специально собранный отладочный образ через Service Mesh (например, Istio) или Canary Deployment.

Резюме и правильный подход

Что произойдет? Ваши изменения будут временными, потенциально нестабильными, неотслеживаемыми и будут потеряны при следующем пересоздании пода. Контроллеры Kubernetes не начнут автоматический откат или обновление, так как изменение не затронуло декларативную спецификацию.

Правильный способ обновить версию приложения:

1. Обновить Docker-образ в реестре (например, myapp:1.1.0 -> myapp:1.2.0).
2. Изменить ссылку на образ в манифесте Deployment (в Git-репозитории).

   # deployment.yaml
   spec:
     template:
       spec:
         containers:
         - name: app
           image: my-registry/myapp:1.2.0  # Обновленная версия
   

3. Применить изменение через CI/CD пайплайн или инструмент GitOps.
4. DeploymentController обнаружит изменение в Pod Template, создаст новые пода с новым образом на основе стратегии обновления (RollingUpdate по умолчанию) и поэтапно заменит старые пода.

Таким образом, прямое изменение в реплике — это антипаттерн, который подрывает ключевые преимущества контейнерных оркестраторов: предсказуемость, воспроизводимость, аудируемость и отказоустойчивость. Все изменения должны вноситься через декларативные манифесты и автоматизированные процессы развертывания.