CRD Processing

These markers help control how the Kubernetes API server processes API requests involving your custom resources.

See Generating CRDs for examples.

Show Detailed Argument Help

// +structType

: string

specifies the level of atomicity of the struct;

i.e. whether each field in the struct is independent of the others, or all fields are treated as a single unit.

This is important for Server-Side Apply to correctly merge struct updates.

Possible values:

"granular": fields in the struct are independent of each other, and can be manipulated by different actors. This is the default behavior.
"atomic": all fields are treated as one unit. Any changes have to replace the entire struct.

Examples:

// Granular struct (default) - individual fields can be updated independently
// +structType=granular
type Config struct {
    Host string
    Port int
}

// Atomic struct - entire struct is replaced on update
// +structType=atomic
type Credentials struct {
    Username string
    Password string
}

: string

// +structType

: string

specifies the level of atomicity of the struct;

i.e. whether each field in the struct is independent of the others, or all fields are treated as a single unit.

This is important for Server-Side Apply to correctly merge struct updates.

Possible values:

"granular": fields in the struct are independent of each other, and can be manipulated by different actors. This is the default behavior.
"atomic": all fields are treated as one unit. Any changes have to replace the entire struct.

Examples:

// Granular struct (default) - individual fields can be updated independently
// +structType=granular
type Config struct {
    Host string
    Port int
}

// Atomic struct - entire struct is replaced on update
// +structType=atomic
type Credentials struct {
    Username string
    Password string
}

: string

// +mapType

: string

specifies the level of atomicity of the map;

i.e. whether each item in the map is independent of the others, or all fields are treated as a single unit.

This is important for Server-Side Apply to correctly merge map updates.

Possible values:

"granular": items in the map are independent of each other, and can be manipulated by different actors. This is the default behavior.
"atomic": all fields are treated as one unit. Any changes have to replace the entire map.

Examples:

// Granular map (default) - individual keys can be updated independently
// +mapType=granular
Labels map[string]string

// Atomic map - entire map is replaced on update
// +mapType=atomic
Config map[string]string

: string

// +mapType

: string

specifies the level of atomicity of the map;

i.e. whether each item in the map is independent of the others, or all fields are treated as a single unit.

This is important for Server-Side Apply to correctly merge map updates.

Possible values:

"granular": items in the map are independent of each other, and can be manipulated by different actors. This is the default behavior.
"atomic": all fields are treated as one unit. Any changes have to replace the entire map.

Examples:

// Granular map (default) - individual keys can be updated independently
// +mapType=granular
Labels map[string]string

// Atomic map - entire map is replaced on update
// +mapType=atomic
Config map[string]string

: string

// +listType

: string

specifies the type of data-structure that the list

represents (map, set, atomic).

This is important for Server-Side Apply to correctly merge list updates.

Possible data-structure types of a list are:

"map": it needs to have a key field, which will be used to build an associative list. A typical example is a the pod container list, which is indexed by the container name.
"set": Fields need to be "scalar", and there can be only one occurrence of each.
"atomic": All the fields in the list are treated as a single value, are typically manipulated together by the same actor.

Examples:

// Map list (associative list) - items are merged by key
// +listType=map
// +listMapKey=name
Containers []Container

// Set list - items must be unique scalars
// +listType=set
Tags []string

// Atomic list - entire list is replaced on update
// +listType=atomic
Args []string

: string

// +listType

: string

specifies the type of data-structure that the list

represents (map, set, atomic).

This is important for Server-Side Apply to correctly merge list updates.

Possible data-structure types of a list are:

"map": it needs to have a key field, which will be used to build an associative list. A typical example is a the pod container list, which is indexed by the container name.
"set": Fields need to be "scalar", and there can be only one occurrence of each.
"atomic": All the fields in the list are treated as a single value, are typically manipulated together by the same actor.

Examples:

// Map list (associative list) - items are merged by key
// +listType=map
// +listMapKey=name
Containers []Container

// Set list - items must be unique scalars
// +listType=set
Tags []string

// Atomic list - entire list is replaced on update
// +listType=atomic
Args []string

: string

// +listMapKey

: string

specifies the keys to map listTypes.

It indicates the index of a map list. They can be repeated if multiple keys must be used. It can only be used when ListType is set to map, and the keys should be scalar types.

Examples:

// Single key
// +listType=map
// +listMapKey=name
Containers []Container

// Composite key (multiple keys)
// +listType=map
// +listMapKey=name
// +listMapKey=protocol
Ports []Port

: string

// +listMapKey

: string

specifies the keys to map listTypes.

It indicates the index of a map list. They can be repeated if multiple keys must be used. It can only be used when ListType is set to map, and the keys should be scalar types.

Examples:

// Single key
// +listType=map
// +listMapKey=name
Containers []Container

// Composite key (multiple keys)
// +listType=map
// +listMapKey=name
// +listMapKey=protocol
Ports []Port

: string

// +kubebuilder:validation:items:XPreserveUnknownFields

for array items stops the apiserver from pruning fields which are not specified.

By default the apiserver drops unknown fields from the request payload during the decoding step. This marker stops the API server from doing so. It affects fields recursively, but switches back to normal pruning behaviour if nested properties or additionalProperties are specified in the schema. This can either be true or undefined. False is forbidden.