Kubernetes-мистика по субботам

Надеюсь я не назову так отдельную рубрику.

В сегодняшний выходной день произошла одна веселая ситуация. Это одновременно пиздец весело с точки зрения наблюдателя за пивком и пиздец больно с точки зрения devops-инженера. Учитывая субботу, весеннее солнце за окном и интересную корейскую дораму, которая была прервана.

Представьте себе — время в районе 12:00 — новый образ контейнера выкачивается из registry успешно, деплой сервиса проходит как ожидается, поды стартуют и все замечательно.

Время в районе 13:00 — начинают, значит, катить второй, совершенно независимый от первого сервис — но при попытке выкачать образ контейнера и docker registry вылетает event с 403й ошибкой. Падает и падает ошибка. Под не стартует — ImagePullBackOff…

Как так, ведь вот только недавно выкатался первый раз успешно? Как оказалось, мы наткнулись на мину — после запуска деплоя первого сервиса случилась авторотация пароля от учетной записи, которая ходит в docker registry. И НИ ОДИН новый сервис теперь не хочет выкатываться.

То ли первый деплой послужил триггером, то ли так великолепно вписались в TTL для пароля… Так великолепно, что на поиск причины убили часа 3 — обивали пороги нескольких дежурок, звонили-писали коллегам и еще затем часа полтора на способы обновления пароля из vault в ServiceAccount в неймспейсе.

Что же в итоге случилось и как этого избежать?

Благодаря звонку в дежурку, удалось предположить что мы запустили два деплоя, между которыми проскочила авторотация пароля. Она запустилась в интервале 12:00–12:30, и к 13:00 старый пароль стал окончательно невалидным.

«Вот бы сейчас жахнуть какой-нибудь лебезящий алерт на ротацию секретов» — Подумал я

Но можно и автоматизировать! Позже, немного погуглив и порефлексировав с дипсиком, появилась светлая мысль однажды попробовать добавить новый оператор в неймспейс, который будет освежать ImagePullSecrets.

А именно подумал про vault-gcp-secrets — это хелм-чарт и оператор, который решает конкретную задачу: поддерживает в актуальном состоянии Kubernetes Secret с ключом сервисного аккаунта GCP, получая его из Vault .

Этот оператор умеет создавать секреты двух типов :

• kubernetes.io/dockerconfigjson — как раз то, что вам нужно для imagePullSecret
• Opaque — для generic ключей

Как он работает

Схема работы выглядит так:

1. В Vault настроен GCP Secrets Engine, который умеет динамически генерировать ключи сервисных аккаунтов с заданными IAM-ролями 
2. Оператор vault-gcp-secrets аутентифицируется в Vault (через Kubernetes auth или AppRole) 
3. Оператор читает путь в Vault (например, gcp/my-role) и получает свежий JSON-ключ сервисного аккаунта
4. Оператор создает или обновляет Kubernetes Secret указанного типа с этим ключом
5. При следующей синхронизации (по расписанию или при изменении в Vault) оператор обновляет секрет новым ключом

Как это может решить проблему

В нашем случае с registry и авторотацией пароля:

1. До: Мы создавали imagePullSecret со статическим паролем → пароль протухал → новые поды не могли выкачать образ.
2. С vault-gcp-secrets: Оператор поддерживает imagePullSecret в актуальном состоянии. Когда Vault ротирует ключ или пароль, оператор автоматически обновляет секрет в Kubernetes.

Оказывается и для GCR (Google Container Registry) это работает отлично: оператор создает imagePullSecret с типом dockerconfigjson, а в настройках указывается :

secret:
  type: kubernetes.io/dockerconfigjson
  dockerServer: gcr.io
  dockerUsername: _json_key  # специальное значение для JSON-ключа

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