Как посмотреть историю изменения Deployment

История изменений Deployment в Kubernetes

Это один из ключевых вопросов для DevOps инженера, работающего с Kubernetes. Умение отслеживать историю изменений Deployment критически важно для отладки, отката изменений и соблюдения compliance. Вот несколько основных методов:

1. Использование kubectl rollout history (Основной метод)

Самый прямой способ — команда kubectl rollout history. Она показывает историю ревизий (revisions) вашего Deployment'а.

# Показать историю ревизий для конкретного Deployment
kubectl rollout history deployment/<deployment-name> -n <namespace>

# Пример:
kubectl rollout history deployment/frontend -n production

Вывод будет содержать номера ревизий, причину изменения (например, Manual или ChangeCause) и время.

Детализация конкретной ревизии:

# Показать подробности о конкретной ревизии, включая применённый манифест
kubectl rollout history deployment/<deployment-name> --revision=<номер-ревизии>

# Пример с ревизией 3:
kubectl rollout history deployment/frontend --revision=3 -n production

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

Улучшение читаемости истории:

По умолчанию ChangeCause (причина изменения) часто пуста. Чтобы историю было легче читать, всегда добавляйте аннотацию kubernetes.io/change-cause в манифест или при применении:

# При применении манифеста через kubectl apply
kubectl apply -f deployment.yaml --record

# ИЛИ вручную через аннотацию в манифесте:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
  annotations:
    kubernetes.io/change-cause: "Обновление образа до версии v1.2.3 для исправления CVE-2023-XXXXX"
spec:
  ...

2. Использование kubectl describe (Быстрый обзор)

Для быстрого просмотра последних событий, но без детального манифеста прошлых версий:

kubectl describe deployment/<deployment-name> -n <namespace>

В выводе обратите внимание на разделы:

• Events (в самом конце) — хронология событий (например, ScalingReplicaSet, SuccessfulRescale).
• Conditions — текущее состояние развёртывания (Available, Progressing).
• Annotations — могут содержать метаинформацию, включая deployment.kubernetes.io/revision.

Этот метод хорош для оперативного анализа текущих проблем.

3. Анализ через ReplicaSet

Deployment управляет Pod'ами через ReplicaSet. Каждая ревизия Deployment'а создаёт новый ReplicaSet. Поэтому историю можно частично увидеть, посмотрев на ReplicaSet'ы:

# Показать все ReplicaSet, отсортированные по метке ревизии Deployment'а
kubectl get replicaset -n <namespace> -l app=<app-label>

# Или для более детального просмотра:
kubectl describe replicaset <replicaset-name> -n <namespace>

Имя ReplicaSet имеет формат <deployment-name>-<unique-hash>. Самый новый ReplicaSet соответствует текущей ревизии. Метка deployment.kubernetes.io/revision указывает номер ревизии.

4. Просмотр через GitOps (Argo CD, Flux) или системы мониторинга

Если вы используете подход GitOps, то первоисточником истины является репозиторий Git. История изменений Deployment'а в этом случае — это история коммитов файла манифеста.

• Argo CD UI/CLI: Прямо в интерфейсе можно увидеть историю синхронизаций (sync history), кто и когда инициировал обновление, и разницу (diff) между развернутым и желаемым состоянием.
• Flux: Аналогично, используйте flux history или смотрите события HelmRelease/GitRepository объектов.
• Git журнал: git log --oneline -p deployment.yaml

5. Интеграция с системами логирования и аудита (kube-apiserver)

Для аудита безопасности и compliance необходимо смотреть логи kube-apiserver. Все операции kubectl (CRUD) с объектами Kubernetes проходят через API-сервер, который при правильной настройке пишет полные audit-логи.

• Где искать: Audit-логи обычно направляются в централизованную систему (например, ELK Stack, Loki, или облачные решения вроде Cloud Audit Logs в GCP).
• Что искать: События с verb=update, patch, create для ресурса deployments в нужном namespace. В логах будет пользователь, источник вызова (например, kubectl или argo-cd), старый и новый манифест.

Практические советы и best practices:

• Всегда используйте --record или аннотации: Без change-cause история бесполезна, так как показывает лишь timestamp.
• Версионируйте манифесты в Git: Инструменты вроде kubectl rollout history имеют ограниченную глубину хранения (по умолчанию 10 ревизий, настраивается через spec.revisionHistoryLimit в Deployment). Git — ваш надёжный долгосрочный архив.
• Сочетайте методы: Для быстрой отладки используйте kubectl rollout history, для расследования инцидентов — audit-логи, для восстановления полной картины изменений — Git-историю.
• Настройте revisionHistoryLimit: Установите разумное значение (например, 15-20), чтобы хранить достаточно истории для отката, но не тратить лишние ресурсы кластера на хранение старых ReplicaSet'ов.

# Пример настройки в манифесте Deployment:
apiVersion: apps/v1
kind: Deployment
spec:
  revisionHistoryLimit: 15 # Хранить историю последних 15 ревизий
  ...

Итог: Для ежедневной работы достаточно kubectl rollout history --revision. Для расследования инцидентов подключайте kubectl describe и логи. Для полного контроля над жизненным циклом и compliance переходите на GitOps, где история изменений — это история вашего репозитория кода.