August 3, 2023

What's New in Apache Kafka 3.5: Features to Watch

Apache Kafka

By

Kafka 3.5 made its debut about six weeks ago, on June 15, 2023. The community is energized about this new release, as it includes a number of key improvements as well as impactful deprecations. Keep reading to learn about the most notable features of Kafka 3.5.0, upgrade considerations, and what the future might hold for the popular distributed event streaming platform. 

Apache Kafka 3.5 Release Date

Kafka 3.5.0 was released on June 15, 2023.

This major release contains quite a few new features and bug fixes. A security/regression patch, 3.5.1, was also released on July 21. There are some significant changes with 3.5.0 as well as 3.5.1, and we will discuss those in this blog, and suggest some upgrade pathing from various previous versions that is relevant to this release.

Kafka Release Cadence

Kafka was initially developed by a LinkedIn team in 2010 and became a top-level Apache Software Foundation project in 2013. Since 2017, major releases have come out about every four months, with community support available for two years. Kafka 3.5 is the second release of 2023, so we can expect 3.6 to come out before the end of the year. 

For a complete list of Kafka versions and release dates, check out this table from our Apache 101 Guide. 

Kafka 3.5 Updates and Changes

The most notable efforts with updates and changes in 3.5 center around the Kafka Raft, or KRaft, implementation and its production suitability. The biggest news is that with the 3.5 release, ZooKeeper is officially marked as deprecated. That is not to say you can’t use Kafka with ZooKeeper with 3.5; you can, but it will now tell you that it is deprecated, and that it will officially be dropped in 4.0. We will go into more detail about the impacts on that later on, but first let's discuss some of the new features in Kafka 3.5. 

Kafka 3.5 New Features

  • KIP-881: Rack-aware partition assignment for Kafka consumers: Kafka 3.5 assignors can now be rack-aware. The protocol changes for KIP-881 were implemented in 3.4, but now the built-in Kafka assignors can now factor in rack awareness to their assignments.    
     
  • KIP-887: Add ConfigProvider to make use of environment variables: KIP-887 provide a retooled implementation of org.apache.kafka.common.config.provider.ConfigProvider to enable EnvVarConfigProvider to retrieve configuration elements from environment variables.    
     
  • KIP-900: KRaft kafka-storage.sh API additions to support SCRAM for Kafka Brokers: One of the challenges for implementing KRaft in some production environments was the lack of SCRAM support for broker authentication. KIP-900 implements an update to the kafka-storage tool as well as enabling SCRAM for inter-broker authentication with KRaft.    
     
  • KIP-903: Replicas with stale broker epoch should not be allowed to join the ISR: In previous versions, data loss could occur when a broker with a stale epoch joined the ISR in a specific cluster state that allowed it to join the ISR with an invalid empty log. Note: This condition can exist in both ZooKeeper and KRaft; however, the scope of KIP-903 was limited to fixing this with KRaft.    
     
  • KIP-399: Extend ProductionExceptionHandler to cover serialization exceptions: KIP-399 provides an interface within Kafka Streams to handle serialization errors when sent to a downstream sink.    
     
  • KIP-710: Full support for distributed mode in dedicated MirrorMaker 2.0 clusters: A previous KIP (KIP-382) introduced MirrorMaker 2 (MM2) to leverage the Kafka Connect framework in a dedicated MM2 cluster. However, the original KIP was missing some features, such as implementing the Connect REST API. KIP-710 rectifies these issues, making the distributed mode in dedicated MM2 clusters more feature complete.    
     
  • KAFKA-14021: MirrorMaker 2 should implement KIP-618 APIs: One of the biggest challenges with MM2 was how to handle “exactly-once” semantics. KIP-618 is a major improvement in implementing this semantic state in source connectors.

In addition to the changes in 3.5.0, 3.5.1 adds a fix for CVE-2023-34455 by upgrading the snappy-java dependency to a version not affected by the CVE. Also, a fix for a regression issue in security.protocol, which restricted values to be uppercase only, has been implemented to make security.protocol case-insensitive.     

For a complete list of Kafka 3.5.0 release changes, check out the release notes for 3.5 here and for 3.5.1 here.

NEW! Decision Maker's Guide to Apache Kafka

Download this white paper that covers enterprise configuration, partition strategy, security best practices, using Kafka with Spark, and more.

Get the Guide 

Other Notable Changes in Kafka 3.5.0

  • KIP-889: Versioned state stores: State stores utilized by Kafka Streams only maintained the latest value associated with a key. KIP-889 implements a versioned state to stores in an effort to better support temporal join semantics for stream tables.    
     
  • KIP-894: Use incrementalAlterConfigs API for syncing topic configurations: MirrorMaker previously used a deprecated AlterConfigs API that allowed MirrorMaker to sync topic configurations whether they were excluded from replication or not; KIP-894 enforces these exclusions. Note: Users running the latest MirrorMaker connector against a target cluster with brokers older than Kafka 2.3.0 will have to upgrade.    
     
  • KAFKA-14525: Move CLI tools from 'core' to 'tools' module: Tools that don't require access to 'core' classes and communicate via the Kafka protocol (typically by using the client classes) should be moved to the 'tools' module, specifically org.apache.kafka.tools.

Kafka 3.5 Deprecations

As previously mentioned, the only major deprecation in Kafka 3.5.0 is that ZooKeeper mode is now officially deprecated. Again, you can still use ZK mode with 3.5.0 if your organization is not ready to upgrade to KRaft mode, which is a real issue for larger and more mature Kafka environments.  

Migration from ZK mode to KRaft mode is still an early access feature and not quite ready for production, so it's fortunate that teams that need a true migration from ZK mode to KRaft mode can still use ZooKeeper in the 3.5.X releases. Just to be prepared to see deprecation warnings about it. 

Upgrading to Kafka 3.5 

Rolling upgrade steps for ZooKeeper implementations can be found here. There is a major change with the consumer offsets store schema for anyone upgrading from a version prior to 2.1.X — once you upgrade to the latest inter.broker.protocol.version, rolling back to pre-2.1.X state will not be possible.

Rolling upgrade steps for KRaft implementation can be found here. For anyone upgrading from a version prior to 3.3.0, keep in mind that once you have changed the metadata.version to the latest version, it will not be possible to downgrade to a version prior to 3.3-IV0. However, you can downgrade internal versions, i.e. 3.3-IV1 to 3.3-IV0.

What to Expect in Future Kafka 3.x Releases

The 3.x releases of Kafka are exciting times, with a lot of community feedback being taken into consideration. This energy and enthusiasm will likely continue on through the rest of the 3.X releases as they continue to get better. One of the most anticipated changes in future will be a fully supported and production-ready implementation of KIP-866, which will allow teams to finally migrate off of ZK mode, putting ZooKeeper to rest once and for all.

Final Thoughts

For some, the latest evolution of Kafka will require some serious refactoring in clusters (Hello, KRaft mode!) on top of the usual security and bug fixes. Whether it makes sense to upgrade Kafka now or wait for KRaft to be marked ready for production will depend on your particular environment. So no need to panic about the end of ZooKeeper just yet if you're not ready for the changes KRaft will bring. 

Optimize Your Kafka Deployments 

OpenLogic provides 24/7/365 technical support for Apache Kafka, plus a full suite of professional services. Just click the button below to get started.

Explore Kafka Solutions  

Additional Resources

Joe Carder Headshot

Joe Carder

Enterprise Solutions Architect, OpenLogic by Perforce

Joe has been working in IT for the past 25 years, with 15 of those years specializing in web and application based enterprise solutions. He focuses currently on Apache Web Server and J2EE technologies.