Fix: Fabric8 Client Fails to Parse emulationMajor in Strimzi Kafka on GKE

Environment: GKE Kubernetes v1.33+ · Strimzi 0.45.0/0.41.0 · Kafka 3.8.x

The Problem

After upgrading GKE Kubernetes to v1.33+, the Strimzi Kafka Cluster Operator suddenly starts crashing. The operator pod enters CrashLoopBackOff, Kafka reconciliation halts completely, and all Kafka operations fail.

Check the operator logs and you'll see this:

com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException:
Unrecognized field "emulationMajor"
(class io.fabric8.kubernetes.client.VersionInfo),
not marked as ignorable
  at io.fabric8.kubernetes.client.utils.Serialization...

Why This Happens

GKE v1.33 introduced a new field — emulationMajor — in the /version API response. This field is part of GKE's version emulation feature, which allows nodes to report a lower Kubernetes version for backward compatibility with older workloads.

The problem: the Fabric8 Kubernetes client bundled inside Strimzi 0.45.0 doesn't know about this field. When Strimzi starts up, it calls the Kubernetes version API to detect the cluster version. Fabric8 tries to deserialize the response into its internal VersionInfo POJO — and fails hard because emulationMajor is not a mapped field and strict deserialization is enabled.

The operator crashes before it can do any reconciliation work.

Impact: All Kafka clusters managed by Strimzi stop reconciling. Topic creation, partition rebalancing, and broker restarts are blocked until the operator is back online.

The Fix

Manually override the Kubernetes version detection inside the Strimzi Cluster Operator deployment using a single environment variable.

Setting STRIMZI_KUBERNETES_VERSION tells Strimzi to skip calling the Kubernetes version API entirely and use the value you provide directly. This bypasses the Fabric8 deserialization path completely and eliminates the crash.

Safe to use in production. This is a supported workaround in the Strimzi project. Strimzi only uses the version value to gate certain Kubernetes API features — pinning it to a known-good value like 1.34 is stable until an official Fabric8 fix is released.

Step-by-Step Instructions

Step 1 — Edit the Strimzi Cluster Operator deployment

Open the deployment for editing:

kubectl edit deployment strimzi-cluster-operator -n kafka

Step 2 — Add the environment variable

Locate the strimzi-cluster-operator container spec and add the following env entry:

spec:
  template:
    spec:
      containers:
        - name: strimzi-cluster-operator
          env:
            # ... existing env vars ...
            - name: STRIMZI_KUBERNETES_VERSION
              value: "major=1,minor=34"

Note: The value major=1,minor=34 tells Strimzi it is running on Kubernetes 1.34. Adjust the minor version to match your actual GKE minor version if needed, but any valid value will bypass the failing API call.

Step 3 — Save and restart the operator

Save the file. If using kubectl edit, the rollout triggers automatically. Otherwise, restart manually:

kubectl rollout restart deployment strimzi-cluster-operator -n kafka

Watch the rollout complete:

kubectl rollout status deployment strimzi-cluster-operator -n kafka

Step 4 — Verify the operator is healthy

Confirm the operator pod is running and no longer crashing:

kubectl get pods -n kafka -l name=strimzi-cluster-operator

You should see:

NAME                                        READY   STATUS    RESTARTS   AGE
strimzi-cluster-operator-<hash>            1/1     Running   0          60s

Check the logs to confirm there are no more deserialization errors:

kubectl logs -n kafka deploy/strimzi-cluster-operator --tail=50

Step 5 — Restart your Kafka resources

Once the operator is healthy, restart all Kafka-related deployments so Strimzi can reconcile them:

# Trigger a rolling restart of all Kafka clusters via Strimzi annotation
kubectl annotate kafka --all strimzi.io/manual-rolling-update=true -n kafka

# Or restart individual StatefulSets directly if needed
kubectl rollout restart statefulset -n kafka

Within a few minutes, all Kafka brokers and ZooKeeper nodes (or KRaft controllers) should be back up and running.

Permanent Fix

This workaround should remain in place until either:

• Strimzi upgrades its Fabric8 dependency to a version that handles unknown fields gracefully (tracked in strimzi/strimzi-kafka-operator).
• GKE removes or gates the emulationMajor field behind an opt-in flag.

Monitor the Strimzi release notes for an official fix. When upgrading Strimzi, remove the STRIMZI_KUBERNETES_VERSION override and verify the operator starts cleanly without it before removing it from production.

Found this useful? If you hit any other issues, check the Strimzi GitHub discussions or the #strimzi channel on the CNCF Slack.