Что такое лейблы в Kubernetes

Что проверяют

Понимаете ли вы, что лейблы это не подписи для людей, а рабочий механизм связывания объектов: по ним Service находит поды, контроллер считает свои, а сетевая политика решает, кого пускать. Ошибка в лейбле это не опечатка, а разорванный трафик.

Как отвечать

Лейбл это пара ключа и значения в метаданных объекта, по которой работают селекторы. У ключа может быть префикс домена, имя и значение ограничены длиной и набором символов, так что произвольный текст туда не поместится.

Где лейблы реально работают:

spec.selector у Service выбирает поды, на которые идёт трафик. spec.selector.matchLabels у Deployment определяет, какие поды принадлежат контроллеру. nodeSelector и правила размещения выбирают узлы по их лейблам. На селекторы опираются сетевые политики, бюджеты доступности, выборка через kubectl get -l и сбор метрик.

Селекторы бывают по равенству (env=prod, tier!=db) и по множествам (in, notin, exists). Service понимает только равенство, контроллеры и kubectl понимают оба вида.

Отличие от аннотаций назовите сразу: лейблы нужны для отбора и потому короткие и индексируемые, аннотации хранят произвольные данные для инструментов, и селекторов по ним не существует.

Хороший тон это общепринятый набор ключей вида app.kubernetes.io/name, /instance, /version, /component, /managed-by: с ним дашборды и выборки предсказуемы в любом кластере.

Где спотыкаются

Считают, что селектор Deployment можно поправить на живом объекте. Он неизменяем после создания, попытка приводит к отказу, и лечится это только пересозданием ресурса.

Кладут в лейблы то, для чего есть аннотации: длинное описание, ссылку на сборку, произвольную строку с недопустимыми символами. Объект перестаёт создаваться или лейбл оказывается бесполезен для отбора.

Забывают, что снятие лейбла с пода вырывает его из-под контроллера. Тот немедленно поднимает замену, а осиротевший под продолжает жить, пока его не удалят руками. Для отладки приём удобный, в проде неожиданный.