<a id="co-config-overview"></a>

# Configure Confluent Platform for Deployment with Confluent for Kubernetes

This topic describes how to work with Kubernetes custom resources (CR) to
configure and manage Confluent Platform. The rest of the topics in this section go into
detail on configuring specific settings for Confluent components.

<a id="co-custom-resources"></a>

## Kubernetes Custom Resources for Confluent Platform

Confluent Platform components are deployed to a Kubernetes cluster as custom resources (CRs).
Confluent for Kubernetes (CFK) provides the custom resource definitions (CRDs) that were
created using Kubernetes API. These 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.

For the settings that are not supported in Confluent CRDs, CFK automatically
calculates and sets the values based on the relevant factors. For example, the
`default.replication.factor` and `min.insync.replicas` Kafka configuration
values are set based on the broker replica count.

If you need to override these default configuration values that CFK sets, or
to provide additional configuration information that is not supported in the
CRDs, you can use the [configuration overrides](co-configure-misc.md#co-config-overrides)
feature in CFK to pass the configuration property to Kafka.

For the configuration settings for Confluent Platform components, see [Confluent Platform
Configuration Reference](https://docs.confluent.io/platform/current/installation/configuration/index.html).
For example, supported Kafka configuration settings can be found in [Kafka
Broker Configurations](https://docs.confluent.io/platform/current/installation/configuration/broker-configs.html).

<a id="co-kubectl-explain"></a>

### Use kubectl to examine Confluent Platform CRDs

The [kubectl explain](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#explain)
command describes the fields associated with Kubernetes API resources, including
the Confluent Platform CRDs.

1. To get a list of the Confluent Platform CRDs:
   ```bash
   kubectl api-resources --api-group=platform.confluent.io
   ```
2. To describe a specific Confluent Platform CRD:
   ```bash
   kubectl explain <CRD-type>.<fieldName>[.<fieldName>]
   ```

   You can drill down the CRD specification by appending a `<fieldName>`
   from the `kubectl explain` output.

   For example:
   ```bash
   kubectl explain kafka.spec.podTemplate
   ```

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

<a id="co-plugin"></a>

### 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 [Confluent kubectl plugin](co-install-plugin.md#co-install-plugin) for installation instructions.

Use the following command to get the comprehensive usage instruction:

```bash
kubectl confluent
```

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:
  ```bash
  kubectl confluent http-endpoints
  ```
* To convert Operator 1.x to CFK 2.0:
  ```bash
  kubectl confluent migration
  ```
* To check if the current user has cluster-level access:
  ```bash
  kubectl confluent operator --namespaced=false pre-check
  ```
* To check if the current user has the namespaced level access:
  ```bash
  kubectl confluent operator pre-check
  ```

## CFK overrides of Confluent Platform default configuration

In some cases, CFK overrides and uses default configuration values that are
different from the Confluent Platform default values. The following table lists some of those
overridden default configurations.

| Component   | Field                                     | Confluent Platform Default Value   | CFK Enforced Value        |
|-------------|-------------------------------------------|------------------------------------|---------------------------|
| Connect     | `connector.client.config.override.policy` | None                               | All                       |
| Kafka       | `replica.lag.time.max.ms`                 | 30000                              | 45000 <sup>[1](#f1)</sup> |
* <a id='f1'>**[1]**</a> This configuration controls the maximum amount of time the replica follower can be behind the replica leader. If this is too low and the network intermittently experiences delays, it will cause the replica leader to remove replica followers intermittently from ISR list.  Since CFK deployments pods might get distributed in multiple availability zones, this value has been set to 45000 instead of 30000.