CCAAK: Deploy Apache Kafka Clusters

Domain 2, Deploy Apache Kafka clusters, tests capacity planning, metadata-mode selection, listener configuration and the mechanics of rolling deployment and expansion. The exam expects exact commands and ordering, not general installation advice.

Sizing and host layout

• Kafka relies on the OS page cache, so heap is usually modest (roughly 6–8 GB) and the remainder of RAM is left for caching. Very large heaps hurt GC pause times.
• Plan for disk throughput, not just capacity: replication multiplies writes by the replication factor, and consumers add read load.
• Use dedicated log.dirs volumes; JBOD gives capacity and parallelism, RAID gives simpler replacement but different failure semantics. Network-attached storage adds latency that shows up as fetch and produce delays.

KRaft versus ZooKeeper

• KRaft requires process.roles, node.id, controller.quorum.voters and controller.listener.names. Storage is formatted once with kafka-storage.sh random-uuid and kafka-storage.sh format -t <uuid> -c server.properties; every node must use the same cluster ID.
• Production clusters use dedicated controllers in an odd number (3 or 5); combined broker/controller mode is for development or small environments.
• ZooKeeper mode uses zookeeper.connect, optionally with a chroot path.

Listeners and advertised addresses

• listeners defines bound interfaces; advertised.listeners defines what clients and brokers are told to connect to. Advertised addresses must be resolvable and reachable by every client that will connect.
• Keep an inter-broker listener separate from client listeners where security policies differ, and a distinct controller listener in KRaft.
• listener.security.protocol.map must map every listener name to a protocol that matches its security configuration.

Rolling deployment and expansion

• Restart one broker at a time and wait until UnderReplicatedPartitions returns to zero before continuing.
• To add brokers, start them with unique broker.id/node.id values, then generate a reassignment plan with kafka-reassign-partitions.sh --generate, execute it with --execute --throttle, and verify with --verify.

Worked example

A six-broker cluster must grow to eight. Each new node gets a unique node ID and matching advertised.listeners. A reassignment JSON is generated for selected topics, executed with a 50 MB/s throttle to protect client traffic, then verified. Leadership is balanced afterwards with a preferred-leader election.

Traps

• Leaving advertised.listeners at localhost, which works on the host but fails for remote clients.
• Duplicate broker.id/node.id values, causing a broker to be rejected or to replace another.
• Reformatting storage on a node that already holds log data.
• Using an even number of controllers, which weakens quorum fault tolerance.