Как обновить ConfigMap в Kubernetes?

А, ну слушай, тут тема про ConfigMap в кубере — вроде бы элементарщина, но есть один нюанс, который многих нахуй отправляет в депрессию. Объясняю на пальцах, с примерами из жизни.

1. Как обновить сам ConfigMap: Тут, в принципе, всё просто, как три копейки. Есть несколько путей, выбирай любой, который тебе не в пизду.

• Через kubectl apply с манифестом: Это самый правильный, идемпотентный путь, особенно если ты не распиздяй, а хранишь всё в гите. Делаешь правку в файле и — хуяк!

  # Меняю 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'ы увидеть эти изменения: Вот тут собака зарыта, сука. По умолчанию Pod, который уже крутится, нихуя не узнает, что ConfigMap поменялся. Он будет до скончания веков использовать ту версию данных, которую увидел при своём рождении. Чтобы применить новую конфигурацию, нужно как-то обновить сами Pod'ы. Стратегии есть разные.

• Ручной перезапуск Deployment: Тупой, как валенок, но чертовски эффективный способ. Просто говоришь деплойменту: «Чувак, переродись».

  kubectl rollout restart deployment/my-app-deployment

  Он создаст новые Pod'ы, и они уже примонтируют свежий, обновлённый ConfigMap. Старые поды потихоньку поубиваются. Всё честно.

• Использование сторонних инструментов (Reloader): Для ленивых, вроде меня. Ставишь себе хелм-чарт 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. Хитро, да?

  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: app-config-v2 # Обрати внимание, имя новое!
  immutable: true
  data:
    config.properties: |
      key=updated-value

Лично я в своих пайплайнах обычно действую по старинке, без лишних телодвижений: kubectl apply для ConfigMap, а следом — kubectl rollout restart для нужного деплоймента. Предсказуемо, понятно, и волнение ебать не возникает.