Kubebuilder: Is there a way to reject unknown fields in CR?

[functicons]

I noticed that by default, if there are unknown fields in CR, it doesn't fail, but simply ignore them. This is not consistent with the native resource types and error-prone. Wondering is there a way to enforce it? Thanks!

[camilamacedo86]

Could you please provide an example and how to reproduce it in order to illustrate your question?

[functicons]

Take the CronJob custom resource YAML as an example, if we add an undefined field e.g. foo in the spec, and try to apply the YAML, it doesn't fail.

[camilamacedo86]

What do you mean with undefined? Undefined where?
Also, when you are telling that you are adding, where you did this process?

Sorry, but for we help you assertively with, then we need to understand exactly what you are doing and what you expected. In this way, could you provide an example detailed as:

• Following the quickstart
• Then, add a new spec in the type.
• Then, run make install

[functicons]

With Kubebuilder, we define CRDs in go, e.g.

type CronJobSpec struct {
  Schedule string `json:"schedule"`
  ...
}

then we generate CRDs in YAML from the Go structs. Finally, when actually creating a CronJob, we need to create another YAML, e.g.

kind: CronJob
metadata:
  name: my-cronjob
spec:
  schedul: ...
  foo: ...

In this case, if I made a typo, schedul should be schedule, or I have an undefined field foo, these problems cannot be validated when I run kubectl apply -f my_cronjob.yaml. Undefined fields are simply ignored.

[camilamacedo86]

Hi @functicons,

Thanks for the clarifications. Let's go thought it.

The idea of Operators is to allow manage the resources dynamically and programmatically, because of this, we define the CRDs specs in the types.go file. Note that it allows us to use them as struct(objects) in the code implementation and perform operations to create/update/delete/read these resources in the platform by using the k8s API.

However, see that the Kubernetes API will not check the code in the types or typo issues when you apply the CR. You could indeed create and apply CR/CRD's without managing them via operators.

So, they are not undefined. They actually are defined when the CR/CRD is applied in the cluster and the API validates and persists it.

Could you please close this one or let us know if it still not clear for you?

[functicons]

Thanks for your info! But I was hoping to validate undefined fields with Admission Webhook or some declarative way when defining the CRD in go, just like we validate the value of defined fields.

[camilamacedo86]

/assign @camilamacedo86

[DirectXMan12]

I think what you're looking for is CRD pruning, which is effectively required for CRD v1 (it's called preserveUnknownFields).