Шаблон для принудительного применения модуля имеет метку из контейнера внутри этого модуля. - PullRequest
0 голосов
/ 06 мая 2020

Наша команда написала изображение docker. Мы хотим получить предупреждение, если модуль, на котором запущено это изображение, выйдет из строя. (Для этого мы используем диспетчер предупреждений Prometheus и kube-state-metrics ).

Команда другая создает задание, которое запускает этот образ (обратите внимание, что они: re сделать это через что-то вроде ar go). Чтобы получить желаемое оповещение, мы просим эту команду включить метку c, т.е. модуль, созданный заданием, будет иметь метку, которую мы можем использовать в promql для создания оповещения при сбое этого модуля.

Единственный способ обеспечить использование правильной метки - это проверить наличие этой метки внутри контейнера и получить сообщение об ошибке, сообщающее нам, что метка отсутствует. Таким образом, либо через нисходящий API (но это другое требование для команды, выполняющей задание), либо, что более вероятно, просто запустив kubectl get pods -l ..., поскольку этот контейнер уже использует kubectl для чего-то еще.

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

1 Ответ

2 голосов
/ 06 мая 2020

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

https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/ https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook

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

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

...