Configuration Overview for Confluent for Kubernetes¶

The following configuration options are described in this section:

Kubernetes Custom Resources for Confluent Platform¶

Confluent Platform components are deployed to a Kubernetes cluster as custom resources (CRs). Confluent for Kubernetes (CFK) creates the custom resource definitions (CRDs) via Kubernetes API, and the CRDs describe how to configure Confluent Platform components. The CRDs are provided in the yaml files in the Confluent for Kubernetes distribution in the crds directory.

If you need to provide additional configuration information that is not supported in the CRDs, you can use the configuration overrides feature in CFK to pass the configuration property to Kafka.

Use kubectl to examine Confluent Platform CRDs¶

The kubectl explain command describes the fields associated with Kubernetes API resources, including the Confluent Platform CRDs.

To get a list of the Confluent Platform CRDs:

kubectl api-resources --api-group=platform.confluent.io
Copy

To describe a specific Confluent Platform CRD:
```
kubectl explain <CRD-type>.<fieldName>[.<fieldName>]
```
Copy
You can drill down the CRD specification by appending a <fieldName> from the kubectl explain output.

For example:
```
kubectl explain kafka.spec.podTemplate
```
Copy
And to further examine the affinity field listed in the output:
```
kubectl explain kafka.spec.podTemplate.affinity
```
Copy

Confluent plugin¶

Confluent plugin is a composite CLI tool integrated with the Kubernetes ecosystem through the kubectl plugin interface. You can use the plugin to debug and diagnose your Confluent Platform deployed through Confluent for Kubernetes (CFK).

See Install Confluent plugin for installation instructions.

Use the following command to get the comprehensive usage instruction:

kubectl confluent
Copy

The following are some of the example commands:

To see all of the external and internal endpoints that you can use to access Confluent components:
```
kubectl confluent http-endpoints
```
Copy
To convert Operator 1.x to CFK 2.0:
```
kubectl confluent migration
```
Copy

To check if the current user has cluster-level access:

kubectl confluent operator --namespaced=false pre-check
Copy

To check if the current user has the namespaced level access:
```
kubectl confluent operator pre-check
```
Copy