Helm charts for Kafka - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of Helm install command with default Kafka chart values?

You run the command helm install my-kafka bitnami/kafka with default values. What will be the status of the Kafka pods immediately after installation?

A Kafka pods will be in <strong>Pending</strong> state indefinitely due to missing PVCs.

B Kafka pods will be in <strong>Running</strong> state after a few seconds.

C Kafka pods will fail to start with <strong>CrashLoopBackOff</strong> error.

D Kafka pods will be <strong>Completed</strong> and exit immediately.

💡 Hint

Default Bitnami Kafka Helm chart provisions persistent storage and readiness probes.

The default Bitnami Kafka Helm chart provisions persistent volumes and readiness probes, so pods start and reach Running state after initialization.

🧠 Conceptual

intermediate

Which Helm value controls the number of Kafka broker replicas?

In the Kafka Helm chart, which value key sets how many Kafka broker pods will be created?

A replicaCount

B brokers.count

C kafka.brokerReplicas

D broker.replicas

💡 Hint

Look for the common Helm pattern for replica count.

The standard Helm chart pattern uses replicaCount to specify the number of pods for the main component, including Kafka brokers.

🔧 Debug

advanced

Why does Kafka pod fail with 'CrashLoopBackOff' after Helm install?

You installed Kafka using Helm with a custom values file that disables persistence (persistence.enabled=false). The Kafka pod fails with CrashLoopBackOff. What is the most likely cause?

A The Helm chart does not support disabling persistence; it causes syntax errors.

B The Kafka image version is incompatible with Kubernetes version.

C Kafka requires persistent storage; disabling persistence causes startup failure.

D Kafka broker count is zero, so no pods are created.

💡 Hint

Think about Kafka's need for data storage and state.

Kafka brokers need persistent storage for logs and data. Disabling persistence means no storage is available, causing the broker to crash.

📝 Syntax

advanced

Identify the correct Helm values YAML snippet to enable Kafka TLS encryption

Which YAML snippet correctly enables TLS encryption for Kafka brokers in the Helm values file?

A

tls:
  enabled: true
  autoGenerate: true

B

tls:
  enabled: yes
  autoGenerated: true

C

tls:
  enable: true
  autoGenerated: true

D

tls:
  enabled: true
  autoGenerated: true

💡 Hint

Check the exact key names and boolean values.

The Bitnami Kafka Helm chart uses tls.enabled and tls.autoGenerated keys with boolean true/false values.

🚀 Application

expert

How to upgrade Kafka Helm chart to add a new broker without downtime?

You have a Kafka cluster deployed with 3 brokers using Helm. You want to upgrade the cluster to 4 brokers without downtime. Which approach is correct?

A Update <code>replicaCount</code> to 4 in values and run <code>helm upgrade</code>. Kafka will add the broker gracefully.

B Delete the Kafka release and reinstall with 4 brokers to avoid conflicts.

C Scale the StatefulSet manually to 4 replicas, then update Helm values to match.

D Change <code>replicaCount</code> to 4 and run <code>helm upgrade --force</code> to recreate pods.

💡 Hint

Think about Helm upgrade behavior and Kafka broker scaling.

Updating replicaCount and running helm upgrade will add a new broker pod gracefully without downtime. Deleting or forcing pod recreation causes downtime.

Practice

1. What is the main purpose of using Helm charts for Kafka deployment on Kubernetes?

easy

A. To automate and simplify Kafka deployment and management

B. To write Kafka application code

C. To monitor Kafka topics manually

D. To replace Kafka brokers with databases

Solution

1. Step 1: Understand Helm charts role

   Helm charts package Kubernetes resources to automate deployment and management.

2. Step 2: Apply to Kafka context

   Using Helm charts for Kafka automates its deployment and configuration on Kubernetes clusters.

3. Final Answer:

   To automate and simplify Kafka deployment and management -> Option A

4. Quick Check:

   Helm automates Kafka deployment = B [OK]

Hint: Helm automates deployment tasks for Kafka on Kubernetes [OK]

Common Mistakes:

• Confusing Helm with Kafka application coding
• Thinking Helm replaces Kafka brokers
• Assuming Helm is for manual monitoring

2. Which Helm command syntax correctly sets the Kafka broker count to 3 during installation?

easy

A. helm install kafka bitnami/kafka --set brokerCount=3

B. helm install kafka bitnami/kafka --set brokers=3

C. helm install kafka bitnami/kafka --set replicaCount=3

D. helm install kafka bitnami/kafka --set kafka.broker=3

Solution

1. Step 1: Identify correct Helm parameter for replicas

   Common Helm charts use replicaCount to set number of pods/brokers.

2. Step 2: Match parameter with Kafka Helm chart

   Bitnami Kafka chart uses replicaCount to define broker count.

3. Final Answer:

   helm install kafka bitnami/kafka --set replicaCount=3 -> Option C

4. Quick Check:

   replicaCount sets broker pods = A [OK]

Hint: Use replicaCount to set broker number in Helm [OK]

Common Mistakes:

• Using incorrect parameter names like brokers or brokerCount
• Misplacing dot notation in --set
• Confusing Helm install syntax

3. Given this Helm command:

helm install kafka bitnami/kafka --set replicaCount=2,logRetentionHours=168

What will be the effect on the Kafka deployment?

medium

A. Deploy 2 Kafka brokers with logs retained for 168 hours

B. Deploy 168 Kafka brokers with 2 hours log retention

C. Deploy 2 Kafka brokers with default log retention

D. Deployment will fail due to syntax error

Solution

1. Step 1: Analyze replicaCount setting

   replicaCount=2 means 2 Kafka broker pods will be deployed.

2. Step 2: Analyze logRetentionHours setting

   logRetentionHours=168 sets log retention to 168 hours (7 days).

3. Final Answer:

   Deploy 2 Kafka brokers with logs retained for 168 hours -> Option A

4. Quick Check:

   replicaCount=2 and logRetentionHours=168 = D [OK]

Hint: Check each --set key=value carefully for effect [OK]

Common Mistakes:

• Mixing up values of replicaCount and logRetentionHours
• Assuming syntax error due to comma
• Ignoring log retention setting

4. You run this Helm upgrade command:

helm upgrade kafka bitnami/kafka --set replicaCount=3

But the Kafka deployment still has 2 brokers. What is the likely issue?

medium

A. The Helm chart version is incompatible

B. The Helm release name is incorrect

C. Kafka does not support scaling brokers via Helm

D. The replicaCount value was not applied due to missing --reuse-values flag

Solution

1. Step 1: Understand Helm upgrade behavior

   Helm upgrade requires --reuse-values to reuse previous values while applying new --set overrides.

2. Step 2: Identify why replicaCount didn't change

   Without --reuse-values, the new value may not apply correctly in combination with prior settings.

3. Final Answer:

   The replicaCount value was not applied due to missing --reuse-values flag -> Option D

4. Quick Check:

   Missing --reuse-values can block value changes = A [OK]

Hint: Use --reuse-values to keep and update Helm settings on upgrade [OK]

Common Mistakes:

• Assuming Helm release name is wrong
• Believing Kafka can't scale brokers
• Ignoring Helm chart version compatibility

5. You want to deploy Kafka with 3 brokers and customize the storage size to 50Gi using Helm. Which command correctly achieves this?

hard

A. helm install kafka bitnami/kafka --set replicaCount=3,storage.size=50Gi

B. helm install kafka bitnami/kafka --set replicaCount=3 --set persistence.size=50Gi

C. helm install kafka bitnami/kafka --set brokers=3 --set storage.size=50Gi

D. helm install kafka bitnami/kafka --set replicaCount=3 --set persistence.storage=50Gi

Solution

1. Step 1: Set broker count correctly

   replicaCount=3 sets 3 Kafka brokers.

2. Step 2: Set storage size correctly

   Bitnami Kafka chart uses persistence.size to define storage size per broker.

3. Step 3: Use correct Helm syntax

   Separate --set flags or comma-separated values are valid, but helm install kafka bitnami/kafka --set replicaCount=3 --set persistence.size=50Gi uses clear separate flags.

4. Final Answer:

   helm install kafka bitnami/kafka --set replicaCount=3 --set persistence.size=50Gi -> Option B

5. Quick Check:

   replicaCount and persistence.size set correctly = C [OK]

Hint: Use replicaCount and persistence.size keys for brokers and storage [OK]

Common Mistakes:

• Using wrong keys like brokers or storage.size
• Combining keys incorrectly in one --set
• Using persistence.storage instead of persistence.size