Ответ
Обновить данные в ConfigMap просто, но ключевой момент — сами Pod'ы не отслеживают изменения ConfigMap автоматически. Вот рабочий процесс, который я применяю.
1. Способы обновления ConfigMap:
- Через
kubectl applyс манифестом: Это идемпотентный и предпочтительный метод, особенно в GitOps-подходе.# Вношу изменения в configmap.yaml и применяю kubectl apply -f configmap.yaml - Через
kubectl edit: Для быстрых правок.kubectl edit configmap my-app-config -n default - Через
kubectl patch: Удобно для скриптов или CI/CD.kubectl patch configmap my-app-config --patch '{"data":{"LOG_LEVEL":"DEBUG"}}'
2. Стратегии обновления Pod'ов после изменения ConfigMap: По умолчанию Pod продолжает использовать старую версию данных. Чтобы применить изменения, нужно инициировать обновление Pod'а.
- Ручной перезапуск Deployment: Самый прямой способ.
kubectl rollout restart deployment/my-app-deploymentЭто создаст новые Pod'ы, которые примонтируют обновлённый ConfigMap.
- Использование сторонних инструментов (Reloader): Устанавливаю Helm-чарт
stakater/reloader. Добавляю аннотацию к Deployment, и Reloader автоматически перезапустит его при изменении связанного ConfigMap.apiVersion: apps/v1 kind: Deployment metadata: name: my-app annotations: reloader.stakater.com/auto: "true" spec: ... - Использование immutable ConfigMaps (Kubernetes v1.19+): Если данные конфигурации статичны, можно пометить ConfigMap как
immutable: true. Это повышает безопасность и производительность. Для обновления в таком случае нужно создать ConfigMap с новым именем и обновить ссылку на него в Pod template, что вызовет стандартный rollout Deployment'а.apiVersion: v1 kind: ConfigMap metadata: name: app-config-v2 immutable: true data: config.properties: | key=updated-value
В своём CI/CD-пайплайне я обычно совмещаю kubectl apply для ConfigMap с последующим kubectl rollout restart для соответствующего Deployment, чтобы изменения вступили в силу предсказуемо.