Custom Configuration in Kubernetes
The Redpanda operator for Kubernetes creates clusters based on the Custom Resource Definition (CRD). After you install the Redpanda operator, you apply the CRD. The CRD contains the basic configuration for the Redpanda cluster, including the cluster name and namespace, and the configuration for the APIs.
Configuring the CRD
In addition to the cluster properties that are included in the CRD by default, you can add additional properties under the additionalConfiguration
section of the CRD. These properties can be cluster-level or node-level. Node-level configuration properties are passed to the redpanda.yaml
configuration file. The Redpanda operator uses the Admin API to update cluster-level properties.
The format of each property in the additionalConfiguration
section of the CRD is:
<subsystem>.<property_name>: <value>
For example, the CRD might have the following additionalConfiguration
section:
additionalConfiguration:
redpanda.enable_idempotence: "true"
redpanda.default_topic_partitions: "3"
pandaproxy_client.retries: "10"
schema_registry.schema_registry_replication_factor: "3"
This example references the following subsystems: redpanda
, pandaproxy_client
(this refers to the HTTP Proxy client), and schema_registry
. Each subsystem is followed by a property name and a value for the property. For a more detailed example of the CRD with the additionalConfiguration
section included, see the CRD example section below.
Note that the Redpanda operator does not check for version compatibility of the properties in the additionalConfiguration
section of the CRD. You might try to apply a property that is not supported by the Redpanda version that the cluster is running. Therefore, it is recommended that you verify the CRD after you make a change. This is explained in the Verifying the CRD section below.
Modifying the CRD
To modify properties, edit the CRD file, save it, and execute it as follows:
kubectl apply -f <custom_resource.yaml>
If a change to the property requires a restart of the cluster, the operator will perform the restart automatically.
If you want to view whether a change to a property requires a restart, see Cluster-level properties.
It is possible to change cluster-level configuration properties through the Admin API. However, if the property in the CRD contains a different value than the value that you set through the Admin API, the value set through the Admin API will eventually be overwritten. If the property does not exist in the CRD, you can change it through the Admin API and there will be no conflict. However, because there is the possibility of a property value being overwritten, it is recommended that you set properties in the CRD. |
Verifying the CRD
It is a best practice to verify that your CRD is applied to the cluster successfully after you make a change to the configuration. This is useful if you have a typo in the CRD or if you are trying to apply a new property that is not supported for the version of Redpanda that your cluster is running on.
For example, you might add the following additionalConfiguration
section to the CRD:
additionalConfiguration:
redpanda.cluster_idd: allosaurus
In the example, there is a typo in the cluster_id
property name, with an additional d
. After saving the file with the typo, run the kubectl apply
command to apply the modified CRD.
To verify that the cluster was configured successfully:
kubectl get cluster -o yaml
If there is an error, the status
section of the output will notify you and look like the following:
status:
conditions:
- lastTransitionTime: "2022-04-01T13:11Z"
message: '{cluster_idd":"Unknown property"}'
reason: Error
status: "False"
type: ClusterConfigured
Note that there is a message that there is an unknown property, the reason is that there was an error, and the ClusterConfigured
status is False
. In this case, the cluster will continue to run without making a change to the configuration, whether or not a change to the property would require a cluster restart.
After you fix the typo, the status
section of the kubectl get cluster-o yaml
output will look like the following:
status:
conditions:
- lastTransitionTime: "2022-04-01T13:11Z"
status: "True"
type: ClusterConfigured
CRD example
The file below is the one_node_cluster.yaml sample file from the redpanda-examples GitHub repository. In this example, the additionalConfiguration
section is appended to the end of the file, with one property defined. This section of the file is highlighted.
apiVersion: redpanda.vectorized.io/v1alpha1
kind: Cluster
metadata:
name: one-node-cluster
spec:
image: "docker.redpanda.com/redpandadata/redpanda"
version: "latest"
replicas: 1
resources:
requests:
cpu: 1
memory: 1.2Gi
limits:
cpu: 1
memory: 1.2Gi
configuration:
rpcServer:
port: 33145
kafkaApi:
- port: 9092
pandaproxyApi:
- port: 8082
schemaRegistry:
port: 8081
adminApi:
- port: 9644
developerMode: true
additionalConfiguration:
redpanda.cluster_id: allosaurus
The additionalConfiguration
section of the CRD example contains a cluster-level property, cluster_id
.
In this example, the cluster ID is revised to mapusaurus
. To do that, edit the cluster_id
property in the CRD so that the additionalConfiguration
section looks like this:
additionalConfiguration:
redpanda.cluster_id: mapusaurus
Save the file, and run the following command to apply the change:
kubectl apply -f one-node-cluster.yaml
Now you can run the following rpk
command to retrieve the cluster ID:
kubectl exec one-node-cluster-0 -- rpk cluster config get cluster_id
The command will return something like the following, with the updated cluster ID:
Defaulted container "redpanda" out of: redpanda, redpanda-configurator (init)
mapusaurus