"None"

None implies no access.

"ReadWrite"

ReadWrite permits both read and write operations.

"Readonly"

Readonly allows only read operations.

"kbadmin"

"kbdataprotection"

"kbmonitoring"

"kbprobe"

"kbreplicator"

Specifies the container image to be used for running the Action.

When specified, a dedicated container will be created using this image to execute the Action. This field is mutually exclusive with the `container` field; only one of them should be provided.

This field cannot be updated.

Defines the command to run.

This field cannot be updated.

Specifies the HTTP request to perform.

This field cannot be updated.

Note: HTTPAction is to be implemented in future version.

Represents a list of environment variables that will be injected into the container. These variables enable the container to adapt its behavior based on the environment it’s running in.

This field cannot be updated.

Defines the criteria used to select the target Pod(s) for executing the Action. This is useful when there is no default target replica identified. It allows for precise control over which Pod(s) the Action should run in.

This field cannot be updated.

Note: This field is reserved for future use and is not currently active.

Used in conjunction with the `targetPodSelector` field to refine the selection of target pod(s) for Action execution. The impact of this field depends on the `targetPodSelector` value:

• When `targetPodSelector` is set to `Any` or `All`, this field will be ignored.
• When `targetPodSelector` is set to `Role`, only those replicas whose role matches the `matchingKey` will be selected for the Action.

This field cannot be updated.

Note: This field is reserved for future use and is not currently active.

Defines the name of the container within the target Pod where the action will be executed.

This name must correspond to one of the containers defined in `componentDefinition.spec.runtime`. If this field is not specified, the default behavior is to use the first container listed in `componentDefinition.spec.runtime`.

This field cannot be updated.

Note: This field is reserved for future use and is not currently active.

Specifies the maximum duration in seconds that the Action is allowed to run.

If the Action does not complete within this time frame, it will be terminated.

This field cannot be updated.

Defines the strategy to be taken when retrying the Action after a failure.

It specifies the conditions under which the Action should be retried and the limits to apply, such as the maximum number of retries and backoff strategy.

This field cannot be updated.

Specifies the state that the cluster must reach before the Action is executed. Currently, this is only applicable to the `postProvision` action.

The conditions are as follows:

• `Immediately`: Executed right after the Component object is created. The readiness of the Component and its resources is not guaranteed at this stage.
• `RuntimeReady`: The Action is triggered after the Component object has been created and all associated runtime resources (e.g. Pods) are in a ready state.
• `ComponentReady`: The Action is triggered after the Component itself is in a ready state. This process does not affect the readiness state of the Component or the Cluster.
• `ClusterReady`: The Action is executed after the Cluster is in a ready state. This execution does not alter the Component or the Cluster’s state of readiness.

This field cannot be updated.

Represents the name of the task.

Represents the namespace where the task is deployed.

Indicates the current status of the task, including “Processing”, “Failed”, “Succeed”.

The name of the Pod that the task is associated with or operates on.

The count of retry attempts made for this task.

"Failed"

"Processing"

"Succeed"

Specifies the anti-affinity level of Pods within a Component. It determines how pods should be spread across nodes to improve availability and performance. It can have the following values: `Preferred` and `Required`. The default value is `Preferred`.

Represents the key of node labels used to define the topology domain for Pod anti-affinity and Pod spread constraints.

In K8s, a topology domain is a set of nodes that have the same value for a specific label key. Nodes with labels containing any of the specified TopologyKeys and identical values are considered to be in the same topology domain.

Note: The concept of topology in the context of K8s TopologyKeys is different from the concept of topology in the ClusterDefinition.

When a Pod has anti-affinity or spread constraints specified, Kubernetes will attempt to schedule the Pod on nodes with different values for the specified TopologyKeys. This ensures that Pods are spread across different topology domains, promoting high availability and reducing the impact of node failures.

Some well-known label keys, such as `kubernetes.io/hostname` and `topology.kubernetes.io/zone`, are often used as TopologyKey. These keys represent the hostname and zone of a node, respectively. By including these keys in the TopologyKeys list, Pods will be spread across nodes with different hostnames or zones.

In addition to the well-known keys, users can also specify custom label keys as TopologyKeys. This allows for more flexible and custom topology definitions based on the specific needs of the application or environment.

The TopologyKeys field is a slice of strings, where each string represents a label key. The order of the keys in the slice does not matter.

Indicates the node labels that must be present on nodes for pods to be scheduled on them. It is a map where the keys are the label keys and the values are the corresponding label values. Pods will only be scheduled on nodes that have all the specified labels with the corresponding values.

For example, if NodeLabels is set to {“nodeType”: “ssd”, “environment”: “production”}, pods will only be scheduled on nodes that have both the “nodeType” label with value “ssd” and the “environment” label with value “production”.

This field allows users to control Pod placement based on specific node labels. It can be used to ensure that Pods are scheduled on nodes with certain characteristics, such as specific hardware (e.g., SSD), environment (e.g., production, staging), or any other custom labels assigned to nodes.

Determines the level of resource isolation between Pods. It can have the following values: `SharedNode` and `DedicatedNode`.

• SharedNode: Allow that multiple Pods may share the same node, which is the default behavior of K8s.
• DedicatedNode: Each Pod runs on a dedicated node, ensuring that no two Pods share the same node. In other words, if a Pod is already running on a node, no other Pods will be scheduled on that node. Which provides a higher level of isolation and resource guarantee for Pods.

The default value is `SharedNode`.

"node"

AvailabilityPolicyNode specifies that resources should be distributed across different nodes within the same zone. This policy aims to provide resilience against node failures, ensuring that the failure of a single node does not impact the overall service availability.

"none"

AvailabilityPolicyNone specifies that no specific availability policy is applied. Resources may not be explicitly distributed for high availability, potentially concentrating them in a single zone or node based on other scheduling decisions.

"zone"

AvailabilityPolicyZone specifies that resources should be distributed across different availability zones. This policy aims to ensure high availability and protect against zone failures, spreading the resources to reduce the risk of simultaneous downtime.

Specifies the name of the Backup custom resource.

Indicates the name of the BackupPolicy applied to perform this Backup.

Specifies the name of BackupMethod. The specified BackupMethod must be defined in the BackupPolicy.

Determines whether the backup contents stored in backup repository should be deleted when the Backup custom resource is deleted. Supported values are `Retain` and `Delete`. - `Retain` means that the backup content and its physical snapshot on backup repository are kept. - `Delete` means that the backup content and its physical snapshot on backup repository are deleted.

Determines the duration for which the Backup custom resources should be retained.

The controller will automatically remove all Backup objects that are older than the specified RetentionPeriod. For example, RetentionPeriod of `30d` will keep only the Backup objects of last 30 days. Sample duration format:

• years: 2y
• months: 6mo
• days: 30d
• hours: 12h
• minutes: 30m

You can also combine the above durations. For example: 30d12h30m. If not set, the Backup objects will be kept forever.

If the `deletionPolicy` is set to ‘Delete’, then the associated backup data will also be deleted along with the Backup object. Otherwise, only the Backup custom resource will be deleted.

If the specified BackupMethod is incremental, `parentBackupName` is required.

(Members of `BackupMethod` are embedded into this type.)

Specifies the name of dataprotection.BackupMethod.

If set, specifies the method for selecting the replica to be backed up using the criteria defined here. If this field is not set, the selection method specified in `backupPolicy.target` is used.

This field provides a way to override the global `backupPolicy.target` setting for specific BackupMethod.

Specifies a mapping of an environment variable key to the appropriate version of the tool image required for backups, as determined by ClusterVersion and ComponentDefinition. The environment variable is then injected into the container executing the backup task.

Specifies the name of ClusterComponentDefinition defined in the ClusterDefinition. Must comply with the IANA Service Naming rule.

Deprecated since v0.9, should use `componentDefs` instead. This field is maintained for backward compatibility and its use is discouraged. Existing usage should be updated to the current preferred approach to avoid compatibility issues in future releases.

Specifies the name of the ComponentDefinition. Each name in the list can represent an exact name, a name prefix, or a regular expression pattern.

For example:

• “mysql-8.0.30-v1alpha1”: Matches the exact name “mysql-8.0.30-v1alpha1”
• “mysql-8.0.30”: Matches all names starting with “mysql-8.0.30”
• ”^mysql-8.0.\d{1,2}$“: Matches all names starting with “mysql-8.0.” followed by one or two digits.

Defines the selection criteria of instance to be backed up, and the connection credential to be used during the backup process.

Defines the execution plans for backup tasks, specifying when and how backups should occur, and the retention period of backup files.

Defines an array of BackupMethods to be used.

Specifies the maximum number of retry attempts for a backup before it is considered a failure.

The metadata for the BackupPolicyTemplate object, including name, namespace, labels, and annotations.

Defines the desired state of the BackupPolicyTemplate.

Populated by the system, it represents the current information about the BackupPolicyTemplate.

Specifies the name of a ClusterDefinition. This is an immutable attribute that cannot be changed after creation. And this field is deprecated since v0.9, consider using the ComponentDef instead.

Represents an array of BackupPolicy templates, with each template corresponding to a specified ComponentDefinition or to a group of ComponentDefinitions that are different versions of definitions of the same component.

Specifies a unique identifier for the BackupPolicyTemplate.

This identifier will be used as the suffix of the name of automatically generated BackupPolicy. This prevents unintended overwriting of BackupPolicies due to name conflicts when multiple BackupPolicyTemplates are present. For instance, using “backup-policy” for regular backups and “backup-policy-hscale” for horizontal-scale ops can differentiate the policies.

Refers to a reference backup that needs to be restored.

"apecloud-postgresql"

"custom"

"etcd"

"mongodb"

"mysql"

"oceanbase"

"official-postgresql"

"polardbx"

"postgresql"

"redis"

"unknown"

"wesql"

The maximum count of vcpu cores, [Min, Max] defines a range for valid vcpu cores, and the value in this range must be multiple times of Step. It’s useful to define a large number of valid values without defining them one by one. Please see the documentation for Step for some examples. If Slots is specified, Max, Min, and Step are ignored

The minimum count of vcpu cores, [Min, Max] defines a range for valid vcpu cores, and the value in this range must be multiple times of Step. It’s useful to define a large number of valid values without defining them one by one. Please see the documentation for Step for some examples. If Slots is specified, Max, Min, and Step are ignored

The minimum granularity of vcpu cores, [Min, Max] defines a range for valid vcpu cores and the value in this range must be multiple times of Step. For example: 1. Min is 2, Max is 8, Step is 2, and the valid vcpu core is {2, 4, 6, 8}. 2. Min is 0.5, Max is 2, Step is 0.5, and the valid vcpu core is {0.5, 1, 1.5, 2}.

The valid vcpu cores, it’s useful if you want to define valid vcpu cores explicitly. If Slots is specified, Max, Min, and Step are ignored

Specifies the name of the ComponentClassDefinition.

Defines the name of the class that is defined in the ComponentClassDefinition.

Specifies whether automated backup is enabled for the Cluster.

Determines the duration to retain backups. Backups older than this period are automatically removed.

For example, RetentionPeriod of `30d` will keep only the backups of last 30 days. Sample duration format:

• years: 2y
• months: 6mo
• days: 30d
• hours: 12h
• minutes: 30m

You can also combine the above durations. For example: 30d12h30m. Default value is 7d.

Specifies the backup method to use, as defined in backupPolicy.

The cron expression for the schedule. The timezone is in UTC. See https://en.wikipedia.org/wiki/Cron.

Specifies the maximum time in minutes that the system will wait to start a missed backup job. If the scheduled backup time is missed for any reason, the backup job must start within this deadline. Values must be between 0 (immediate execution) and 1440 (one day).

Specifies the name of the backupRepo. If not set, the default backupRepo will be used.

Specifies whether to enable point-in-time recovery.

Specifies the backup method to use, if not set, use the first continuous method.

Specifies whether to enable incremental backup.

The cron expression for the incremental backup schedule. The timezone is in UTC. See https://en.wikipedia.org/wiki/Cron.

This name could be used as default name of `cluster.spec.componentSpecs.name`, and needs to conform with same validation rules as `cluster.spec.componentSpecs.name`, currently complying with IANA Service Naming rule. This name will apply to cluster objects as the value of label “apps.kubeblocks.io/component-name”.

Description of the component definition.

Defines the type of the workload.

• `Stateless` describes stateless applications.
• `Stateful` describes common stateful applications.
• `Consensus` describes applications based on consensus protocols, such as raft and paxos.
• `Replication` describes applications based on the primary-secondary data replication protocol.

Defines well-known database component name, such as mongos(mongodb), proxy(redis), mariadb(mysql).

Defines the template of configurations.

Defines the template of scripts.

Settings for health checks.

Specify the logging files which can be observed and configured by cluster users.

Defines the pod spec template of component.

Defines the service spec.

Defines spec for `Stateless` workloads.

Defines spec for `Stateful` workloads.

Defines spec for `Consensus` workloads. It’s required if the workload type is `Consensus`.

Defines spec for `Replication` workloads.

Defines workload spec of this component. From KB 0.7.0, RSM(InstanceSetSpec) will be the underlying CR which powers all kinds of workload in KB. RSM is an enhanced stateful workload extension dedicated for heavy-state workloads like databases.

Defines the behavior of horizontal scale.

Defines system accounts needed to manage the component, and the statement to create them.

Used to describe the purpose of the volumes mapping the name of the VolumeMounts in the PodSpec.Container field, such as data volume, log volume, etc. When backing up the volume, the volume can be correctly backed up according to the volumeType.

For example:

• `name: data, type: data` means that the volume named `data` is used to store `data`.
• `name: binlog, type: log` means that the volume named `binlog` is used to store `log`.

NOTE: When volumeTypes is not defined, the backup function will not be supported, even if a persistent volume has been specified.

Used for custom label tags which you want to add to the component resources.

Defines command to do switchover. In particular, when workloadType=Replication, the command defined in switchoverSpec will only be executed under the condition of cluster.componentSpecs[x].SwitchPolicy.type=Noop.

Defines the command to be executed when the component is ready, and the command will only be executed once after the component becomes ready.

Defines settings to do volume protect.

Used to inject values from other components into the current component. Values will be saved and updated in a configmap and mounted to the current component.

Used to declare the service reference of the current component.

Defines the metrics exporter.

Deprecated since v0.9 monitor is monitoring config which provided by provider.

"Abnormal"

AbnormalClusterCompPhase indicates the component has more than zero replicas, but there are some failed pods. The component is functioning, but it is in a fragile state.

"Creating"

CreatingClusterCompPhase indicates the component is being created.

"Deleting"

DeletingClusterCompPhase indicates the component is currently being deleted.

"Failed"

FailedClusterCompPhase indicates the component has more than zero replicas, but there are some failed pods. The component is not functioning.

"Running"

RunningClusterCompPhase indicates the component has more than zero replicas, and all pods are up-to-date and in a ‘Running’ state.

"Stopped"

StoppedClusterCompPhase indicates the component has zero replicas, and all pods have been deleted.

"Stopping"

StoppingClusterCompPhase indicates the component has zero replicas, and there are pods that are terminating.

"Updating"

UpdatingClusterCompPhase indicates the component has more than zero replicas, and there are no failed pods, it is currently being updated.

References the ComponentService name defined in the `componentDefinition.spec.services[*].name`.

Determines how the Service is exposed. Valid options are `ClusterIP`, `NodePort`, and `LoadBalancer`.

• `ClusterIP` allocates a Cluster-internal IP address for load-balancing to endpoints. Endpoints are determined by the selector or if that is not specified, they are determined by manual construction of an Endpoints object or EndpointSlice objects.
• `NodePort` builds on ClusterIP and allocates a port on every node which routes to the same endpoints as the ClusterIP.
• `LoadBalancer` builds on NodePort and creates an external load-balancer (if supported in the current cloud) which routes to the same endpoints as the ClusterIP.

Note: although K8s Service type allows the ‘ExternalName’ type, it is not a valid option for ClusterComponentService.

For more info, see: https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types.

If ServiceType is LoadBalancer, cloud provider related parameters can be put here. More info: https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer.

Indicates whether to generate individual Services for each Pod. If set to true, a separate Service will be created for each Pod in the Cluster.

Specifies the Component’s name. It’s part of the Service DNS name and must comply with the IANA service naming rule. The name is optional when ClusterComponentSpec is used as a template (e.g., in `shardingSpec`), but required otherwise.

References a ClusterComponentDefinition defined in the `clusterDefinition.spec.componentDef` field. Must comply with the IANA service naming rule.

Deprecated since v0.9, because defining Components in `clusterDefinition.spec.componentDef` field has been deprecated. This field is replaced by the `componentDef` field, use `componentDef` instead. This field is maintained for backward compatibility and its use is discouraged. Existing usage should be updated to the current preferred approach to avoid compatibility issues in future releases.

Specifies the exact name, name prefix, or regular expression pattern for matching the name of the ComponentDefinition custom resource (CR) that defines the Component’s characteristics and behavior.

If both `componentDefRef` and `componentDef` are provided, the `componentDef` will take precedence over `componentDefRef`.

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.

References the class defined in ComponentClassDefinition.

Deprecated since v0.9. This field is maintained for backward compatibility and its use is discouraged. Existing usage should be updated to the current preferred approach to avoid compatibility issues in future releases.

Defines a list of ServiceRef for a Component, enabling access to both external services and Services provided by other Clusters.

Types of services:

• External services: Not managed by KubeBlocks or managed by a different KubeBlocks operator; Require a ServiceDescriptor for connection details.
• Services provided by a Cluster: Managed by the same KubeBlocks operator; identified using Cluster, Component and Service names.

ServiceRefs with identical `serviceRef.name` in the same Cluster are considered the same.

Example:

serviceRefs:
  - name: "redis-sentinel"
    serviceDescriptor:
      name: "external-redis-sentinel"
  - name: "postgres-cluster"
    clusterServiceSelector:
      cluster: "my-postgres-cluster"
      service:
        component: "postgresql"

The example above includes ServiceRefs to an external Redis Sentinel service and a PostgreSQL Cluster.

Specifies which types of logs should be collected for the Component. The log types are defined in the `componentDefinition.spec.logConfigs` field with the LogConfig entries.

The elements in the `enabledLogs` array correspond to the names of the LogConfig entries. For example, if the `componentDefinition.spec.logConfigs` defines LogConfig entries with names “slow_query_log” and “error_log”, you can enable the collection of these logs by including their names in the `enabledLogs` array:

enabledLogs:
- slow_query_log
- error_log

Specifies Labels to override or add for underlying Pods, PVCs, Account & TLS Secrets, Services Owned by Component.

Specifies Annotations to override or add for underlying Pods, PVCs, Account & TLS Secrets, Services Owned by Component.

List of environment variables to add. These environment variables will be placed after the environment variables declared in the Pod.

Specifies the desired number of replicas in the Component for enhancing availability and durability, or load balancing.

Specifies a group of affinity scheduling rules for the Component. It allows users to control how the Component’s Pods are scheduled onto nodes in the K8s cluster.

Allows Pods to be scheduled onto nodes with matching taints. Each toleration in the array allows the Pod to tolerate node taints based on specified `key`, `value`, `effect`, and `operator`.

• The `key`, `value`, and `effect` identify the taint that the toleration matches.
• The `operator` determines how the toleration matches the taint.

Pods with matching tolerations are allowed to be scheduled on tainted nodes, typically reserved for specific purposes.

Specifies the scheduling policy for the component.

Specifies the resources required by the Component. It allows defining the CPU, memory requirements and limits for the Component’s containers.

Specifies a list of PersistentVolumeClaim templates that represent the storage requirements for the Component. Each template specifies the desired characteristics of a persistent volume, such as storage class, size, and access modes. These templates are used to dynamically provision persistent volumes for the Component.

List of volumes to override.

Overrides services defined in referenced ComponentDefinition and expose endpoints that can be accessed by clients.

Overrides system accounts defined in the referenced `ComponentDefinition`.

Defines the strategy for switchover and failover when workloadType is Replication.

Deprecated since v0.9. This field is maintained for backward compatibility and its use is discouraged. Existing usage should be updated to the current preferred approach to avoid compatibility issues in future releases.

A boolean flag that indicates whether the Component should use Transport Layer Security (TLS) for secure communication. When set to true, the Component will be configured to use TLS encryption for its network connections. This ensures that the data transmitted between the Component and its clients or other Components is encrypted and protected from unauthorized access. If TLS is enabled, the Component may require additional configuration, such as specifying TLS certificates and keys, to properly set up the secure communication channel.

Specifies the configuration for the TLS certificates issuer. It allows defining the issuer name and the reference to the secret containing the TLS certificates and key. The secret should contain the CA certificate, TLS certificate, and private key in the specified keys. Required when TLS is enabled.

Specifies the name of the ServiceAccount required by the running Component. This ServiceAccount is used to grant necessary permissions for the Component’s Pods to interact with other Kubernetes resources, such as modifying Pod labels or sending events.

Defaults: To perform certain operational tasks, agent sidecars running in Pods require specific RBAC permissions. The service account will be bound to a default role named “kubeblocks-cluster-pod-role” which is installed together with KubeBlocks. If not specified, KubeBlocks automatically assigns a default ServiceAccount named “kb-{cluster.name}”

Future Changes: Future versions might change the default ServiceAccount creation strategy to one per Component, potentially revising the naming to “kb-{cluster.name}-{component.name}”.

Users can override the automatic ServiceAccount assignment by explicitly setting the name of an existed ServiceAccount in this field.

Defines the update strategy for the Component.

Deprecated since v0.9. This field is maintained for backward compatibility and its use is discouraged. Existing usage should be updated to the current preferred approach to avoid compatibility issues in future releases.

Indicates the InstanceUpdateStrategy that will be employed to update Pods in the InstanceSet when a revision is made to Template.

Controls the concurrency of pods during initial scale up, when replacing pods on nodes, or when scaling down. It only used when `PodManagementPolicy` is set to `Parallel`. The default Concurrency is 100%.

PodUpdatePolicy indicates how pods should be updated

• `StrictInPlace` indicates that only allows in-place upgrades. Any attempt to modify other fields will be rejected.
• `PreferInPlace` indicates that we will first attempt an in-place upgrade of the Pod. If that fails, it will fall back to the ReCreate, where pod will be recreated.
• `Recreate` indicates that recreate the Pod no matter what fields being updated. Default value is “PreferInPlace”

Allows users to specify custom ConfigMaps and Secrets to be mounted as volumes in the Cluster’s Pods. This is useful in scenarios where users need to provide additional resources to the Cluster, such as:

• Mounting custom scripts or configuration files during Cluster startup.
• Mounting Secrets as volumes to provide sensitive information, like S3 AK/SK, to the Cluster.

Allows for the customization of configuration values for each instance within a Component. An instance represent a single replica (Pod and associated K8s resources like PVCs, Services, and ConfigMaps). While instances typically share a common configuration as defined in the ClusterComponentSpec, they can require unique settings in various scenarios:

For example: - A database Component might require different resource allocations for primary and secondary instances, with primaries needing more resources. - During a rolling upgrade, a Component may first update the image for one or a few instances, and then update the remaining instances after verifying that the updated instances are functioning correctly.

InstanceTemplate allows for specifying these unique configurations per instance. Each instance’s name is constructed using the pattern: $(component.name)-$(template.name)-$(ordinal), starting with an ordinal of 0. It is crucial to maintain unique names for each InstanceTemplate to avoid conflicts.

The sum of replicas across all InstanceTemplates should not exceed the total number of replicas specified for the Component. Any remaining replicas will be generated using the default template and will follow the default naming rules.

Specifies the names of instances to be transitioned to offline status.

Marking an instance as offline results in the following:

1. The associated Pod is stopped, and its PersistentVolumeClaim (PVC) is retained for potential future reuse or data recovery, but it is no longer actively used.
2. The ordinal number assigned to this instance is preserved, ensuring it remains unique and avoiding conflicts with new instances.

Setting instances to offline allows for a controlled scale-in process, preserving their data and maintaining ordinal consistency within the Cluster. Note that offline instances and their associated resources, such as PVCs, are not automatically deleted. The administrator must manually manage the cleanup and removal of these resources when they are no longer needed.

Determines whether metrics exporter information is annotated on the Component’s headless Service.

If set to true, the following annotations will not be patched into the Service:

• “monitor.kubeblocks.io/path”
• “monitor.kubeblocks.io/port”
• “monitor.kubeblocks.io/scheme”

These annotations allow the Prometheus installed by KubeBlocks to discover and scrape metrics from the exporter.

Deprecated since v0.9 Determines whether metrics exporter information is annotated on the Component’s headless Service.

If set to true, the following annotations will be patched into the Service:

• “monitor.kubeblocks.io/path”
• “monitor.kubeblocks.io/port”
• “monitor.kubeblocks.io/scheme”

These annotations allow the Prometheus installed by KubeBlocks to discover and scrape metrics from the exporter.

Stop the Component. If set, all the computing resources will be released.

Specifies the current state of the Component.

Records detailed information about the Component in its current phase. The keys are either podName, deployName, or statefulSetName, formatted as ‘ObjectKind/Name’.

Checks if all Pods of the Component are ready.

Indicates the time when all Component Pods became ready. This is the readiness time of the last Component Pod.

Represents the status of the members.

Specifies a reference to one of the cluster component definition names in the ClusterDefinition API (spec.componentDefs.name).

Defines a configuration extension mechanism to handle configuration differences between versions. The configTemplateRefs field, in conjunction with the configTemplateRefs in the ClusterDefinition, determines the final configuration file.

Defines the image for the component to connect to databases or engines. This overrides the `image` and `env` attributes defined in clusterDefinition.spec.componentDefs.systemAccountSpec.cmdExecutorConfig. To clear default environment settings, set systemAccountSpec.cmdExecutorConfig.env to an empty list.

Defines the context for container images for component versions. This value replaces the values in clusterDefinition.spec.componentDefs.podSpec.[initContainers | containers].

Defines the images for the component to perform a switchover. This overrides the image and env attributes defined in clusterDefinition.spec.componentDefs.SwitchoverSpec.CommandExecutorEnvItem.

Refers to the name of a volumeMount defined in either:

• `componentDefinition.spec.runtime.containers[*].volumeMounts`
• `clusterDefinition.spec.componentDefs[*].podSpec.containers[*].volumeMounts` (deprecated)

The value of `name` must match the `name` field of a volumeMount specified in the corresponding `volumeMounts` array.

Specifies the labels for the PVC of the volume.

Specifies the annotations for the PVC of the volume.

Defines the desired characteristics of a PersistentVolumeClaim that will be created for the volume with the mount name specified in the `name` field.

When a Pod is created for this ClusterComponent, a new PVC will be created based on the specification defined in the `spec` field. The PVC will be associated with the volume mount specified by the `name` field.

How often (in seconds) to perform the probe.

Number of seconds after which the probe times out. Defaults to 1 second.

Minimum consecutive failures for the probe to be considered failed after having succeeded.

Commands used to execute for probe.

Defines write checks that are executed on the probe sidecar.

Defines read checks that are executed on the probe sidecar.

Specifies the probe used for checking the running status of the component.

Specifies the probe used for checking the status of the component.

Specifies the probe used for checking the role of the component.

Defines the timeout (in seconds) for the role probe after all pods of the component are ready. The system will check if the application is available in the pod. If pods exceed the InitializationTimeoutSeconds time without a role label, this component will enter the Failed/Abnormal phase.

Note that this configuration will only take effect if the component supports RoleProbe and will not affect the life cycle of the pod. default values are 60 seconds.

Specifies the well-known database type, such as mysql, redis, or mongodb.

Deprecated since v0.9. This field is maintained for backward compatibility and its use is discouraged. Existing usage should be updated to the current preferred approach to avoid compatibility issues in future releases.

Provides the definitions for the cluster components.

Deprecated since v0.9. Components should now be individually defined using ComponentDefinition and collectively referenced via `topology.components`. This field is maintained for backward compatibility and its use is discouraged. Existing usage should be updated to the current preferred approach to avoid compatibility issues in future releases.

Connection credential template used for creating a connection credential secret for cluster objects.

Built-in objects are:

• `$(RANDOM_PASSWD)` random 8 characters.
• `$(STRONG_RANDOM_PASSWD)` random 16 characters, with mixed cases, digits and symbols.
• `$(UUID)` generate a random UUID v4 string.
• `$(UUID_B64)` generate a random UUID v4 BASE64 encoded string.
• `$(UUID_STR_B64)` generate a random UUID v4 string then BASE64 encoded.
• `$(UUID_HEX)` generate a random UUID v4 HEX representation.
• `$(HEADLESS_SVC_FQDN)` headless service FQDN placeholder, value pattern is `$(CLUSTER_NAME)-$(1ST_COMP_NAME)-headless.$(NAMESPACE).svc`, where 1ST_COMP_NAME is the 1st component that provide `ClusterDefinition.spec.componentDefs[].service` attribute;
• `$(SVC_FQDN)` service FQDN placeholder, value pattern is `$(CLUSTER_NAME)-$(1ST_COMP_NAME).$(NAMESPACE).svc`, where 1ST_COMP_NAME is the 1st component that provide `ClusterDefinition.spec.componentDefs[].service` attribute;
• `$(SVC_PORT_{PORT-NAME})` is ServicePort’s port value with specified port name, i.e, a servicePort JSON struct: `{"name": "mysql", "targetPort": "mysqlContainerPort", "port": 3306}`, and `$(SVC_PORT_mysql)` in the connection credential value is 3306.

Deprecated since v0.9. This field is maintained for backward compatibility and its use is discouraged. Existing usage should be updated to the current preferred approach to avoid compatibility issues in future releases.

Topologies defines all possible topologies within the cluster.

Represents the most recent generation observed for this ClusterDefinition.

Specifies the current phase of the ClusterDefinition. Valid values are `empty`, `Available`, `Unavailable`. When `Available`, the ClusterDefinition is ready and can be referenced by related objects.

Provides additional information about the current phase.

Topologies this ClusterDefinition supported.

The service references declared by this ClusterDefinition.

Indicates whether the host network can be accessed. By default, this is set to false.

Indicates whether the network is accessible to the public. By default, this is set to false.

Specifies the exact name, name prefix, or regular expression pattern for matching the name of the ComponentDefinition custom resource (CR) used by the component that the referent object resident in.

If not specified, the component itself will be used.

Name of the referent object.

Specify whether the object must be defined.

This option defines the behavior when multiple component objects match the specified @CompDef. If not provided, an error will be raised when handling multiple matches.

"Abnormal"

AbnormalClusterPhase represents some components are in `Failed` or `Abnormal` phase, indicates that the cluster is in a fragile state and troubleshooting is required.

"Creating"

CreatingClusterPhase represents all components are in `Creating` phase.

"Deleting"

DeletingClusterPhase indicates the cluster is being deleted.

"Failed"

FailedClusterPhase represents all components are in `Failed` phase, indicates that the cluster is unavailable.

"Running"

RunningClusterPhase represents all components are in `Running` phase, indicates that the cluster is functioning properly.

"Stopped"

StoppedClusterPhase represents all components are in `Stopped` phase, indicates that the cluster has stopped and is not providing any functionality.

"Stopping"

StoppingClusterPhase represents at least one component is in `Stopping` phase, indicates that the cluster is in the process of stopping.

"Updating"

UpdatingClusterPhase represents all components are in `Creating`, `Running` or `Updating` phase, and at least one component is in `Creating` or `Updating` phase, indicates that the cluster is undergoing an update.

clusterDefRef is the name of the cluster definition.

selector is used to bind the resource constraint to components.

Specifies the amount of CPU resource the Cluster needs. For more information, refer to: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

Specifies the amount of memory resource the Cluster needs. For more information, refer to: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

(Members of `Service` are embedded into this type.)

Extends the ServiceSpec.Selector by allowing the specification of a sharding name, which is defined in `cluster.spec.shardingSpecs[*].name`, to be used as a selector for the service. Note that this and the `componentSelector` are mutually exclusive and cannot be set simultaneously.

Extends the ServiceSpec.Selector by allowing the specification of a component, to be used as a selector for the service. Note that this and the `shardingSelector` are mutually exclusive and cannot be set simultaneously.

Specifies the name of the ClusterDefinition to use when creating a Cluster.

This field enables users to create a Cluster based on a specific ClusterDefinition. Which, in conjunction with the `topology` field, determine:

• The Components to be included in the Cluster.
• The sequences in which the Components are created, updated, and terminate.

This facilitates multiple-components management with predefined ClusterDefinition.

Users with advanced requirements can bypass this general setting and specify more precise control over the composition of the Cluster by directly referencing specific ComponentDefinitions for each component within `componentSpecs[*].componentDef`.

If this field is not provided, each component must be explicitly defined in `componentSpecs[*].componentDef`.

Note: Once set, this field cannot be modified; it is immutable.

Refers to the ClusterVersion name.

Deprecated since v0.9, use ComponentVersion instead. This field is maintained for backward compatibility and its use is discouraged. Existing usage should be updated to the current preferred approach to avoid compatibility issues in future releases.

Specifies the name of the ClusterTopology to be used when creating the Cluster.

This field defines which set of Components, as outlined in the ClusterDefinition, will be used to construct the Cluster based on the named topology. The ClusterDefinition may list multiple topologies under `clusterdefinition.spec.topologies[*]`, each tailored to different use cases or environments.

If `topology` is not specified, the Cluster will use the default topology defined in the ClusterDefinition.

Note: Once set during the Cluster creation, the `topology` field cannot be modified. It establishes the initial composition and structure of the Cluster and is intended for one-time configuration.

Specifies the behavior when a Cluster is deleted. It defines how resources, data, and backups associated with a Cluster are managed during termination. Choose a policy based on the desired level of resource cleanup and data preservation:

• `DoNotTerminate`: Prevents deletion of the Cluster. This policy ensures that all resources remain intact.
• `Halt`: Deletes Cluster resources like Pods and Services but retains Persistent Volume Claims (PVCs), allowing for data preservation while stopping other operations. Warning: Halt policy is deprecated in 0.9.1 and will have same meaning as DoNotTerminate.
• `Delete`: Extends the `Halt` policy by also removing PVCs, leading to a thorough cleanup while removing all persistent data.
• `WipeOut`: An aggressive policy that deletes all Cluster resources, including volume snapshots and backups in external storage. This results in complete data removal and should be used cautiously, primarily in non-production environments to avoid irreversible data loss.

Warning: Choosing an inappropriate termination policy can result in data loss. The `WipeOut` policy is particularly risky in production environments due to its irreversible nature.

Specifies a list of ShardingSpec objects that manage the sharding topology for Cluster Components. Each ShardingSpec organizes components into shards, with each shard corresponding to a Component. Components within a shard are all based on a common ClusterComponentSpec template, ensuring uniform configurations.

This field supports dynamic resharding by facilitating the addition or removal of shards through the `shards` field in ShardingSpec.

Note: `shardingSpecs` and `componentSpecs` cannot both be empty; at least one must be defined to configure a Cluster.

Specifies a list of ClusterComponentSpec objects used to define the individual Components that make up a Cluster. This field allows for detailed configuration of each Component within the Cluster.

Note: `shardingSpecs` and `componentSpecs` cannot both be empty; at least one must be defined to configure a Cluster.

Defines a list of additional Services that are exposed by a Cluster. This field allows Services of selected Components, either from `componentSpecs` or `shardingSpecs` to be exposed, alongside Services defined with ComponentService.

Services defined here can be referenced by other clusters using the ServiceRefClusterSelector.

Defines a set of node affinity scheduling rules for the Cluster’s Pods. This field helps control the placement of Pods on nodes within the Cluster.

An array that specifies tolerations attached to the Cluster’s Pods, allowing them to be scheduled onto nodes with matching taints.

Specifies the scheduling policy for the cluster.

Specifies runtimeClassName for all Pods managed by this Cluster.

Specifies the backup configuration of the Cluster.

Describes how Pods are distributed across node.

Deprecated since v0.9. This field is maintained for backward compatibility and its use is discouraged. Existing usage should be updated to the current preferred approach to avoid compatibility issues in future releases.

Describes the availability policy, including zone, node, and none.

Deprecated since v0.9. This field is maintained for backward compatibility and its use is discouraged. Existing usage should be updated to the current preferred approach to avoid compatibility issues in future releases.

Specifies the replicas of the first componentSpec, if the replicas of the first componentSpec is specified, this value will be ignored.

Deprecated since v0.9. This field is maintained for backward compatibility and its use is discouraged. Existing usage should be updated to the current preferred approach to avoid compatibility issues in future releases.

Specifies the resources of the first componentSpec, if the resources of the first componentSpec is specified, this value will be ignored.

Deprecated since v0.9. This field is maintained for backward compatibility and its use is discouraged. Existing usage should be updated to the current preferred approach to avoid compatibility issues in future releases.

Specifies the storage of the first componentSpec, if the storage of the first componentSpec is specified, this value will be ignored.

Deprecated since v0.9. This field is maintained for backward compatibility and its use is discouraged. Existing usage should be updated to the current preferred approach to avoid compatibility issues in future releases.

The configuration of network.

Deprecated since v0.9. This field is maintained for backward compatibility and its use is discouraged. Existing usage should be updated to the current preferred approach to avoid compatibility issues in future releases.

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

The current phase of the Cluster includes: `Creating`, `Running`, `Updating`, `Stopping`, `Stopped`, `Deleting`, `Failed`, `Abnormal`.

Provides additional information about the current phase.

Records the current status information of all Components within the Cluster.

Represents the generation number of the referenced ClusterDefinition.

Represents a list of detailed status of the Cluster object. Each condition in the list provides real-time information about certain aspect of the Cluster object.

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

Specifies the amount of storage the Cluster needs. For more information, refer to: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

Type specifies the type of switch policy to be applied.

Name is the unique identifier for the cluster topology. Cannot be updated.

Components specifies the components in the topology.

Specifies the sequence in which components within a cluster topology are started, stopped, and upgraded. This ordering is crucial for maintaining the correct dependencies and operational flow across components.

Default indicates whether this topology serves as the default configuration. When set to true, this topology is automatically used unless another is explicitly specified.

Defines the unique identifier of the component within the cluster topology.

It follows IANA Service naming rules and is used as part of the Service’s DNS name. The name must start with a lowercase letter, can contain lowercase letters, numbers, and hyphens, and must end with a lowercase letter or number.

If the @template field is set to true, the name will be used as a prefix to match the specific components dynamically created.

Cannot be updated once set.

Specifies the exact name, name prefix, or regular expression pattern for matching the name of the ComponentDefinition custom resource (CR) that defines the Component’s characteristics and behavior.

The system selects the ComponentDefinition CR with the latest version that matches the pattern. This approach allows:

1. Precise selection by providing the exact name of a ComponentDefinition CR.
2. Flexible and automatic selection of the most up-to-date ComponentDefinition CR by specifying a name prefix or regular expression pattern.

Cannot be updated once set.

Specifies whether the topology component will be considered as a template for instantiating components upon user requests dynamically.

Cannot be updated once set.

Specifies the order for creating and initializing components. This is designed for components that depend on one another. Components without dependencies can be grouped together.

Components that can be provisioned independently or have no dependencies can be listed together in the same stage, separated by commas.

Outlines the order for stopping and deleting components. This sequence is designed for components that require a graceful shutdown or have interdependencies.

Components that can be terminated independently or have no dependencies can be listed together in the same stage, separated by commas.

Update determines the order for updating components’ specifications, such as image upgrades or resource scaling. This sequence is designed for components that have dependencies or require specific update procedures.

Components that can be updated independently or have no dependencies can be listed together in the same stage, separated by commas.

Specifies a reference to the ClusterDefinition.

Contains a list of versioning contexts for the components’ containers.

The current phase of the ClusterVersion.

Provides additional information about the current phase.

The generation number that has been observed by the controller.

The generation number of the ClusterDefinition that is currently being referenced.

(Members of `CommandExecutorEnvItem` are embedded into this type.)

(Members of `CommandExecutorItem` are embedded into this type.)

Specifies the image used to execute the command.

A list of environment variables that will be injected into the command execution context.

The command to be executed.

Additional parameters used in the execution of the command.

Specifies the number of seconds to wait after the resource has been patched before initiating completion probes. The default value is 5 seconds, with a minimum value of 1.

Specifies the number of seconds after which the probe times out. The default value is 60 seconds, with a minimum value of 1.

Specifies the frequency (in seconds) at which the probe should be performed. The default value is 5 seconds, with a minimum value of 1.

Executes expressions regularly, based on the value of PeriodSeconds, to determine if the action has been completed.

name is the class name

args are variable’s value

the CPU of the class

the memory of the class

group defines a list of class series that conform to the same constraint.

observedGeneration is the most recent generation observed for this ComponentClassDefinition. It corresponds to the ComponentClassDefinition’s generation, which is updated on mutation by the API Server.

classes is the list of classes that have been observed for this ComponentClassDefinition

template is a class definition template that uses the Go template syntax and allows for variable declaration. When defining a class in Series, specifying the variable’s value is sufficient, as the complete class definition will be generated through rendering the template.

For example:

template: |
	 cpu: "{{ or .cpu 1 }}"
	 memory: "{{ or .memory 4 }}Gi"

vars defines the variables declared in the template and will be used to generating the complete class definition by render the template.

series is a series of class definitions.

namingTemplate is a template that uses the Go template syntax and allows for referencing variables defined in ComponentClassGroup.Template. This enables dynamic generation of class names. For example: name: “general-{{ .cpu }}c{{ .memory }}g”

classes are definitions of classes that come in two forms. In the first form, only ComponentClass.Args need to be defined, and the complete class definition is generated by rendering the ComponentClassGroup.Template and Name. In the second form, the Name, CPU and Memory must be defined.

(Members of `ComponentTemplateSpec` are embedded into this type.)

Specifies the configuration files within the ConfigMap that support dynamic updates.

A configuration template (provided in the form of a ConfigMap) may contain templates for multiple configuration files. Each configuration file corresponds to a key in the ConfigMap. Some of these configuration files may support dynamic modification and reloading without requiring a pod restart.

If empty or omitted, all configuration files in the ConfigMap are assumed to support dynamic updates, and ConfigConstraint applies to all keys.

Specifies the secondary rendered config spec for pod-specific customization.

The template is rendered inside the pod (by the “config-manager” sidecar container) and merged with the main template’s render result to generate the final configuration file.

This field is intended to handle scenarios where different pods within the same Component have varying configurations. It allows for pod-specific customization of the configuration.

Note: This field will be deprecated in future versions, and the functionality will be moved to `cluster.spec.componentSpecs[*].instances[*]`.

Specifies the name of the referenced configuration constraints object.

Specifies the containers to inject the ConfigMap parameters as environment variables.

This is useful when application images accept parameters through environment variables and generate the final configuration file in the startup script based on these variables.

This field allows users to specify a list of container names, and KubeBlocks will inject the environment variables converted from the ConfigMap into these designated containers. This provides a flexible way to pass the configuration items from the ConfigMap to the container without modifying the image.

Deprecated: `asEnvFrom` has been deprecated since 0.9.0 and will be removed in 0.10.0. Use `injectEnvTo` instead.

Specifies the containers to inject the ConfigMap parameters as environment variables.

This is useful when application images accept parameters through environment variables and generate the final configuration file in the startup script based on these variables.

This field allows users to specify a list of container names, and KubeBlocks will inject the environment variables converted from the ConfigMap into these designated containers. This provides a flexible way to pass the configuration items from the ConfigMap to the container without modifying the image.

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.

The name of the componentDef to be selected.

Defines the policy to be followed in case of a failure in finding the component.

The values that are to be injected as environment variables into each component.

Specifies the name of the Component provider, typically the vendor or developer name. It identifies the entity responsible for creating and maintaining the Component.

When specifying the provider name, consider the following guidelines:

• Keep the name concise and relevant to the Component.
• Use a consistent naming convention across Components from the same provider.
• Avoid using trademarked or copyrighted names without proper permission.

Provides a brief and concise explanation of the Component’s purpose, functionality, and any relevant details. It serves as a quick reference for users to understand the Component’s role and characteristics.

Defines the type of well-known service protocol that the Component provides. It specifies the standard or widely recognized protocol used by the Component to offer its Services.

The `serviceKind` field allows users to quickly identify the type of Service provided by the Component based on common protocols or service types. This information helps in understanding the compatibility, interoperability, and usage of the Component within a system.

Some examples of well-known service protocols include:

• “MySQL”: Indicates that the Component provides a MySQL database service.
• “PostgreSQL”: Indicates that the Component offers a PostgreSQL database service.
• “Redis”: Signifies that the Component functions as a Redis key-value store.
• “ETCD”: Denotes that the Component serves as an ETCD distributed key-value store.

The `serviceKind` value is case-insensitive, allowing for flexibility in specifying the protocol name.

When specifying the `serviceKind`, consider the following guidelines:

• Use well-established and widely recognized protocol names or service types.
• Ensure that the `serviceKind` accurately represents the primary service type offered by the Component.
• If the Component provides multiple services, choose the most prominent or commonly used protocol.
• Limit the `serviceKind` to a maximum of 32 characters for conciseness and readability.

Note: The `serviceKind` field is optional and can be left empty if the Component does not fit into a well-known service category or if the protocol is not widely recognized. It is primarily used to convey information about the Component’s service type to users and facilitate discovery and integration.

The `serviceKind` field is immutable and cannot be updated.

Specifies the version of the Service provided by the Component. It follows the syntax and semantics of the “Semantic Versioning” specification (http://semver.org/).

The Semantic Versioning specification defines a version number format of X.Y.Z (MAJOR.MINOR.PATCH), where:

• X represents the major version and indicates incompatible API changes.
• Y represents the minor version and indicates added functionality in a backward-compatible manner.
• Z represents the patch version and indicates backward-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the X.Y.Z format:

• Use pre-release labels (e.g., -alpha, -beta) for versions that are not yet stable or ready for production use.
• Use build metadata (e.g., +build.1) for additional version information if needed.

Examples of valid ServiceVersion values:

• “1.0.0”
• “2.3.1”
• “3.0.0-alpha.1”
• “4.5.2+build.1”

The `serviceVersion` field is immutable and cannot be updated.

Specifies the PodSpec template used in the Component. It includes the following elements:

• Init containers
• Containers
  • Image
  • Commands
  • Args
  • Envs
  • Mounts
  • Ports
  • Security context
  • Probes
  • Lifecycle
• Volumes

This field is intended to define static settings that remain consistent across all instantiated Components. Dynamic settings such as CPU and memory resource limits, as well as scheduling settings (affinity, toleration, priority), may vary among different instantiated Components. They should be specified in the `cluster.spec.componentSpecs` (ClusterComponentSpec).

Specific instances of a Component may override settings defined here, such as using a different container image or modifying environment variable values. These instance-specific overrides can be specified in `cluster.spec.componentSpecs[*].instances`.

This field is immutable and cannot be updated once set.

Deprecated since v0.9 monitor is monitoring config which provided by provider.

Defines the built-in metrics exporter container.

Defines variables which are determined after Cluster instantiation and reflect dynamic or runtime attributes of instantiated Clusters. These variables serve as placeholders for setting environment variables in Pods and Actions, or for rendering configuration and script templates before actual values are finalized.

These variables are placed in front of the environment variables declared in the Pod if used as environment variables.

Variable values can be sourced from:

• ConfigMap: Select and extract a value from a specific key within a ConfigMap.
• Secret: Select and extract a value from a specific key within a Secret.
• HostNetwork: Retrieves values (including ports) from host-network resources.
• Service: Retrieves values (including address, port, NodePort) from a selected Service. Intended to obtain the address of a ComponentService within the same Cluster.
• Credential: Retrieves account name and password from a SystemAccount variable.
• ServiceRef: Retrieves address, port, account name and password from a selected ServiceRefDeclaration. Designed to obtain the address bound to a ServiceRef, such as a ClusterService or ComponentService of another cluster or an external service.
• Component: Retrieves values from a selected Component, including replicas and instance name list.

This field is immutable.

Defines the volumes used by the Component and some static attributes of the volumes. After defining the volumes here, user can reference them in the `cluster.spec.componentSpecs[*].volumeClaimTemplates` field to configure dynamic properties such as volume capacity and storage class.

This field allows you to specify the following:

• Snapshot behavior: Determines whether a snapshot of the volume should be taken when performing a snapshot backup of the Component.
• Disk high watermark: Sets the high watermark for the volume’s disk usage. When the disk usage reaches the specified threshold, it triggers an alert or action.

By configuring these volume behaviors, you can control how the volumes are managed and monitored within the Component.

This field is immutable.

Specifies the host network configuration for the Component.

When `hostNetwork` option is enabled, the Pods share the host’s network namespace and can directly access the host’s network interfaces. This means that if multiple Pods need to use the same port, they cannot run on the same host simultaneously due to port conflicts.

The DNSPolicy field in the Pod spec determines how containers within the Pod perform DNS resolution. When using hostNetwork, the operator will set the DNSPolicy to ‘ClusterFirstWithHostNet’. With this policy, DNS queries will first go through the K8s cluster’s DNS service. If the query fails, it will fall back to the host’s DNS settings.

If set, the DNS policy will be automatically set to “ClusterFirstWithHostNet”.

This field is immutable.

Defines additional Services to expose the Component’s endpoints.

A default headless Service, named `{cluster.name}-{component.name}-headless`, is automatically created for internal Cluster communication.

This field enables customization of additional Services to expose the Component’s endpoints to other Components within the same or different Clusters, and to external applications. Each Service entry in this list can include properties such as ports, type, and selectors.

• For intra-Cluster access, Components can reference Services using variables declared in `componentDefinition.spec.vars[*].valueFrom.serviceVarRef`.
• For inter-Cluster access, reference Services use variables declared in `componentDefinition.spec.vars[*].valueFrom.serviceRefVarRef`, and bind Services at Cluster creation time with `clusterComponentSpec.ServiceRef[*].clusterServiceSelector`.

This field is immutable.

Specifies the configuration file templates and volume mount parameters used by the Component. It also includes descriptions of the parameters in the ConfigMaps, such as value range limitations.

This field specifies a list of templates that will be rendered into Component containers’ configuration files. Each template is represented as a ConfigMap and may contain multiple configuration files, with each file being a key in the ConfigMap.

The rendered configuration files will be mounted into the Component’s containers according to the specified volume mount parameters.

This field is immutable.

Defines the types of logs generated by instances of the Component and their corresponding file paths. These logs can be collected for further analysis and monitoring.

The `logConfigs` field is an optional list of LogConfig objects, where each object represents a specific log type and its configuration. It allows you to specify multiple log types and their respective file paths for the Component.

Examples:

 logConfigs:
 - filePathPattern: /data/mysql/log/mysqld-error.log
   name: error
 - filePathPattern: /data/mysql/log/mysqld.log
   name: general
 - filePathPattern: /data/mysql/log/mysqld-slowquery.log
   name: slow

This field is immutable.

Specifies groups of scripts, each provided via a ConfigMap, to be mounted as volumes in the container. These scripts can be executed during container startup or via specific actions.

Each script group is encapsulated in a ComponentTemplateSpec that includes:

• The ConfigMap containing the scripts.
• The mount point where the scripts will be mounted inside the container.

This field is immutable.

Defines the namespaced policy rules required by the Component.

The `policyRules` field is an array of `rbacv1.PolicyRule` objects that define the policy rules needed by the Component to operate within a namespace. These policy rules determine the permissions and verbs the Component is allowed to perform on Kubernetes resources within the namespace.

The purpose of this field is to automatically generate the necessary RBAC roles for the Component based on the specified policy rules. This ensures that the Pods in the Component has appropriate permissions to function.

Note: This field is currently non-functional and is reserved for future implementation.

This field is immutable.

Specifies static labels that will be patched to all Kubernetes resources created for the Component.

Note: If a label key in the `labels` field conflicts with any system labels or user-specified labels, it will be silently ignored to avoid overriding higher-priority labels.

This field is immutable.

Specifies static annotations that will be patched to all Kubernetes resources created for the Component.

Note: If an annotation key in the `annotations` field conflicts with any system annotations or user-specified annotations, it will be silently ignored to avoid overriding higher-priority annotations.

This field is immutable.

Defines the upper limit of the number of replicas supported by the Component.

It defines the maximum number of replicas that can be created for the Component. This field allows you to set a limit on the scalability of the Component, preventing it from exceeding a certain number of replicas.

This field is immutable.

An array of `SystemAccount` objects that define the system accounts needed for the management operations of the Component.

Each `SystemAccount` includes:

• Account name.
• The SQL statement template: Used to create the system account.
• Password Source: Either generated based on certain rules or retrieved from a Secret.

Use cases for system accounts typically involve tasks like system initialization, backups, monitoring, health checks, replication, and other system-level operations.

System accounts are distinct from user accounts, although both are database accounts.

• System Accounts: Created during Cluster setup by the KubeBlocks operator, these accounts have higher privileges for system management and are fully managed through a declarative API by the operator.
• User Accounts: Managed by users or administrator. User account permissions should follow the principle of least privilege, granting only the necessary access rights to complete their required tasks.

This field is immutable.

Specifies the concurrency strategy for updating multiple instances of the Component. Available strategies:

• `Serial`: Updates replicas one at a time, ensuring minimal downtime by waiting for each replica to become ready before updating the next.
• `Parallel`: Updates all replicas simultaneously, optimizing for speed but potentially reducing availability during the update.
• `BestEffortParallel`: Updates replicas concurrently with a limit on simultaneous updates to ensure a minimum number of operational replicas for maintaining quorum. For example, in a 5-replica component, updating a maximum of 2 replicas simultaneously keeps at least 3 operational for quorum.

This field is immutable and defaults to ‘Serial’.

InstanceSet controls the creation of pods during initial scale up, replacement of pods on nodes, and scaling down.

• `OrderedReady`: Creates pods in increasing order (pod-0, then pod-1, etc). The controller waits until each pod is ready before continuing. Pods are removed in reverse order when scaling down.
• `Parallel`: Creates pods in parallel to match the desired scale without waiting. All pods are deleted at once when scaling down.

Enumerate all possible roles assigned to each replica of the Component, influencing its behavior.

A replica can have zero to multiple roles. KubeBlocks operator determines the roles of each replica by invoking the `lifecycleActions.roleProbe` method. This action returns a list of roles for each replica, and the returned roles must be predefined in the `roles` field.

The roles assigned to a replica can influence various aspects of the Component’s behavior, such as:

• Service selection: The Component’s exposed Services may target replicas based on their roles using `roleSelector`.
• Update order: The roles can determine the order in which replicas are updated during a Component update. For instance, replicas with a “follower” role can be updated first, while the replica with the “leader” role is updated last. This helps minimize the number of leader changes during the update process.

This field is immutable.

This field has been deprecated since v0.9. This field is maintained for backward compatibility and its use is discouraged. Existing usage should be updated to the current preferred approach to avoid compatibility issues in future releases.

This field is immutable.

Defines a set of hooks and procedures that customize the behavior of a Component throughout its lifecycle. Actions are triggered at specific lifecycle stages:

• `postProvision`: Defines the hook to be executed after the creation of a Component, with `preCondition` specifying when the action should be fired relative to the Component’s lifecycle stages: `Immediately`, `RuntimeReady`, `ComponentReady`, and `ClusterReady`.
• `preTerminate`: Defines the hook to be executed before terminating a Component.
• `roleProbe`: Defines the procedure which is invoked regularly to assess the role of replicas.
• `switchover`: Defines the procedure for a controlled transition of leadership from the current leader to a new replica. This approach aims to minimize downtime and maintain availability in systems with a leader-follower topology, such as before planned maintenance or upgrades on the current leader node.
• `memberJoin`: Defines the procedure to add a new replica to the replication group.
• `memberLeave`: Defines the method to remove a replica from the replication group.
• `readOnly`: Defines the procedure to switch a replica into the read-only state.
• `readWrite`: transition a replica from the read-only state back to the read-write state.
• `dataDump`: Defines the procedure to export the data from a replica.
• `dataLoad`: Defines the procedure to import data into a replica.
• `reconfigure`: Defines the procedure that update a replica with new configuration file.
• `accountProvision`: Defines the procedure to generate a new database account.

This field is immutable.

Lists external service dependencies of the Component, including services from other Clusters or outside the K8s environment.

This field is immutable.

`minReadySeconds` is the minimum duration in seconds that a new Pod should remain in the ready state without any of its containers crashing to be considered available. This ensures the Pod’s stability and readiness to serve requests.

A default value of 0 seconds means the Pod is considered available as soon as it enters the ready state.

Refers to the most recent generation that has been observed for the ComponentDefinition.

Represents the current status of the ComponentDefinition. Valid values include ``,`Available`, and`Unavailable. When the status isAvailable`, the ComponentDefinition is ready and can be utilized by related objects.

Provides additional information about the current phase.

Specifies the name of the ComponentDefinition. The name can represent an exact name, a name prefix, or a regular expression pattern.

For example:

• “mysql-8.0.30-v1alpha1”: Matches the exact name “mysql-8.0.30-v1alpha1”
• “mysql-8.0.30”: Matches all names starting with “mysql-8.0.30”
• ”^mysql-8.0.\d{1,2}$“: Matches all names starting with “mysql-8.0.” followed by one or two digits.

Specifies the account name associated with the Component. If set, the corresponding account username and password are injected into containers’ environment variables `KB_ACCOUNT_USERNAME` and `KB_ACCOUNT_PASSWORD`.

Specifies the name of the Service. If set, the service name is injected as the `KB_COMP_SVC_NAME` environment variable in the containers, and each service port is mapped to a corresponding environment variable named `KB_COMP_SVC_PORT_$(portName)`. The `portName` is transformed by replacing ‘-’ with ‘_’ and converting to uppercase.

Specifies the hook to be executed after a component’s creation.

By setting `postProvision.customHandler.preCondition`, you can determine the specific lifecycle stage at which the action should trigger: `Immediately`, `RuntimeReady`, `ComponentReady`, and `ClusterReady`. with `ComponentReady` being the default.

The PostProvision Action is intended to run only once.

The container executing this action has access to following environment variables:

• KB_CLUSTER_POD_IP_LIST: Comma-separated list of the cluster’s pod IP addresses (e.g., “podIp1,podIp2”).

• KB_CLUSTER_POD_NAME_LIST: Comma-separated list of the cluster’s pod names (e.g., “pod1,pod2”).

• KB_CLUSTER_POD_HOST_NAME_LIST: Comma-separated list of host names, each corresponding to a pod in KB_CLUSTER_POD_NAME_LIST (e.g., “hostName1,hostName2”).

• KB_CLUSTER_POD_HOST_IP_LIST: Comma-separated list of host IP addresses, each corresponding to a pod in KB_CLUSTER_POD_NAME_LIST (e.g., “hostIp1,hostIp2”).

• KB_CLUSTER_COMPONENT_POD_NAME_LIST: Comma-separated list of all pod names within the component (e.g., “pod1,pod2”).

• KB_CLUSTER_COMPONENT_POD_IP_LIST: Comma-separated list of pod IP addresses, matching the order of pods in KB_CLUSTER_COMPONENT_POD_NAME_LIST (e.g., “podIp1,podIp2”).

• KB_CLUSTER_COMPONENT_POD_HOST_NAME_LIST: Comma-separated list of host names for each pod, matching the order of pods in KB_CLUSTER_COMPONENT_POD_NAME_LIST (e.g., “hostName1,hostName2”).

• KB_CLUSTER_COMPONENT_POD_HOST_IP_LIST: Comma-separated list of host IP addresses for each pod, matching the order of pods in KB_CLUSTER_COMPONENT_POD_NAME_LIST (e.g., “hostIp1,hostIp2”).

• KB_CLUSTER_COMPONENT_LIST: Comma-separated list of all cluster components (e.g., “comp1,comp2”).

• KB_CLUSTER_COMPONENT_DELETING_LIST: Comma-separated list of components that are currently being deleted (e.g., “comp1,comp2”).

• KB_CLUSTER_COMPONENT_UNDELETED_LIST: Comma-separated list of components that are not being deleted (e.g., “comp1,comp2”).

Note: This field is immutable once it has been set.

Specifies the hook to be executed prior to terminating a component.

The PreTerminate Action is intended to run only once.

This action is executed immediately when a scale-down operation for the Component is initiated. The actual termination and cleanup of the Component and its associated resources will not proceed until the PreTerminate action has completed successfully.

The container executing this action has access to following environment variables:

• KB_CLUSTER_POD_IP_LIST: Comma-separated list of the cluster’s pod IP addresses (e.g., “podIp1,podIp2”).

• KB_CLUSTER_POD_NAME_LIST: Comma-separated list of the cluster’s pod names (e.g., “pod1,pod2”).

• KB_CLUSTER_POD_HOST_NAME_LIST: Comma-separated list of host names, each corresponding to a pod in KB_CLUSTER_POD_NAME_LIST (e.g., “hostName1,hostName2”).

• KB_CLUSTER_POD_HOST_IP_LIST: Comma-separated list of host IP addresses, each corresponding to a pod in KB_CLUSTER_POD_NAME_LIST (e.g., “hostIp1,hostIp2”).

• KB_CLUSTER_COMPONENT_POD_NAME_LIST: Comma-separated list of all pod names within the component (e.g., “pod1,pod2”).

• KB_CLUSTER_COMPONENT_POD_IP_LIST: Comma-separated list of pod IP addresses, matching the order of pods in KB_CLUSTER_COMPONENT_POD_NAME_LIST (e.g., “podIp1,podIp2”).

• KB_CLUSTER_COMPONENT_POD_HOST_NAME_LIST: Comma-separated list of host names for each pod, matching the order of pods in KB_CLUSTER_COMPONENT_POD_NAME_LIST (e.g., “hostName1,hostName2”).

• KB_CLUSTER_COMPONENT_POD_HOST_IP_LIST: Comma-separated list of host IP addresses for each pod, matching the order of pods in KB_CLUSTER_COMPONENT_POD_NAME_LIST (e.g., “hostIp1,hostIp2”).

• KB_CLUSTER_COMPONENT_LIST: Comma-separated list of all cluster components (e.g., “comp1,comp2”).

• KB_CLUSTER_COMPONENT_DELETING_LIST: Comma-separated list of components that are currently being deleted (e.g., “comp1,comp2”).

• KB_CLUSTER_COMPONENT_UNDELETED_LIST: Comma-separated list of components that are not being deleted (e.g., “comp1,comp2”).

• KB_CLUSTER_COMPONENT_IS_SCALING_IN: Indicates whether the component is currently scaling in. If this variable is present and set to “true”, it denotes that the component is undergoing a scale-in operation. During scale-in, data rebalancing is necessary to maintain cluster integrity. Contrast this with a cluster deletion scenario where data rebalancing is not required as the entire cluster is being cleaned up.

Note: This field is immutable once it has been set.

Defines the procedure which is invoked regularly to assess the role of replicas.

This action is periodically triggered by Lorry at the specified interval to determine the role of each replica. Upon successful execution, the action’s output designates the role of the replica, which should match one of the predefined role names within `componentDefinition.spec.roles`. The output is then compared with the previous successful execution result. If a role change is detected, an event is generated to inform the controller, which initiates an update of the replica’s role.

Defining a RoleProbe Action for a Component is required if roles are defined for the Component. It ensures replicas are correctly labeled with their respective roles. Without this, services that rely on roleSelectors might improperly direct traffic to wrong replicas.

The container executing this action has access to following environment variables:

• KB_POD_FQDN: The FQDN of the Pod whose role is being assessed.
• KB_SERVICE_PORT: The port used by the database service.
• KB_SERVICE_USER: The username with the necessary permissions to interact with the database service.
• KB_SERVICE_PASSWORD: The corresponding password for KB_SERVICE_USER to authenticate with the database service.

Example Output of this action: - On Success: The determined role of the replica, which must align with one of the roles specified in the component definition. - On Failure: An error message, if applicable, indicating why the action failed.

Note: This field is immutable once it has been set.

Defines the procedure for a controlled transition of leadership from the current leader to a new replica. This approach aims to minimize downtime and maintain availability in systems with a leader-follower topology, during events such as planned maintenance or when performing stop, shutdown, restart, or upgrade operations involving the current leader node.

The container executing this action has access to following environment variables:

• KB_SWITCHOVER_CANDIDATE_NAME: The name of the pod for the new leader candidate, which may not be specified (empty).
• KB_SWITCHOVER_CANDIDATE_FQDN: The FQDN of the new leader candidate’s pod, which may not be specified (empty).
• KB_LEADER_POD_IP: The IP address of the current leader’s pod prior to the switchover.
• KB_LEADER_POD_NAME: The name of the current leader’s pod prior to the switchover.
• KB_LEADER_POD_FQDN: The FQDN of the current leader’s pod prior to the switchover.

The environment variables with the following prefixes are deprecated and will be removed in future releases:

• KB_REPLICATION_PRIMARYPOD
• KB_CONSENSUS_LEADERPOD

Note: This field is immutable once it has been set.

Defines the procedure to add a new replica to the replication group.

This action is initiated after a replica pod becomes ready.

The role of the replica (e.g., primary, secondary) will be determined and assigned as part of the action command implementation, or automatically by the database kernel or a sidecar utility like Patroni that implements a consensus algorithm.

The container executing this action has access to following environment variables:

• KB_SERVICE_PORT: The port used by the database service.
• KB_SERVICE_USER: The username with the necessary permissions to interact with the database service.
• KB_SERVICE_PASSWORD: The corresponding password for KB_SERVICE_USER to authenticate with the database service.
• KB_PRIMARY_POD_FQDN: The FQDN of the primary Pod within the replication group.
• KB_MEMBER_ADDRESSES: A comma-separated list of Pod addresses for all replicas in the group.
• KB_NEW_MEMBER_POD_NAME: The pod name of the replica being added to the group.
• KB_NEW_MEMBER_POD_IP: The IP address of the replica being added to the group.

Expected action output: - On Failure: An error message detailing the reason for any failure encountered during the addition of the new member.

For example, to add a new OBServer to an OceanBase Cluster in ‘zone1’, the following command may be used:

command:
- bash
- -c
- |
   ADDRESS=$(KB_MEMBER_ADDRESSES%%,*)
   HOST=$(echo $ADDRESS | cut -d ':' -f 1)
   PORT=$(echo $ADDRESS | cut -d ':' -f 2)
   CLIENT="mysql -u $KB_SERVICE_USER -p$KB_SERVICE_PASSWORD -P $PORT -h $HOST -e"
	  $CLIENT "ALTER SYSTEM ADD SERVER '$KB_NEW_MEMBER_POD_IP:$KB_SERVICE_PORT' ZONE 'zone1'"

Note: This field is immutable once it has been set.

Defines the procedure to remove a replica from the replication group.

This action is initiated before remove a replica from the group. The operator will wait for MemberLeave to complete successfully before releasing the replica and cleaning up related Kubernetes resources.

The process typically includes updating configurations and informing other group members about the removal. Data migration is generally not part of this action and should be handled separately if needed.

The container executing this action has access to following environment variables:

• KB_SERVICE_PORT: The port used by the database service.
• KB_SERVICE_USER: The username with the necessary permissions to interact with the database service.
• KB_SERVICE_PASSWORD: The corresponding password for KB_SERVICE_USER to authenticate with the database service.
• KB_PRIMARY_POD_FQDN: The FQDN of the primary Pod within the replication group.
• KB_MEMBER_ADDRESSES: A comma-separated list of Pod addresses for all replicas in the group.
• KB_LEAVE_MEMBER_POD_NAME: The pod name of the replica being removed from the group.
• KB_LEAVE_MEMBER_POD_IP: The IP address of the replica being removed from the group.

Expected action output: - On Failure: An error message, if applicable, indicating why the action failed.

For example, to remove an OBServer from an OceanBase Cluster in ‘zone1’, the following command can be executed:

command:
- bash
- -c
- |
   ADDRESS=$(KB_MEMBER_ADDRESSES%%,*)
   HOST=$(echo $ADDRESS | cut -d ':' -f 1)
   PORT=$(echo $ADDRESS | cut -d ':' -f 2)
   CLIENT="mysql -u $KB_SERVICE_USER  -p$KB_SERVICE_PASSWORD -P $PORT -h $HOST -e"
	  $CLIENT "ALTER SYSTEM DELETE SERVER '$KB_LEAVE_MEMBER_POD_IP:$KB_SERVICE_PORT' ZONE 'zone1'"

Note: This field is immutable once it has been set.

Defines the procedure to switch a replica into the read-only state.

Use Case: This action is invoked when the database’s volume capacity nears its upper limit and space is about to be exhausted.

The container executing this action has access to following environment variables:

• KB_POD_FQDN: The FQDN of the replica pod whose role is being checked.
• KB_SERVICE_PORT: The port used by the database service.
• KB_SERVICE_USER: The username with the necessary permissions to interact with the database service.
• KB_SERVICE_PASSWORD: The corresponding password for KB_SERVICE_USER to authenticate with the database service.

Expected action output: - On Failure: An error message, if applicable, indicating why the action failed.

Note: This field is immutable once it has been set.

Defines the procedure to transition a replica from the read-only state back to the read-write state.

Use Case: This action is used to bring back a replica that was previously in a read-only state, which restricted write operations, to its normal operational state where it can handle both read and write operations.

The container executing this action has access to following environment variables:

• KB_POD_FQDN: The FQDN of the replica pod whose role is being checked.
• KB_SERVICE_PORT: The port used by the database service.
• KB_SERVICE_USER: The username with the necessary permissions to interact with the database service.
• KB_SERVICE_PASSWORD: The corresponding password for KB_SERVICE_USER to authenticate with the database service.

Expected action output: - On Failure: An error message, if applicable, indicating why the action failed.

Note: This field is immutable once it has been set.

Defines the procedure for exporting the data from a replica.

Use Case: This action is intended for initializing a newly created replica with data. It involves exporting data from an existing replica and importing it into the new, empty replica. This is essential for synchronizing the state of replicas across the system.

Applicability: Some database engines or associated sidecar applications (e.g., Patroni) may already provide this functionality. In such cases, this action may not be required.

The output should be a valid data dump streamed to stdout. It must exclude any irrelevant information to ensure that only the necessary data is exported for import into the new replica.

Note: This field is immutable once it has been set.

Defines the procedure for importing data into a replica.

Use Case: This action is intended for initializing a newly created replica with data. It involves exporting data from an existing replica and importing it into the new, empty replica. This is essential for synchronizing the state of replicas across the system.

Some database engines or associated sidecar applications (e.g., Patroni) may already provide this functionality. In such cases, this action may not be required.

Data should be received through stdin. If any error occurs during the process, the action must be able to guarantee idempotence to allow for retries from the beginning.

Note: This field is immutable once it has been set.

Defines the procedure that update a replica with new configuration.

Note: This field is immutable once it has been set.

This Action is reserved for future versions.

Defines the procedure to generate a new database account.

Use Case: This action is designed to create system accounts that are utilized for replication, monitoring, backup, and other administrative tasks.

Note: This field is immutable once it has been set.

Specifies the name of the Component as defined in the cluster.spec

The name of the env, it must be a C identifier.

The value of the env.

The source from which the value of the env.

In versions prior to KB 0.8.0, ComponentDefRef is the name of the component definition in the ClusterDefinition. In KB 0.8.0 and later versions, ComponentDefRef is the name of ComponentDefinition.

rules are the constraint rules that will be applied to the component.

Component resource constraint rules.

selector is used to bind the resource constraint to cluster definitions based on ClusterDefinition API.

componentSelector is used to bind the resource constraint to components based on ComponentDefinition API.

"pods"

(Members of `Service` are embedded into this type.)

Indicates whether to create a corresponding Service for each Pod of the selected Component. When set to true, a set of Services will be automatically generated for each Pod, and the `roleSelector` field will be ignored.

The names of the generated Services will follow the same suffix naming pattern: `$(serviceName)-$(podOrdinal)`. The total number of generated Services will be equal to the number of replicas specified for the Component.

Example usage:

name: my-service
serviceName: my-service
podService: true
disableAutoProvision: true
spec:
  type: NodePort
  ports:
  - name: http
    port: 80
    targetPort: 8080

In this example, if the Component has 3 replicas, three Services will be generated: - my-service-0: Points to the first Pod (podOrdinal: 0) - my-service-1: Points to the second Pod (podOrdinal: 1) - my-service-2: Points to the third Pod (podOrdinal: 2)

Each generated Service will have the specified spec configuration and will target its respective Pod.

This feature is useful when you need to expose each Pod of a Component individually, allowing external access to specific instances of the Component.

Indicates whether the automatic provisioning of the service should be disabled.

If set to true, the service will not be automatically created at the component provisioning. Instead, you can enable the creation of this service by specifying it explicitly in the cluster API.

Specifies the name of the referenced ComponentDefinition.

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/).

References the class defined in ComponentClassDefinition.

Deprecated since v0.9. This field is maintained for backward compatibility and its use is discouraged. Existing usage should be updated to the current preferred approach to avoid compatibility issues in future releases.

Defines a list of ServiceRef for a Component, enabling access to both external services and Services provided by other Clusters.

Types of services:

• External services: Not managed by KubeBlocks or managed by a different KubeBlocks operator; Require a ServiceDescriptor for connection details.
• Services provided by a Cluster: Managed by the same KubeBlocks operator; identified using Cluster, Component and Service names.

ServiceRefs with identical `serviceRef.name` in the same Cluster are considered the same.

Example:

serviceRefs:
  - name: "redis-sentinel"
    serviceDescriptor:
      name: "external-redis-sentinel"
  - name: "postgres-cluster"
    clusterServiceSelector:
      cluster: "my-postgres-cluster"
      service:
        component: "postgresql"

The example above includes ServiceRefs to an external Redis Sentinel service and a PostgreSQL Cluster.

Specifies Labels to override or add for underlying Pods, PVCs, Account & TLS Secrets, Services Owned by Component.

Specifies Annotations to override or add for underlying Pods, PVCs, Account & TLS Secrets, Services Owned by Component.

List of environment variables to add.

Specifies the resources required by the Component. It allows defining the CPU, memory requirements and limits for the Component’s containers.

Specifies a list of PersistentVolumeClaim templates that define the storage requirements for the Component. Each template specifies the desired characteristics of a persistent volume, such as storage class, size, and access modes. These templates are used to dynamically provision persistent volumes for the Component.

List of volumes to override.

Overrides Services defined in referenced ComponentDefinition and exposes endpoints that can be accessed by clients.

Overrides system accounts defined in the referenced `ComponentDefinition`.

Specifies the desired number of replicas in the Component for enhancing availability and durability, or load balancing.

Reserved field for future use.

Specifies which types of logs should be collected for the Cluster. The log types are defined in the `componentDefinition.spec.logConfigs` field with the LogConfig entries.

The elements in the `enabledLogs` array correspond to the names of the LogConfig entries. For example, if the `componentDefinition.spec.logConfigs` defines LogConfig entries with names “slow_query_log” and “error_log”, you can enable the collection of these logs by including their names in the `enabledLogs` array:

enabledLogs:
- slow_query_log
- error_log

Specifies the name of the ServiceAccount required by the running Component. This ServiceAccount is used to grant necessary permissions for the Component’s Pods to interact with other Kubernetes resources, such as modifying Pod labels or sending events.

Defaults: If not specified, KubeBlocks automatically assigns a default ServiceAccount named “kb-{cluster.name}”, bound to a default role defined during KubeBlocks installation.

Future Changes: Future versions might change the default ServiceAccount creation strategy to one per Component, potentially revising the naming to “kb-{cluster.name}-{component.name}”.

Users can override the automatic ServiceAccount assignment by explicitly setting the name of an existed ServiceAccount in this field.

Indicates the InstanceUpdateStrategy that will be employed to update Pods in the InstanceSet when a revision is made to Template.

Controls the concurrency of pods during initial scale up, when replacing pods on nodes, or when scaling down. It only used when `PodManagementPolicy` is set to `Parallel`. The default Concurrency is 100%.

PodUpdatePolicy indicates how pods should be updated

• `StrictInPlace` indicates that only allows in-place upgrades. Any attempt to modify other fields will be rejected.
• `PreferInPlace` indicates that we will first attempt an in-place upgrade of the Pod. If that fails, it will fall back to the ReCreate, where pod will be recreated.
• `Recreate` indicates that recreate the Pod no matter what fields being updated. Default value is “PreferInPlace”

Specifies a group of affinity scheduling rules for the Component. It allows users to control how the Component’s Pods are scheduled onto nodes in the Cluster.

Allows Pods to be scheduled onto nodes with matching taints. Each toleration in the array allows the Pod to tolerate node taints based on specified `key`, `value`, `effect`, and `operator`.

• The `key`, `value`, and `effect` identify the taint that the toleration matches.
• The `operator` determines how the toleration matches the taint.

Pods with matching tolerations are allowed to be scheduled on tainted nodes, typically reserved for specific purposes.

Specifies the scheduling policy for the component.

Specifies the TLS configuration for the Component, including:

• A boolean flag that indicates whether the Component should use Transport Layer Security (TLS) for secure communication.
• An optional field that specifies the configuration for the TLS certificates issuer when TLS is enabled. It allows defining the issuer name and the reference to the secret containing the TLS certificates and key. The secret should contain the CA certificate, TLS certificate, and private key in the specified keys.

Allows for the customization of configuration values for each instance within a Component. An Instance represent a single replica (Pod and associated K8s resources like PVCs, Services, and ConfigMaps). While instances typically share a common configuration as defined in the ClusterComponentSpec, they can require unique settings in various scenarios:

For example: - A database Component might require different resource allocations for primary and secondary instances, with primaries needing more resources. - During a rolling upgrade, a Component may first update the image for one or a few instances, and then update the remaining instances after verifying that the updated instances are functioning correctly.

InstanceTemplate allows for specifying these unique configurations per instance. Each instance’s name is constructed using the pattern: $(component.name)-$(template.name)-$(ordinal), starting with an ordinal of 0. It is crucial to maintain unique names for each InstanceTemplate to avoid conflicts.

The sum of replicas across all InstanceTemplates should not exceed the total number of Replicas specified for the Component. Any remaining replicas will be generated using the default template and will follow the default naming rules.

Specifies the names of instances to be transitioned to offline status.

Marking an instance as offline results in the following:

1. The associated Pod is stopped, and its PersistentVolumeClaim (PVC) is retained for potential future reuse or data recovery, but it is no longer actively used.
2. The ordinal number assigned to this instance is preserved, ensuring it remains unique and avoiding conflicts with new instances.

Setting instances to offline allows for a controlled scale-in process, preserving their data and maintaining ordinal consistency within the Cluster. Note that offline instances and their associated resources, such as PVCs, are not automatically deleted. The administrator must manually manage the cleanup and removal of these resources when they are no longer needed.

Defines runtimeClassName for all Pods managed by this Component.

Determines whether metrics exporter information is annotated on the Component’s headless Service.

If set to true, the following annotations will not be patched into the Service:

• “monitor.kubeblocks.io/path”
• “monitor.kubeblocks.io/port”
• “monitor.kubeblocks.io/scheme”

These annotations allow the Prometheus installed by KubeBlocks to discover and scrape metrics from the exporter.

Stop the Component. If set, all the computing resources will be released.

Specifies the most recent generation observed for this Component object.

Represents a list of detailed status of the Component object. Each condition in the list provides real-time information about certain aspect of the Component object.

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

Indicates the current phase of the Component, with each phase indicating specific conditions:

• Creating: The initial phase for new Components, transitioning from ‘empty’(“”).
• Running: All Pods in a Running state.
• Updating: The Component is currently being updated, with no failed Pods present.
• Abnormal: Some Pods have failed, indicating a potentially unstable state. However, the cluster remains available as long as a quorum of members is functioning.
• Failed: A significant number of Pods or critical Pods have failed The cluster may be non-functional or may offer only limited services (e.g, read-only).
• Stopping: All Pods are being terminated, with current replica count at zero.
• Stopped: All associated Pods have been successfully deleted.
• Deleting: The Component is being deleted.

A map that stores detailed message about the Component. Each entry in the map provides insights into specific elements of the Component, such as Pods or workloads.

Keys in this map are formatted as `ObjectKind/Name`, where `ObjectKind` could be a type like Pod, and `Name` is the specific name of the object.

Represents the switchover process for a specified candidate primary or leader instance. Note that only Action.Exec is currently supported, while Action.HTTP is not.

Represents a switchover process that does not involve a specific candidate primary or leader instance. As with the previous field, only Action.Exec is currently supported, not Action.HTTP.

Used to define the selectors for the scriptSpecs that need to be referenced. If this field is set, the scripts defined under the ‘scripts’ field can be invoked or referenced within an Action.

This field is deprecated from v0.9. This field is maintained for backward compatibility and its use is discouraged. Existing usage should be updated to the current preferred approach to avoid compatibility issues in future releases.

The name of the system account.

Specifies the policy for generating the account’s password.

This field is immutable once set.

Refers to the secret from which data will be copied to create the new account.

This field is immutable once set.

Specifies the name of the configuration template.

Specifies the name of the referenced configuration template ConfigMap object.

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

Refers to the volume name of PodTemplate. The configuration file produced through the configuration template will be mounted to the corresponding volume. Must be a DNS_LABEL name. The volume name must be defined in podSpec.containers[*].volumeMounts.

The operator attempts to set default file permissions for scripts (0555) and configurations (0444). However, certain database engines may require different file permissions. You can specify the desired file permissions here.

Must be specified as an octal value between 0000 and 0777 (inclusive), or as a decimal value between 0 and 511 (inclusive). YAML supports both octal and decimal values for file permissions.

Please note that this setting only affects the permissions of the files themselves. Directories within the specified path are not impacted by this setting. It’s important to be aware that this setting might conflict with other options that influence the file mode, such as fsGroup. In such cases, the resulting file mode may have additional bits set. Refers to documents of k8s.ConfigMapVolumeSource.defaultMode for more information.

Specifies the source to select. It can be one of three types: `FieldRef`, `ServiceRef`, `HeadlessServiceRef`.

The jsonpath of the source to select when the Type is `FieldRef`. Two objects are registered in the jsonpath: `componentDef` and `components`:

• `componentDef` is the component definition object specified in `componentRef.componentDefName`.
• `components` are the component list objects referring to the component definition object.

Defines the format of each headless service address. Three builtin variables can be used as placeholders: `$POD_ORDINAL`, `$POD_FQDN`, `$POD_NAME`

• `$POD_ORDINAL` represents the ordinal of the pod.
• `$POD_FQDN` represents the fully qualified domain name of the pod.
• `$POD_NAME` represents the name of the pod.

The string used to join the values of headless service addresses.

"FieldRef"

FromFieldRef refers to the value of a specific field in the object.

"HeadlessServiceRef"

FromHeadlessServiceRef refers to a headless service within the same namespace as the object.

"ServiceRef"

FromServiceRef refers to a service within the same namespace as the object.

(Members of `ClusterObjectReference` are embedded into this type.)

The Component to select from.

(Members of `ComponentVars` are embedded into this type.)

Reference to the name of the Component object.

Reference to the replicas of the component.

Reference to the instanceName list of the component. and the value will be presented in the following format: instanceName1,instanceName2,…

Reference to the pod FQDN list of the component. The value will be presented in the following format: FQDN1,FQDN2,…

CompDefs specifies names for the component definitions associated with this ComponentVersion. Each name in the list can represent an exact name, a name prefix, or a regular expression pattern.

For example:

• “mysql-8.0.30-v1alpha1”: Matches the exact name “mysql-8.0.30-v1alpha1”
• “mysql-8.0.30”: Matches all names starting with “mysql-8.0.30”
• ”^mysql-8.0.\d{1,2}$“: Matches all names starting with “mysql-8.0.” followed by one or two digits.

Releases is a list of identifiers for the releases.

Name is a unique identifier for this release. Cannot be updated.

Changes provides information about the changes made in this release.

ServiceVersion defines the version of the well-known service that the component provides. The version should follow the syntax and semantics of the “Semantic Versioning” specification (http://semver.org/). If the release is used, it will serve as the service version for component instances, overriding the one defined in the component definition. Cannot be updated.

Images define the new images for different containers within the release.

CompatibilityRules defines compatibility rules between sets of component definitions and releases.

Releases represents different releases of component instances within this ComponentVersion.

ObservedGeneration is the most recent generation observed for this ComponentVersion.

Phase valid values are ``,`Available`, 'Unavailable`. Available is ComponentVersion become available, and can be used for co-related objects.

Extra message for current phase.

ServiceVersions represent the supported service versions of this ComponentVersion.

Specifies the name of the volume. It must be a DNS_LABEL and unique within the pod. More info can be found at: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names Note: This field cannot be updated.

Specifies whether the creation of a snapshot of this volume is necessary when performing a backup of the Component.

Note: This field cannot be updated.

Sets the critical threshold for volume space utilization as a percentage (0-100).

Exceeding this percentage triggers the system to switch the volume to read-only mode as specified in `componentDefinition.spec.lifecycleActions.readOnly`. This precaution helps prevent space depletion while maintaining read-only access. If the space utilization later falls below this threshold, the system reverts the volume to read-write mode as defined in `componentDefinition.spec.lifecycleActions.readWrite`, restoring full functionality.

Note: This field cannot be updated.

Specifies the dynamic reload action supported by the engine. When set, the controller executes the method defined here to execute hot 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 `reloadStaticParamsBeforeRestart` is set to true, modifications to `staticParameters` can also trigger a reload.
2. `reloadOptions` is set.

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

Example:

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

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.

Configures whether the dynamic reload specified in `reloadOptions` 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 “true” option is for certain engines that require static parameters to be set via SQL statements before they can take effect on restart.

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.

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.

A list of ScriptConfig Object.

Each 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 and DownwardAction to perform specific tasks or configurations.

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

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

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

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

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

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 `selector` allows you to specify label selectors to target the desired pods for the reload process.

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

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:

formatterConfig:
 format: ini
 iniConfig:
   sectionName: mysqld

Specifies the status of the configuration template. When set to CCAvailablePhase, the ConfigConstraint can be referenced by ClusterDefinition or ClusterVersion.

Provides descriptions for abnormal states.

Refers to the most recent generation observed for this ConfigConstraint. This value is updated by the API Server.

(Members of `ResourceMeta` are embedded into this type.)

ConfigMap specifies the ConfigMap to be mounted as a volume.

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.

Represents the updated parameters for a single configuration file.

Specifies the name of the referenced configuration template ConfigMap object.

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

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

Specifies the name of the configuration template.

Defines the upgrade policy for the configuration.

Sets the configuration files and their associated parameters that need to be updated. It should contain at least one item.

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.

Deprecated: No longer used. Please use ‘Payload’ instead. Previously represented the version of the configuration template.

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.

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.

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.

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.

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.

Indicates the current status of the configuration item.

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

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

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

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

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

Indicates the name of the configuration template (as ConfigMap).

Records the UpgradePolicy of the configuration change operation.

Represents the current state of the reconfiguration state machine. Possible values include “Creating”, “Init”, “Running”, “Pending”, “Merged”, “MergeFailed”, “FailedAndPause”, “Upgrading”, “Deleting”, “FailedAndRetry”, “Finished”, “ReconfigurePersisting”, “ReconfigurePersisted”.

Provides details about the operation.

Records the number of pods successfully updated following a configuration change.

Represents the total count of pods intended to be updated by a configuration change.

Records the last state of the reconfiguration finite state machine. Possible values include “None”, “Retry”, “Failed”, “NotSupport”, “FailedAndRetry”.

• “None” describes fsm has finished and quit.
• “Retry” describes fsm is running.
• “Failed” describes fsm is failed and exited.
• “NotSupport” describes fsm does not support the feature.
• “FailedAndRetry” describes fsm is failed in current state, but can be retried.

Stores the last applied configuration.

Contains the updated parameters.

"Creating"

"Deleting"

"FailedAndPause"

"FailedAndRetry"

"Finished"

"Init"

"MergeFailed"

"Merged"

"Pending"

"Running"

"Upgrading"

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

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

ConfigItemDetails is an array of ConfigurationItemDetail objects.

Each ConfigurationItemDetail 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 ConfigurationItemDetail 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)

Provides a description of any abnormal status.

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

Provides detailed status information for opsRequest.

Provides the status of each component undergoing reconfiguration.

Specifies the username for the external service.

Specifies the password for the external service.

Represents the key of the password in the connection credential secret. If not specified, the default key “password” is used.

Represents the key of the username in the connection credential secret. If not specified, the default key “username” is used.

Defines the key of the host in the connection credential secret.

Indicates map key of the port in the connection credential secret.

Specifies the name of the consensus member.

Specifies the services that this member is capable of providing.

Indicates the number of Pods that perform this role. The default is 1 for `Leader`, 0 for `Learner`, others for `Followers`.

(Members of `StatefulSetSpec` are embedded into this type.)

Represents a single leader in the consensus set.

Members of the consensus set that have voting rights but are not the leader.

Represents a member of the consensus set that does not have voting rights.

The name of the container.

Container port to reference.

Holds a direct string or an expression that can be evaluated to a string.

It can include variables denoted by $(VAR_NAME). These variables are expanded to the value of the environment variables defined in the container. If a variable cannot be resolved, it remains unchanged in the output.

To escape variable expansion and retain the literal value, use double $ characters.

For example:

• ”$(VAR_NAME)” will be expanded to the value of the environment variable VAR_NAME.
• ”$$(VAR_NAME)” will result in “$(VAR_NAME)” in the output, without any variable expansion.

Default value is an empty string.

Specifies the source for the variable’s value.

(Members of `ClusterObjectReference` are embedded into this type.)

The Credential (SystemAccount) to select from.

(Members of `CredentialVars` are embedded into this type.)

The key of the label.

The value of the label.

The resources that will be patched with the label.

Specifies the name of the OpsDefinition.

Specifies the name of the ServiceAccount to be used for executing the custom operation.

Specifies the maximum number of components to be operated on concurrently to mitigate performance impact on clusters with multiple components.

It accepts an absolute number (e.g., 5) or a percentage of components to execute in parallel (e.g., “10%”). Percentages are rounded up to the nearest whole number of components. For example, if “10%” results in less than one, it rounds up to 1.

When unspecified, all components are processed simultaneously by default.

Note: This feature is not implemented yet.

Specifies the components and their parameters for executing custom actions as defined in OpsDefinition. Requires at least one component.

(Members of `ComponentOps` are embedded into this type.)

Specifies the name of the Component.

Specifies the parameters that match the schema specified in the `opsDefinition.spec.parametersSchema`.

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.

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

Specifies the environment variable key in the mapping.

Specifies the source used to derive the value of the environment variable, which typically represents the tool image required for backup operation.

Name of the variable. Must be a C_IDENTIFIER.

Variable references `$(VAR_NAME)` are expanded using the previously defined variables in the current context.

If a variable cannot be resolved, the reference in the input string will be unchanged. Double `$$` are reduced to a single `$`, which allows for escaping the `$(VAR_NAME)` syntax: i.e.

• `$$(VAR_NAME)` will produce the string literal `$(VAR_NAME)`.

Escaped references will never be expanded, regardless of whether the variable exists or not. Defaults to “”.

Source for the variable’s value. Cannot be used if value is not empty.

A Go template expression that will be applied to the resolved value of the var.

The expression will only be evaluated if the var is successfully resolved to a non-credential value.

The resolved value can be accessed by its name within the expression, system vars and other user-defined non-credential vars can be used within the expression in the same way. Notice that, when accessing vars by its name, you should replace all the “-” in the name with “_”, because of that “-” is not a valid identifier in Go.

All expressions are evaluated in the order the vars are defined. If a var depends on any vars that also have expressions defined, be careful about the evaluation order as it may use intermediate values.

The result of evaluation will be used as the final value of the var. If the expression fails to evaluate, the resolving of var will also be considered failed.

Specifies the container name in the target Pod. If not specified, the first container will be used by default.

Defines the name of the environment variable. This name can originate from an ‘env’ entry or be a data key from an ‘envFrom’ source.

Specifies the command to be executed inside the container. The working directory for this command is the container’s root directory(‘/’). Commands are executed directly without a shell environment, meaning shell-specific syntax (‘|’, etc.) is not supported. If the shell is required, it must be explicitly invoked in the command.

A successful execution is indicated by an exit status of 0; any non-zero status signifies a failure.

Args represents the arguments that are passed to the `command` for execution.

Specifies the name of the built-in metrics exporter container.

Specifies the http/https url path to scrape for metrics. If empty, Prometheus uses the default value (e.g. `/metrics`).

Specifies the port name to scrape for metrics.

Specifies the schema to use for scraping. `http` and `https` are the expected values unless you rewrite the `__scheme__` label via relabeling. If empty, Prometheus uses the default value `http`.

scrapePort is exporter port for Time Series Database to scrape metrics.

scrapePath is exporter url path for Time Series Database to scrape metrics.

Specifies the name of the Component.

Indicates whether the services will be exposed. ‘Enable’ exposes the services. while ‘Disable’ removes the exposed Service.

Specifies a list of OpsService. When an OpsService is exposed, a corresponding ClusterService will be added to `cluster.spec.services`. On the other hand, when an OpsService is unexposed, the corresponding ClusterService will be removed from `cluster.spec.services`.

Note: If `componentName` is not specified, the `ports` and `selector` fields must be provided in each OpsService definition.

"Disable"

"Enable"

"Fail"

FailurePolicyFail means that an error will be reported.