Enforcing immutability of Kubernetes custom resource spec fields

6/24/2019

I'm using the Kubernetes golang operator sdk to implement an operator that manages RabbitMQ queues. I'm wondering if there's a way for k8s to enforce immutability of particular spec fields on my custom resource. I have the following golang struct which represents a rabbitMQ queue and some parameters to have it bind to a rabbitMQ exchange:

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

The reason why I want immutability, specifically for the VHost field, is because it's a parameter that's used to namespace a queue in rabbitMQ. If it were changed for an existing deployed queue, the k8s reconciler will fail to query rabbitMQ for the intended queue since it will be querying with a different vhost (effectively a different namespace), which could cause the creation of a new queue or an update of the wrong queue.

There are a few alternatives that I'm considering such as using the required ObjectMeta.Name field to contain both the concatenated vhost and the queuename to ensure that they are immutable for a deployed queue. Or somehow caching older specs within the operator (haven't figured out exactly how to do this yet) and doing a comparison of the old and current spec in the reconciler returning an error if VHost changes. However neither of these approaches seem ideal. Ideally if the operator framework could enforce immutability on the VHost field, that would be a simple approach to handling this.

-- wangdrew
kubernetes
kubernetes-operator
rabbitmq

2 Answers

6/24/2019

AFAIK this is not yet available to CRDs. Our approach is generally to use the object name as the default name of the object being controlled (vhost name in this case) so it just naturally works out okay.

-- coderanger
Source: StackOverflow

6/25/2019

This validation is possible by using the ValidatingAdmissionWebhook with future support coming via CRD's OpenAPI validation.

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

-- wangdrew
Source: StackOverflow