Проблема при использовании аннотаций Kubernetes
Я читал документацию по аннотациям кубернетов.
Но я не смог найти базового примера использования этих аннотаций. Например;
У меня есть развертывание yaml, как показано ниже:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
annotations:
test_value: "test"
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 1
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.13
ports:
- containerPort: 80
Как я могу использовать эту аннотацию с именем test_value и где.
Наилучшие пожелания...
Ответы 4
Как и Labels, Annotations - это пары ключ-значение, которые представляют метаданные, прикрепленные к объекту Kubernetes.
Но в отличие от Labels, которые используются внутри компании для поиска коллекции объектов, удовлетворяющих определенным условиям, цель Annotations - просто прикрепить соответствующие метаданные, которые не должны использоваться в качестве фильтра для идентификации этих объектов.
Что, если бы мы хотели описать, чей человек отвечал за создание конкретного файла .yaml?
Мы могли бы прикрепить такую информацию к объекту Kubernetes, чтобы, когда нам нужно знать, кто создал такой объект, мы могли просто запустить kubectl describe ....
Другим полезным примером может быть добавление аннотации к Deployment перед развертыванием, объясняющей, какие изменения произошли в новой версии объекта Deployment. Эту информацию можно будет получить позже при проверке истории версий развертывания.
Но, как вы уже поняли на примере Ingress, с помощью Annotations мы также можем выполнять расширенную настройку таких объектов. Это не ограничивается только Ingress, и, например, вы также можете предоставить конфигурацию для запуска Prometheus в кластере Kubernetes. Вы можете проверить подробности здесь.
Как упоминалось в Kubernetes Документация, метки имеют ограниченную цель выбора объектов и поиска коллекций объектов, удовлетворяющих определенным условиям. Это накладывает некоторые ограничения на информацию, которую вы можете хранить на этикетках. (Допустимые значения меток должны быть не более 63 символов и должны быть пустыми или начинаться и заканчиваться буквенно-цифровым символом ([a-z0-9A-Z]) с дефисами (-), подчеркиванием (_), точками (.) И буквенно-цифровые символы между.)
Однако аннотации не используются для фильтрации объектов, поэтому вы можете помещать в аннотации большие / маленькие структурированные / неструктурированные данные, которые могут содержать символы, которые вам не разрешено использовать в ярлыках. Инструменты и библиотеки могут извлекать аннотации и использовать их для добавления некоторых функций в ваш кластер.
Вот несколько примеров информации, которую можно записать в аннотации:
Поля, управляемые декларативным конфигурационным слоем. Добавление этих полей в качестве аннотаций отличает их от значений по умолчанию, установленных клиентами или серверами, и от автоматически сгенерированных полей и полей, установленных системами автоматического изменения размера или автоматического масштабирования.
Информация о сборке, выпуске или образе, такая как временные метки, идентификаторы выпуска, ветка git, номера PR, хэши изображений и адрес реестра.
Указатели на репозитории журналов, мониторинга, аналитики или аудита.
Информация о клиентской библиотеке или инструменте, которая может использоваться для целей отладки: например, имя, версия и информация о сборке.
Информация о пользователе или инструменте / системе, например URL-адреса связанных объектов из других компонентов экосистемы.
Метаданные облегченного инструмента развертывания: например, конфигурация или контрольные точки.
Номера телефонов или пейджера ответственных лиц или записи в каталоге, в которых указано, где можно найти эту информацию, например, на веб-сайте группы.
Что ж, вы правы, Annotations - это как Labels. Но я увидел, что мы можем настроить конфигурацию с помощью Annotations, например:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: cafe-ingress-with-annotations
annotations:
nginx.org/proxy-connect-timeout: "30s"
nginx.org/proxy-read-timeout: "20s"
nginx.org/client-max-body-size: "4m"
spec:
rules:
- host: cafe.example.com
http:
paths:
- path: /tea
backend:
serviceName: tea-svc
servicePort: 80
- path: /coffee
backend:
serviceName: coffee-svc
servicePort: 80
Конфигурацию Nginx можно настроить в соответствии с заданным Annotation. Итак, как это сделать. Я не смог найти учебник.
Сначала я расскажу немного об аннотациях.
Аннотации против ярлыков
Аннотации немного отличаются от ярлыков.
Этикетки:
Вы используете ярлыки для группировки ресурсов, на которые вы хотите ссылаться как единое целое.
Например, модули с app=run, env=staging могут предоставляться службой с селектором меток, который соответствует этим меткам, или управляться развертыванием или набором демонов.
Аннотации:
Аннотации могут использоваться по-разному, например, для описания и добавления поддержки полей, не являющихся частью K8S API.
Хотя метки должны быть короткими, аннотации могут содержать гораздо большие наборы данных и может достигать 256 КБ.
Примеры использования аннотаций
Ниже вы можете увидеть несколько примеров того, как аннотации используются различными поставщиками / инструментами, которые взаимодействуют с вашим кластером.
1) Используется внутри K8S - ниже приведены аннотации, которые добавляются в модуль API-сервера:
kubernetes.io/config.hash: 7c3646d2bcee38ee7dfb851711571ba3
kubernetes.io/config.mirror: 7c3646d2bcee38ee7dfb851711571ba3
kubernetes.io/config.seen: "2020-10-22T01:26:12.671011852+03:00"
kubernetes.io/config.source: file
2) Если вы подготовили кластер с Кубеадм - это будет добавлено в модуль API-сервера:
annotations:
kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: 10.246.38.137:6443
3) Если вы запустите амазонка-экс, вы увидите, что к вашим рабочим нагрузкам добавлена следующая аннотация - это для обратной совместимости - подробнее см. В здесь):
annotations:
kubernetes.io/psp: eks.privileged
4) Бывают случаи, когда сторонние инструменты, такие как aws-alb-входящий контроллер, требуют от вас передачи (обязательной) конфигурации через аннотации (поскольку эти поля не поддерживаются API K8S):
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: aws-alb-ingress
namespace: default
annotations:
kubernetes.io/ingress.class: alb
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/tags: Role=Backend , Environment=prod , Name=eros-ingress-alb
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80},{"HTTPS": 443}]'
alb.ingress.kubernetes.io/security-groups : sg-0e3455g455
alb.ingress.kubernetes.io/backend-protocol : HTTP
alb.ingress.kubernetes.io/target-type: instance
alb.ingress.kubernetes.io/healthcheck-path:
alb.ingress.kubernetes.io/success-codes: "200"
alb.ingress.kubernetes.io/certificate-arn:
В твоем случае
Спросите себя, в чем причина добавления аннотаций.
Затем убедитесь, что вы используете уникальный префикс для своего ключа, чтобы избежать сговоров.
Если вы не знаете, как добавить аннотацию к yaml, вы можете добавить ее вручную:
$kubectl annotate pod <pod-name> unique.prefix/for-my-key = "value"
Затем запустите $kubectl get po <pod-name> -o yaml, чтобы просмотреть аннотацию, которую вы добавили вручную, и скопируйте yaml в свою VCS.
Отклонение от курса - хороший пример, чтобы начать это понимать. Спасибо