Обеспечение неизменности полей спецификации пользовательских ресурсов Kubernetes - PullRequest
1 голос
/ 24 июня 2019

Я использую оператор 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 ]

0 голосов
/ 25 июня 2019

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

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

0 голосов
/ 24 июня 2019

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

...