Обеспечение неизменности полей спецификации пользовательских ресурсов Kubernetes

Я использую оператор Kubernetes golang sdk для реализации оператора, который управляет очередями RabbitMQ. Мне интересно, есть ли способ для k8s обеспечить неизменность определенных полей спецификации на моем пользовательском ресурсе. У меня есть следующая структура golang, которая представляет очередь rabbitMQ и некоторые параметры для ее привязки к обмену rabbitMQ:

type RmqQueueSpec struct {
    VHost string `json:"vhost,required"`
    Exchange string `json:"exchange,required"`
    RoutingKey string `json:"routingKey"`
    SecretConfig map[string]string `json:"secretConfig"`
}

Причина, по которой я хочу неизменности, особенно для VHost поле, потому что это параметр, который используется для пространства имен очереди в rabbitMQ. Если он был изменен для существующей развернутой очереди, то примирению k8s не удастся запросить у rabbitMQ предполагаемую очередь, поскольку он будет запрашивать другой vhost (фактически другое пространство имен), что может привести к созданию новой очереди или обновлению. неправильной очереди.

Есть несколько альтернатив, которые я рассматриваю, например, использование обязательного поля ObjectMeta.Name, которое должно содержать как сцепленный vhost, так и имя очереди, чтобы гарантировать их неизменность для развернутой очереди. Или как-то кешировать более старые спецификации внутри оператора (еще не выяснил, как это сделать) и выполнить сравнение старой и текущей спецификаций в согласователе, возвращая ошибку, если VHost изменения. Однако ни один из этих подходов не кажется идеальным. В идеале, если структура оператора может обеспечить неизменность на VHost поле, это был бы простой подход к решению этой проблемы.

Источник

2 ответа

Решение

AFAIK это еще не доступно для CRD. Наш подход, как правило, заключается в использовании имени объекта в качестве имени по умолчанию контролируемого объекта (в данном случае vhost name), так что оно, естественно, работает нормально.

Источник

Эта проверка возможна при использовании ValidatingAdmissionWebhook с будущей поддержкой, поступающей через проверку OpenAPI CRD.

https://github.com/operator-framework/operator-sdk/issues/1587 https://github.com/kubernetes/kubernetes/issues/65973

Источник
Другие вопросы по тегам