Наша команда написала изображение docker. Мы хотим получить предупреждение, если модуль, на котором запущено это изображение, выйдет из строя. (Для этого мы используем диспетчер предупреждений Prometheus и kube-state-metrics ).
Команда другая создает задание, которое запускает этот образ (обратите внимание, что они: re сделать это через что-то вроде ar go). Чтобы получить желаемое оповещение, мы просим эту команду включить метку c, т.е. модуль, созданный заданием, будет иметь метку, которую мы можем использовать в promql для создания оповещения при сбое этого модуля.
Единственный способ обеспечить использование правильной метки - это проверить наличие этой метки внутри контейнера и получить сообщение об ошибке, сообщающее нам, что метка отсутствует. Таким образом, либо через нисходящий API (но это другое требование для команды, выполняющей задание), либо, что более вероятно, просто запустив kubectl get pods -l ...
, поскольку этот контейнер уже использует kubectl
для чего-то еще.
В нашей команде ведутся споры, является ли это плохой практикой. Настаивать на этикетке стручка - это антипаттерн? Нам интересно, есть ли более чистый дизайн для такой ситуации?