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. For the specific versions supported, see the Supported Versions section.

• Install kubectl.

• Configure the 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.

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.

Note

Starting with version 3.2.0, on Linux s390x architecture, the Confluent for Kubernetes image is available only for Managing Flink Applications. 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.

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.

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
Debian 12	6.1	N/A
Debian 10	4.19	N/A
Ubuntu 22	5.15	Kernels covered by Livepatch
Ubuntu 20	5.4	Kernels covered by Livepatch
RHEL 9	5.14	Red Hat Enterprise Linux
RHEL 8	4.18	Red Hat Enterprise Linux

Helm

Helm 3 is required for Confluent for Kubernetes.

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.

For the CFK image tag of a specific patch release, see Confluent for Kubernetes 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 (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 (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 (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 (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 (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 (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 (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.

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.

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.

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.

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

Confluent for Kubernetes image tags

The Confluent Platform and Confluent for Kubernetes images are hosted in the confluentinc repository 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 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:

kubectl confluent cluster list-crd

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.

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 and 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

• Deploy Confluent for Kubernetes

• Configure Confluent Platform for Deployment with Confluent for Kubernetes

• Deploy Confluent Platform using Confluent for Kubernetes

• Manage Confluent Platform with Confluent for Kubernetes

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.