apiVersion
string

parameters.kubeblocks.io/v1alpha1

kind
string

ComponentParameter

metadata

Refer to the Kubernetes API documentation for the fields of the metadata field.

spec

status

apiVersion
string

parameters.kubeblocks.io/v1alpha1

kind
string

ParamConfigRenderer

metadata

Refer to the Kubernetes API documentation for the fields of the metadata field.

spec

status

apiVersion
string

parameters.kubeblocks.io/v1alpha1

kind
string

Parameter

metadata

Refer to the Kubernetes API documentation for the fields of the metadata field.

spec

status

apiVersion
string

parameters.kubeblocks.io/v1alpha1

kind
string

ParametersDefinition

metadata

Refer to the Kubernetes API documentation for the fields of the metadata field.

spec

status

processName

The name of the process.

"dotenv"

"hcl"

"ini"

"json"

"properties"

"props-plus"

"redis"

"toml"

"xml"

"yaml"

name

Specifies the config file name in the config template.

templateName

Specifies the name of the referenced componentTemplateSpec.

fileFormatConfig

Specifies the format of the configuration file and any associated parameters that are specific to the chosen format. Supported formats include ini, xml, yaml, json, hcl, dotenv, properties, and toml.

Each format may have its own set of parameters that can be configured. For instance, when using the ini format, you can specify the section name.

Example:

fileFormatConfig:
format: ini
iniConfig:
sectionName: mysqld

reRenderResourceTypes

Specifies whether the configuration needs to be re-rendered after v-scale or h-scale operations to reflect changes.

In some scenarios, the configuration may need to be updated to reflect the changes in resource allocation or cluster topology. Examples:

• Redis: adjust maxmemory after v-scale operation.

• MySQL: increase max connections after v-scale operation.

• Zookeeper: update zoo.cfg with new node addresses after h-scale operation.

clusterName

Specifies the name of the Cluster that this configuration is associated with.

componentName

Represents the name of the Component that this configuration pertains to.

configItemDetails

ConfigItemDetails is an array of ConfigTemplateItemDetail objects.

Each ConfigTemplateItemDetail corresponds to a configuration template, which is a ConfigMap that contains multiple configuration files. Each configuration file is stored as a key-value pair within the ConfigMap.

The ConfigTemplateItemDetail includes information such as:

• The configuration template (a ConfigMap)

• The corresponding ConfigConstraint (constraints and validation rules for the configuration)

• Volume mounts (for mounting the configuration files)

message

Provides a description of any abnormal status.

phase

Indicates the current status of the configuration item.

Possible values include “Creating”, “Init”, “Running”, “Pending”, “Merged”, “MergeFailed”, “FailedAndPause”, “Upgrading”, “Deleting”, “FailedAndRetry”, “Finished”.

observedGeneration

Represents the latest generation observed for this ClusterDefinition. It corresponds to the ConfigConstraint’s generation, which is updated by the API Server.

conditions

Provides detailed status information for opsRequest.

configurationStatus

Provides the status of each component undergoing reconfiguration.

componentName

Specifies the name of the Component.

parameters

Specifies the user-defined configuration template or parameters.

userConfigTemplates

Specifies the user-defined configuration template.

When provided, the importTemplateRef overrides the default configuration template specified in configSpec.templateRef. This allows users to customize the configuration template according to their specific requirements.

componentName

Specifies the name of the Component.

phase

Indicates the current status of the configuration item.

Possible values include “Creating”, “Init”, “Running”, “Pending”, “Merged”, “MergeFailed”, “FailedAndPause”, “Upgrading”, “Deleting”, “FailedAndRetry”, “Finished”.

parameterStatus

Describes the status of the component reconfiguring.

templateRef

Specifies the name of the referenced configuration template ConfigMap object.

namespace

Specifies the namespace of the referenced configuration template ConfigMap object. An empty namespace is equivalent to the “default” namespace.

policy

Defines the strategy for merging externally imported templates into component templates.

name

Defines the unique identifier of the configuration template.

It must be a string of maximum 63 characters, and can only include lowercase alphanumeric characters, hyphens, and periods. The name must start and end with an alphanumeric character.

payload

External controllers can trigger a configuration rerender by modifying this field.

Note: Currently, the payload field is opaque and its content is not interpreted by the system. Modifying this field will cause a rerender, regardless of the specific content of this field.

configSpec

Specifies the name of the configuration template (a ConfigMap), ConfigConstraint, and other miscellaneous options.

The configuration template is a ConfigMap that contains multiple configuration files. Each configuration file is stored as a key-value pair within the ConfigMap.

ConfigConstraint allows defining constraints and validation rules for configuration parameters. It ensures that the configuration adheres to certain requirements and limitations.

userConfigTemplates

Specifies the user-defined configuration template.

When provided, the importTemplateRef overrides the default configuration template specified in configSpec.templateRef. This allows users to customize the configuration template according to their specific requirements.

configFileParams

Specifies the user-defined configuration parameters.

When provided, the parameter values in configFileParams override the default configuration parameters. This allows users to override the default configuration according to their specific needs.

name

Specifies the name of the configuration template. It is a required field and must be a string of maximum 63 characters. The name should only contain lowercase alphanumeric characters, hyphens, or periods. It should start and end with an alphanumeric character.

phase

Indicates the current status of the configuration item.

Possible values include “Creating”, “Init”, “Running”, “Pending”, “Merged”, “MergeFailed”, “FailedAndPause”, “Upgrading”, “Deleting”, “FailedAndRetry”, “Finished”.

lastDoneRevision

Represents the last completed revision of the configuration item. This field is optional.

updateRevision

Represents the updated revision of the configuration item. This field is optional.

message

Provides a description of any abnormal status. This field is optional.

reconcileDetail

Provides detailed information about the execution of the configuration change. This field is optional.

name

Specifies the name of the field. It must be a string of maximum length 63. The name should match the regex pattern ^[a-z0-9]([a-z0-9\.\-]*[a-z0-9])?$.

mountPoint

Specifies the mount point of the Downward API volume.

items

Represents a list of files under the Downward API volume.

command

Specifies the command to be triggered when changes are detected in Downward API volume files. It relies on the inotify mechanism in the config-manager sidecar to monitor file changes.

scriptConfig

ScriptConfig object specifies a ConfigMap that contains script files that should be mounted inside the pod. The scripts are mounted as volumes and can be referenced and executed by the DownwardAction to perform specific tasks or configurations.

"all"

"dynamic"

"auto"

"http"

"sql"

"exec"

"tpl"

"signal"

FormatterAction

(Members of FormatterAction are embedded into this type.)

Each format may have its own set of parameters that can be configured. For instance, when using the ini format, you can specify the section name.

format

The config file format. Valid values are ini, xml, yaml, json, hcl, dotenv, properties and toml. Each format has its own characteristics and use cases.

• ini: is a text-based content with a structure and syntax comprising key–value pairs for properties, reference wiki: https://en.wikipedia.org/wiki/INI_file

• xml: refers to wiki: https://en.wikipedia.org/wiki/XML

• yaml: supports for complex data types and structures.

• json: refers to wiki: https://en.wikipedia.org/wiki/JSON

• hcl: The HashiCorp Configuration Language (HCL) is a configuration language authored by HashiCorp, reference url: https://www.linode.com/docs/guides/introduction-to-hcl/

• dotenv: is a plain text file with simple key–value pairs, reference wiki: https://en.wikipedia.org/wiki/Configuration_file#MS-DOS

• properties: a file extension mainly used in Java, reference wiki: https://en.wikipedia.org/wiki/.properties

• toml: refers to wiki: https://en.wikipedia.org/wiki/TOML

• props-plus: a file extension mainly used in Java, supports CamelCase(e.g: brokerMaxConnectionsPerIp)

iniConfig

Holds options specific to the ‘ini’ file format.

sectionName

A string that describes the name of the ini section.

"none"

"add"

"patch"

"replace"

componentDef

Specifies the ComponentDefinition custom resource (CR) that defines the Component’s characteristics and behavior.

serviceVersion

ServiceVersion specifies the version of the Service expected to be provisioned by this Component. The version should follow the syntax and semantics of the “Semantic Versioning” specification (http://semver.org/). If no version is specified, the latest available version will be used.

parametersDefs

Specifies the ParametersDefinition custom resource (CR) that defines the Component parameter’s schema and behavior.

configs

Specifies the configuration files.

observedGeneration

The most recent generation number of the ParamsDesc object that has been observed by the controller.

message

Provides additional information about the current phase.

phase

Specifies the status of the configuration template. When set to PDAvailablePhase, the ParamsDesc can be referenced by ComponentDefinition.

"RestoreToDefault"

"Reset"

deletedMethod

Specifies the method to handle the deletion of a parameter. If set to “RestoreToDefault”, the parameter will be restored to its default value, which requires engine support, such as pg. If set to “Reset”, the parameter will be re-rendered through the configuration template.

defaultValue

Specifies the value to use if DeletedMethod is RestoreToDefault. Example: pg SET configuration_parameter TO DEFAULT;

"Creating"

"Deleting"

"FailedAndPause"

"FailedAndRetry"

"Finished"

"Init"

"MergeFailed"

"Merged"

"Pending"

"Running"

"Upgrading"

clusterName

Specifies the name of the Cluster resource that this operation is targeting.

componentParameters

Lists ComponentParametersSpec objects, each specifying a Component and its parameters and template updates.

message

Provides a description of any abnormal status.

phase

Indicates the current status of the configuration item.

Possible values include “Creating”, “Init”, “Running”, “Pending”, “Merged”, “MergeFailed”, “FailedAndPause”, “Upgrading”, “Deleting”, “FailedAndRetry”, “Finished”.

observedGeneration

Represents the latest generation observed for this ClusterDefinition. It corresponds to the ConfigConstraint’s generation, which is updated by the API Server.

componentReconfiguringStatus

Records the status of a reconfiguring operation if opsRequest.spec.type equals to “Reconfiguring”.

fileName

Specifies the config file name in the config template.

parametersSchema

Defines a list of parameters including their names, default values, descriptions, types, and constraints (permissible values or the range of valid values).

reloadAction

Specifies the dynamic reload (dynamic reconfiguration) actions supported by the engine. When set, the controller executes the scripts defined in these actions to handle dynamic parameter updates.

Dynamic reloading is triggered only if both of the following conditions are met:

1. The modified parameters are listed in the dynamicParameters field. If dynamicParameterSelectedPolicy is set to “all”, modifications to staticParameters can also trigger a reload.

2. reloadAction is set.

If reloadAction is not set or the modified parameters are not listed in dynamicParameters, dynamic reloading will not be triggered.

Example:

dynamicReloadAction:
tplScriptTrigger:
namespace: kb-system
scriptConfigMapRef: mysql-reload-script
sync: true

downwardAPIChangeTriggeredActions

Specifies a list of actions to execute specified commands based on Pod labels.

It utilizes the K8s Downward API to mount label information as a volume into the pod. The ‘config-manager’ sidecar container watches for changes in the role label and dynamically invoke registered commands (usually execute some SQL statements) when a change is detected.

It is designed for scenarios where:

• Replicas with different roles have different configurations, such as Redis primary & secondary replicas.

• After a role switch (e.g., from secondary to primary), some changes in configuration are needed to reflect the new role.

deletedPolicy

Specifies the policy when parameter be removed.

mergeReloadAndRestart

Indicates whether to consolidate dynamic reload and restart actions into a single restart.

• If true, updates requiring both actions will result in only a restart, merging the actions.

• If false, updates will trigger both actions executed sequentially: first dynamic reload, then restart.

This flag allows for more efficient handling of configuration changes by potentially eliminating an unnecessary reload step.

reloadStaticParamsBeforeRestart

Configures whether the dynamic reload specified in reloadAction applies only to dynamic parameters or to all parameters (including static parameters).

• false (default): Only modifications to the dynamic parameters listed in dynamicParameters will trigger a dynamic reload.

• true: Modifications to both dynamic parameters listed in dynamicParameters and static parameters listed in staticParameters will trigger a dynamic reload. The “all” option is for certain engines that require static parameters to be set via SQL statements before they can take effect on restart.

staticParameters

List static parameters. Modifications to any of these parameters require a restart of the process to take effect.

dynamicParameters

List dynamic parameters. Modifications to these parameters trigger a configuration reload without requiring a process restart.

immutableParameters

Lists the parameters that cannot be modified once set. Attempting to change any of these parameters will be ignored.

observedGeneration

The most recent generation number of the ParamsDesc object that has been observed by the controller.

phase

Specifies the status of the configuration template. When set to PDAvailablePhase, the ParamsDesc can be referenced by ComponentDefinition.

conditions

Represents a list of detailed status of the ParametersDescription object.

This field is crucial for administrators and developers to monitor and respond to changes within the ParametersDescription. It provides a history of state transitions and a snapshot of the current state that can be used for automated logic or direct inspection.

"Available"

"Deleting"

"Unavailable"

content

Holds the configuration keys and values. This field is a workaround for issues found in kubebuilder and code-generator. Refer to https://github.com/kubernetes-sigs/kubebuilder/issues/528 and https://github.com/kubernetes/code-generator/issues/50 for more details.

Represents the content of the configuration file.

parameters

Represents the updated parameters for a single configuration file.

topLevelKey

Specifies the top-level key in the ‘configSchema.cue’ that organizes the validation rules for parameters. This key must exist within the CUE script defined in ‘configSchema.cue’.

cue

Hold a string that contains a script written in CUE language that defines a list of configuration items. Each item is detailed with its name, default value, description, type (e.g. string, integer, float), and constraints (permissible values or the valid range of values).

CUE (Configure, Unify, Execute) is a declarative language designed for defining and validating complex data configurations. It is particularly useful in environments like K8s where complex configurations and validation rules are common.

This script functions as a validator for user-provided configurations, ensuring compliance with the established specifications and constraints.

schemaInJSON

Generated from the ‘cue’ field and transformed into a JSON format.

policy

Represents the policy applied during the most recent execution.

execResult

Represents the outcome of the most recent execution.

currentRevision

Represents the current revision of the configuration item.

succeedCount

Represents the number of pods where configuration changes were successfully applied.

expectedCount

Represents the total number of pods that require execution of configuration changes.

errMessage

Represents the error message generated when the execution of configuration changes fails.

ConfigTemplateItemDetailStatus

(Members of ConfigTemplateItemDetailStatus are embedded into this type.)

updatedParameters

Contains the updated parameters.

userConfigTemplates

Specifies the user-defined configuration template.

When provided, the importTemplateRef overrides the default configuration template specified in configSpec.templateRef. This allows users to customize the configuration template according to their specific requirements.

unixSignalTrigger

Used to trigger a reload by sending a specific Unix signal to the process.

shellTrigger

Allows to execute a custom shell script to reload the process.

tplScriptTrigger

Enables reloading process using a Go template script.

autoTrigger

Automatically perform the reload when specified conditions are met.

targetPodSelector

Used to match labels on the pod to determine whether a dynamic reload should be performed.

In some scenarios, only specific pods (e.g., primary replicas) need to undergo a dynamic reload. The reloadedPodSelector allows you to specify label selectors to target the desired pods for the reload process.

If the reloadedPodSelector is not specified or is nil, all pods managed by the workload will be considered for the dynamic reload.

"asyncReload"

"dynamicReloadBeginRestart"

"none"

"restartContainer"

"restart"

"rolling"

"syncReload"

"hscale"

"tls"

"vscale"

"shardingHScale"

scriptConfigMapRef

Specifies the reference to the ConfigMap containing the scripts.

namespace

Specifies the namespace for the ConfigMap. If not specified, it defaults to the “default” namespace.

command

Specifies the command to execute in order to reload the process. It should be a valid shell command.

sync

Determines the synchronization mode of parameter updates with “config-manager”.

• ‘True’: Executes reload actions synchronously, pausing until completion.

• ‘False’: Executes reload actions asynchronously, without waiting for completion.

batchReload

Controls whether parameter updates are processed individually or collectively in a batch:

• ‘True’: Processes all changes in one batch reload.

• ‘False’: Processes each change individually.

Defaults to ‘False’ if unspecified.

batchParamsFormatterTemplate

Specifies a Go template string for formatting batch input data. It’s used when batchReload is ‘True’ to format data passed into STDIN of the script. The template accesses key-value pairs of updated parameters via the ‘$’ variable. This allows for custom formatting of the input data.

Example template:

batchParamsFormatterTemplate: |-
{{- range $pKey, $pValue := $ }}
{{ printf "%s:%s" $pKey $pValue }}
{{- end }}

This example generates batch input data in a key

key1

key2

key3

If not specified, the default format is key=value, sorted by keys, for each updated parameter.

key1=value1
key2=value2
key3=value3

toolsSetup

Specifies the tools container image used by ShellTrigger for dynamic reload. If the dynamic reload action is triggered by a ShellTrigger, this field is required. This image must contain all necessary tools for executing the ShellTrigger scripts.

Usually the specified image is referenced by the init container, which is then responsible for copy the tools from the image to a bin volume. This ensures that the tools are available to the ‘config-manager’ sidecar.

scriptConfig

ScriptConfig object specifies a ConfigMap that contains script files that should be mounted inside the pod. The scripts are mounted as volumes and can be referenced and executed by the dynamic reload.

"SIGABRT"

"SIGALRM"

"SIGBUS"

"SIGCHLD"

"SIGCONT"

"SIGFPE"

"SIGHUP"

"SIGILL"

"SIGINT"

"SIGIO"

"SIGKILL"

"SIGPIPE"

"SIGPROF"

"SIGPWR"

"SIGQUIT"

"SIGSEGV"

"SIGSTKFLT"

"SIGSTOP"

"SIGSYS"

"SIGTERM"

"SIGTRAP"

"SIGTSTP"

"SIGTTIN"

"SIGTTOU"

"SIGURG"

"SIGUSR1"

"SIGUSR2"

"SIGVTALRM"

"SIGWINCH"

"SIGXCPU"

"SIGXFSZ"

ScriptConfig

(Members of ScriptConfig are embedded into this type.)

Specifies the ConfigMap that contains the script to be executed for reload.

sync

Determines whether parameter updates should be synchronized with the “config-manager”. Specifies the controller’s reload strategy:

• If set to ‘True’, the controller executes the reload action in synchronous mode, pausing execution until the reload completes.

• If set to ‘False’, the controller executes the reload action in asynchronous mode, updating the ConfigMap without waiting for the reload process to finish.

name

Specifies the name of the init container.

asContainerImage

Indicates whether the tool image should be used as the container image for a sidecar. This is useful for large tool images, such as those for C++ tools, which may depend on numerous libraries (e.g., *.so files).

If enabled, the tool image is deployed as a sidecar container image.

Examples:

toolsSetup::
mountPoint: /kb_tools
toolConfigs:

name: kb-tools
asContainerImage: true
image:  apecloud/oceanbase:4.2.0.0-100010032023083021

generated containers:

initContainers:

name: install-config-manager-tool
image: apecloud/kubeblocks-tools:${version}
command:

cp
/bin/config_render
/opt/tools
volumemounts:
name: kb-tools
mountpath: /opt/tools
containers:


name: config-manager
image: apecloud/oceanbase:4.2.0.0-100010032023083021
imagePullPolicy: IfNotPresent
command:

/opt/tools/reloader
--log-level
info
--operator-update-enable
--tcp
"9901"
--config
/opt/config-manager/config-manager.yaml
volumemounts:
name: kb-tools
mountpath: /opt/tools

image

Specifies the tool container image.

command

Specifies the command to be executed by the init container.

mountPoint

Specifies the directory path in the container where the tools-related files are to be copied. This field is typically used with an emptyDir volume to ensure a temporary, empty directory is provided at pod creation.

toolConfigs

Specifies a list of settings of init containers that prepare tools for dynamic reload.

signal

Specifies a valid Unix signal to be sent. For a comprehensive list of all Unix signals, see: ../../pkg/configuration/configmap/handler.go

processName

Identifies the name of the process to which the Unix signal will be sent.