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

<a id="co-supported-environments"></a>

# Supported Environments and Versions

Confluent for Kubernetes supports specific Kubernetes environments, hardware, operating
systems, and Confluent Platform versions. Review and address the following prerequisites
before you start the installation process.

## Kubernetes

* Confluent for Kubernetes 3.3 supports the Kubernetes distributions with [Cloud Native
  Computing Foundation (CNCF) conformant offerings](https://www.cncf.io/certification/software-conformance/). For the specific
  versions supported, see the
  [Supported Versions](#co-operator-supported-versions) section.
* Install [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/).
* Configure the [kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
  file for your cluster.

If you are using Red Hat OpenShift as your Kubernetes distribution, you must
work with Red Hat’s Security Context Constraint (SCC). For more details, refer to
[Security considerations for Red Hat OpenShift](https://github.com/confluentinc/confluent-kubernetes-examples/tree/master/security/openshift-security).

## Hardware

The underlying processor architecture of your Kubernetes worker nodes must be a
supported version for the Confluent Platform version you plan to deploy.

Currently, Confluent Platform supports `x86` and `ARM64` hardware architectures. For supported hardware for a specific version of Confluent Platform, see [Hardware
Requirements for Confluent Platform](https://docs.confluent.io/platform/current/installation/system-requirements.html#hardware).

#### NOTE
Starting with version 3.2.0, on Linux s390x architecture, the Confluent for Kubernetes image is available
only for [Managing Flink Applications](co-manage-flink.md#co-manage-flink). CFK does not support deploying or managing Confluent Platform
on Linux s390x. While Confluent provides CFK Docker images for Linux s390x, Confluent
doesn’t support issues specific to this architecture. Confluent provides support only if
the issue also occurs on a supported architecture, such as Linux AMD64 or Linux ARM64.
To discuss third-party support options for Linux s390x, contact [Confluent support](https://support.confluent.io/hc/en-us).

## Operating systems

The operating system (OS) of your Kubernetes worker nodes must match the
supported Linux kernel version for the Confluent Platform version you plan to deploy.

Supported Linux kernels are the kernels that the supported Linux OS
distributions are built upon. For supported OSs for a specific version of Confluent Platform,
see [OS Requirements for Confluent Platform](https://docs.confluent.io/platform/current/installation/system-requirements.html#operating-systems).

Even if an OS is not on the Confluent Platform supported list, you can still deploy CFK on the
container-optimized OS for the Kubernetes worker nodes if that OS is based on
the same Linux kernel.

For example, you can deploy Confluent Platform 7.9 with CFK 2.11 on Bottlerocket because the
OS is built on the same Linux kernel 6.1 as AWS Linux 2023 certified for Confluent Platform.

Supported Linux kernel versions in CFK 3.3 are:

| OS Distro and Version   |   Linux Kernel Version | Reference                                                                                                                      |
|-------------------------|------------------------|--------------------------------------------------------------------------------------------------------------------------------|
| AWS Linux 2023          |                   6.1  | [AL2023 kernel changes from AL2 - Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2-kernel.html) |
| Debian 12               |                   6.1  | N/A                                                                                                                            |
| Debian 10               |                   4.19 | N/A                                                                                                                            |
| Ubuntu 22               |                   5.15 | [Kernels covered by Livepatch](https://ubuntu.com/security/livepatch/docs/livepatch/reference/kernels)                         |
| Ubuntu 20               |                   5.4  | [Kernels covered by Livepatch](https://ubuntu.com/security/livepatch/docs/livepatch/reference/kernels)                         |
| RHEL 9                  |                   5.14 | [Red Hat Enterprise Linux](https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#RHEL_9)                                      |
| RHEL 8                  |                   4.18 | [Red Hat Enterprise Linux](https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#RHEL_8)                                      |

## Helm

[Helm 3](https://helm.sh/docs/intro/install/) is required for Confluent for Kubernetes.

<a id="co-operator-supported-versions"></a>

## Confluent Platform

The following table shows the compatibility information with CFK, Confluent Platform,
Unified Stream Manager, Control Center, and Kubernetes.

The Kubernetes versions column lists the Kubernetes and OpenShift
versions supported for the first release of a specific CFK version, for
example, 2.10.0 for CFK 2.10.x. For the supported Kubernetes and OpenShift
versions of the subsequent patch releases, see the [release notes](release-notes.md#release-notes).

For the CFK image tag of a specific patch release, see [Confluent for Kubernetes image tags](#co-operator-image-tags).

| CFK Operator Version   | Confluent Platform Versions   | USM Versions   | Control Center Versions   | Kubernetes Versions                          | Release Date   | Standard End of Support   |
|------------------------|-------------------------------|----------------|---------------------------|----------------------------------------------|----------------|---------------------------|
| CFK 3.3.x              | 7.5.x - 8.3.x                 | 1.0.x - 1.1.x  | 2.4.x - 2.6.x             | 1.28 - 1.36<br/><br/>(OpenShift 4.15 - 4.22) | Jun 23, 2026   | Jun 23, 2028              |
| CFK 3.2.x              | 7.4.x - 8.2.x                 | 1.0.x - 1.1.x  | 2.4.x - 2.6.x             | 1.27 - 1.35<br/><br/>(OpenShift 4.14 - 4.21) | Mar 11, 2026   | Mar 11, 2028              |
| CFK 3.1.x              | 7.3.x - 8.1.x                 | 1.0.x - 1.1.x  | 2.3.x                     | 1.26 - 1.34<br/><br/>(OpenShift 4.13 - 4.20) | Oct 15, 2025   | Oct 15, 2027              |
| CFK 3.0.x              | 7.2.x - 8.0.x                 | N/A            | 2.2.x                     | 1.25 - 1.33<br/><br/>(OpenShift 4.12 - 4.20) | Jun 13, 2025   | Jun 13, 2027              |
| CFK 2.11.x             | 7.1.x - 7.9.x                 | N/A            | 2.0.x - 2.1.x             | 1.25 - 1.32<br/><br/>(OpenShift 4.12 - 4.19) | Feb 21, 2025   | Feb 21, 2027              |
| CFK 2.10.x             | 7.1.x - 7.8.x                 | N/A            | N/A                       | 1.25 - 1.31<br/><br/>(OpenShift 4.12 - 4.18) | Dec 4, 2024    | Dec 4, 2026               |
| CFK 2.9.x              | 7.0.x - 7.7.x                 | N/A            | N/A                       | 1.25 - 1.30<br/><br/>(OpenShift 4.12 - 4.17) | Jul 30, 2024   | Jul 30, 2026              |
* Starting with CFK 2.9, the standard support policy of CFK is for two years
  from the first patch release (`.0`) date.
* Platinum tier support is not offered for CFK.
* You can apply your Confluent Platform Platinum tier support contract to the Confluent Platform components
  deployed by CFK when both of the following conditions are true:
  - You are on a currently supported version of CFK.
  - The Confluent Platform version you want to use is compatible with a currently supported
    version of CFK.

<a id="co-gateway-supported-versions"></a>

## Confluent Private Cloud Gateway

The following table shows the compatibility information between CFK and
Confluent Private Cloud Gateway.

| CFK Operator Version   | Confluent Private Cloud Gateway Versions      |
|------------------------|-----------------------------------------------|
| CFK 3.3.x              | Confluent Private Cloud Gateway 1.2.x - 1.3.x |
| CFK 3.2.x              | Confluent Private Cloud Gateway 1.1.x - 1.2.x |
| CFK 3.1.x              | Confluent Private Cloud Gateway 1.1.x         |

For Confluent Private Cloud Gateway release date, end of support, and other information, see
[Confluent Private Cloud Gateway Support and Maintenance Policy](https://docs.confluent.io/private-cloud-gateway/current/gateway-deploy-overview.html#support-and-maintenance-policy).

## Kafka inter-broker protocol version

When you perform a greenfield installation of Confluent Platform using CFK, set the Apache Kafka®
inter-broker protocol (IBP) version to make sure you use the correct version of
IBP and avoid issues during deployments and future upgrades.

Set the IBP version in the Kafka custom resource (CR) according to the version of
Kafka you are installing. For the correct IBP version, refer to the table in the
[Confluent Platform Upgrade Guide](https://docs.confluent.io/platform/current/installation/upgrade.html#steps-for-upgrading-to-version-x).

```yaml
kind: Kafka
spec:
  configOverrides:
    server:
      - inter.broker.protocol.version=<current Kafka broker protocol version>
```

The example below is for installing Confluent Platform 8.3.
`inter.broker.protocol.version` is set to `4.3` that
corresponds to 8.3.

```yaml
kind: Kafka
spec:
  configOverrides:
    server:
      - inter.broker.protocol.version=4.3
```

<a id="co-operator-image-tags"></a>

## Confluent for Kubernetes image tags

The Confluent Platform and Confluent for Kubernetes images are hosted in the [confluentinc repository](https://hub.docker.com/u/confluentinc) in Docker Hub.

#### IMPORTANT
The following table documents version metadata (Operator version, image tag, and
Custom Resource Definition (CRD) version) only. Do not treat it as the source of truth for
compatibility. CRDs are backward compatible, which means older CFK
versions are compatible with newer CRDs.

As a best practice, keep the CFK version and the CRD version
the same to take advantage of all the latest features.

In a multi-operator, single-CRD setup, always install and maintain CRDs
from the highest Operator version present, and use `--skip-crds` on all
lower-version Helm installations to prevent accidental CRD downgrade.

The image tag versioning is available in:

* 2.9.5 and later versions of 2.9.x
* 2.10.1 and later versions of 2.10.x
* 2.11.0 and later versions

| CFK Operator Version   | CFK Image Tag   | CRD App Version   | CRD Chart Version   |
|------------------------|-----------------|-------------------|---------------------|
| 3.3.0                  | 0.1718.10       | 3.3.0             | v0.1718.10          |
| 3.2.3                  | 0.1514.76       | 3.2.3             | v0.1514.76          |
| 3.2.2                  | 0.1514.40       | 3.2.2             | v0.1514.40          |
| 3.2.1                  | 0.1514.19       | 3.2.1             | v0.1514.19          |
| 3.2.0                  | 0.1514.1        | 3.2.0             | v0.1514.1           |
| 3.1.3                  | 0.1351.147      | 3.1.3             | v0.1351.147         |
| 3.1.2                  | 0.1351.103      | 3.1.2             | v0.1351.103         |
| 3.1.1                  | 0.1351.59       | 3.1.1             | v0.1351.59          |
| 3.1.0                  | 0.1351.24       | 3.1.0             | v0.1351.24          |
| 3.0.5                  | 0.1263.163      | 3.0.5             | v0.1263.163         |
| 3.0.4                  | 0.1263.124      | 3.0.4             | v0.1263.124         |
| 3.0.3                  | 0.1263.105      | 3.0.3             | v0.1263.105         |
| 3.0.2                  | 0.1263.79       | 3.0.2             | v0.1263.79          |
| 3.0.1                  | 0.1263.34       | 3.0.1             | v0.1263.34          |
| 3.0.0                  | 0.1263.8        | 3.0.0             | v0.1263.8           |
| 2.11.6                 | 0.1193.192      | 2.11.6            | v0.1193.192         |
| 2.11.5                 | 0.1193.151      | 2.11.5            | v0.1193.151         |
| 2.11.4                 | 0.1193.108      | 2.11.4            | v0.1193.108         |
| 2.11.3                 | 0.1193.70       | 2.11.3            | v0.1193.70          |
| 2.11.2                 | 0.1193.47       | 2.11.2            | v0.1193.47          |
| 2.11.1                 | 0.1193.34       | 2.11.1            | v0.1193.34          |
| 2.11.0                 | 0.1193.1        | 2.11.0            | v0.1193.1           |
| 2.10.6                 | 0.1145.181      | 2.10.6            | v0.1145.181         |
| 2.10.5                 | 0.1145.141      | 2.10.5            | v0.1145.141         |
| 2.10.4                 | 0.1145.102      | 2.10.4            | v0.1145.102         |
| 2.10.3                 | 0.1145.71       | 2.10.3            | v0.1145.71          |
| 2.10.2                 | 0.1145.50       | 2.10.2            | v0.1145.50          |
| 2.10.1                 | 0.1145.35       | 2.10.1            | v0.1145.35          |
| 2.9.10                 | 0.1033.238      | 2.9.10            | v0.1033.238         |
| 2.9.9                  | 0.1033.196      | 2.9.9             | v0.1033.196         |
| 2.9.8                  | 0.1033.150      | 2.9.8             | v0.1033.150         |
| 2.9.7                  | 0.1033.110      | 2.9.7             | v0.1033.110         |
| 2.9.6                  | 0.1033.87       | 2.9.6             | v0.1033.87          |
| 2.9.5                  | 0.1033.71       | 2.9.5             | v0.1033.71          |

#### NOTE
Ensure that the `confluent-init-container` image uses the same version
as your CFK operator. The `confluent-init-container` image is tagged
with the CFK release version, not the CFK image tag shown in the
table. For example, `3.3.0`. When you upgrade CFK,
update the `confluent-init-container` image with the operator. For
details, see the [CFK upgrade](co-upgrade-cfk.md#co-upgrade-init-container) process.

Do not use a `confluent-init-container` image that is on a different
version than the operator. Version mismatches can cause failures or
prevent your deployment from using all features of the running CFK
version.

To get the list of your current CFK CRDs and the versions, install the Confluent
kubectl plugin and run the following plugin option:

```bash
kubectl confluent cluster list-crd
```

<a id="co-docker-registry"></a>

## Docker registry

Confluent for Kubernetes pulls Confluent Docker images from a Docker registry and deploys those
onto your Kubernetes cluster.

By default, Confluent for Kubernetes deploys publicly available Docker images hosted on Docker
Hub from the `confluentinc` repositories.

If you choose to use your own Docker registry and repositories, you need to pull
the images from the Confluent repositories and upload them to your Docker
registry repositories.

For details on using a custom private registry, see [Use Custom Docker Registry for Confluent Platform Using Confluent for Kubernetes](co-custom-registry.md#co-custom-registry).

<a id="co-support-boundaries"></a>

## Support for Kubernetes ecosystem

Confluent for Kubernetes (CFK) includes Kubernetes Controllers and
business logic that automatically configure, deploy, and manage multiple
aspects of Confluent Platform on your chosen Kubernetes.

CFK uses the standard Kubernetes API. CFK doesn’t
manage aspects beyond the Kubernetes API, such as vendor implementations like
Amazon Elastic Load Balancing (ELB), or storage classes like Amazon
Elastic Block Store (EBS).

The following examples illustrate the support boundaries of CFK.

* For storage, the Kubernetes API implements and provides the APIs for the
  `StorageClass`, `PersistentVolumes`, and `PersistentVolumeClaims`
  resources. When CFK configures and deploys Kafka brokers, it takes a
  user-provided `StorageClass` resource and uses that to create a
  `PersistentVolumeClaim` resource for the Kafka broker storage. CFK does
  not check and validate what’s in the user-provided `StorageClass`
  resource. CFK does not check whether the persistent volume is created.
  CFK relies on the storage vendor implementation for that.
* For networking with load balancers, the Kubernetes API implements and provides
  the APIs for [Network Service](https://kubernetes.io/docs/concepts/services-networking/service/) and
  [LoadBalancer](https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer).
  When CFK configures and deploys Kafka with a load balancer, CFK creates a
  `LoadBalancer` type service, one for every Kafka broker. Kafka then relies on
  the `LoadBalancer` vendor implementation to configure and deploy the `LoadBalancer` instance. Amazon ELB, Google LB, Azure LB, and MetalLB are all
  examples of such `LoadBalancer` vendor implementations.

Within the described boundary, CFK is tested to ensure that it invokes the
Kubernetes API correctly and creates the correct Kubernetes objects.
CFK tests validate that a `LoadBalancer` type service is created with the
configurations that you specified in the Kafka broker custom resource. CFK
doesn’t test that a Google load balancer is properly configured and deployed
to route traffic to Kafka brokers. Confluent depends on the Google
implementation of the load balancer to work correctly.

With the above points in mind, consider the following guidelines
when you deploy CFK to efficiently and effectively run a production
system:

1. Identify the architecture you want to use, including the Confluent
   components and the Kubernetes runtime, and verify core deployment and
   management functions in your environment.
2. Develop a runbook and troubleshooting steps for your deployment. Ensure your
   team is familiar with this runbook before you go to production.
3. When you need support for issues in your deployment, be prepared
   to pull in the respective vendors to cover the entire architecture. If you have
   a networking issue in your CFK deployment, pull in the
   Kubernetes vendor and the vendor for the networking service you use
   along with Confluent.

## Custom deployment pipelines and support scope

Confluent documents and validates standard workflows for installing and upgrading
CFK and Confluent Platform. For most deployments, follow these workflows:

* [Namespace and RBAC Strategy](co-prepare.md#co-deployment-models)
* [Deploy Confluent for Kubernetes](co-deploy-operator.md#co-deploy-operator)
* [Configure Confluent Platform for Deployment with Confluent for Kubernetes](co-configure-overview.md#co-config-overview)
* [Deploy Confluent Platform using Confluent for Kubernetes](co-deploy-cp.md#co-deploy-cp)
* [Manage Confluent Platform with Confluent for Kubernetes](co-manage-cp.md#co-manage-cp)

Many customers integrate these documented workflows into their own continuous
integration and continuous delivery (CI/CD) systems. Confluent supports using CI/CD
to orchestrate documented workflows, provided the workflows aren’t modified in unsupported ways.

A custom deployment pipeline is any installation or upgrade flow that
significantly changes or replaces the documented workflows. Examples include:

* Generating or modifying CFK or Confluent Platform manifests in nonstandard ways.
* Inserting additional proprietary automation steps that alter the order, scope,
  or behavior of the documented workflow.
* Chaining multiple tools in a way that changes how CFK or Confluent Platform deploy or upgrade.

Confluent support is responsible for CFK and Confluent Platform behavior when you deploy
using the documented workflows, whether you run them manually or orchestrate them
with your CI/CD system. Confluent support can’t own or troubleshoot the design,
implementation, or operation of your custom CI/CD tooling and end-to-end
pipelines. Issues isolated to those pipelines are outside the scope of
standard Confluent support.