DEV Community

Indra Gusti Prasetya
Indra Gusti Prasetya

Posted on Originally published at indragustiprasetya.com

Fix "unrecognized format int32" in Kubernetes 1.34

#tutorial

After upgrading a cluster to Kubernetes 1.34.0, kubectl apply and helm install start printing Warning: unrecognized format "int32" (and int64, float, double) against CRDs that were valid the day before. Your CRDs are fine. This guide shows how to prove the warning is a kube-apiserver regression, tell it apart from a real format typo, and either patch the control plane or filter the noise cleanly until you can.

Overview

Short version: the warning is a server-side regression in kube-apiserver 1.34.0 that wrongly applied a new unknown-format check to integer and number properties. It was fixed in PR #133896, cherry-picked to the 1.34 patch line on 2025-09-05, and it ships clean in 1.35.0. The fix is a control-plane upgrade, not a kubectl or CRD change.

This is for platform and cluster operators who suddenly see a wall of format warnings from kube-prometheus-stack, cert-manager, Cilium, or their own operators, and have to decide whether to act. The symptom is all over the issue trackers, and almost every thread misattributes the cause: people get told to edit their CRD schemas or downgrade kubectl. Both are wrong. The warning is emitted by the API server, not the client, and the schemas were correct all along. Below is the one command that proves where the warning originates, so you can separate this false positive from a genuine format typo. If you are mid-rollout, file it next to the other 1.34/1.35 surprises like user namespaces going GA, and treat it the same way: it is a new server version changing behavior underneath stable tooling, the same shape of break as Cosign v3 breaking image verification in Harbor.

Prerequisites

  • A cluster running Kubernetes 1.34.0 (control plane). Check with kubectl version.
  • kubectl v1.28+ with server-side field validation (the default since 1.27).
  • Cluster-admin or the ability to apply a CRD in a scratch namespace.
  • If you run EKS, GKE, or AKS, note your provider's control-plane patch version. You likely cannot bump it yourself, which changes your options (see pitfalls).

Step-by-step

1. Reproduce the warning with a minimal CRD

Apply a CRD that declares an integer property with format: int32, the exact shape kube-prometheus-stack and cert-manager ship:

# int32-crd.yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: widgets.example.com
spec:
  group: example.com
  scope: Namespaced
  names:
    plural: widgets
    singular: widget
    kind: Widget
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                replicas:
                  type: integer
                  format: int32
Enter fullscreen mode Exit fullscreen mode 
kubectl apply -f int32-crd.yaml
Enter fullscreen mode Exit fullscreen mode

On 1.34.0 you get:

Warning: unrecognized format "int32"
customresourcedefinition.apiextensions.k8s.io/widgets.example.com created
Enter fullscreen mode Exit fullscreen mode

The resource is still created. The warning is non-blocking, but in a real chart it repeats dozens of times and buries anything that actually matters.

2. Confirm the warning is server-side, not from kubectl

This is the step everyone skips. Add -v=8 and watch for a Warning response header from the API server:

kubectl apply -f int32-crd.yaml -v=8 2>&1 | grep -i warning
Enter fullscreen mode Exit fullscreen mode

You'll see the warning arrive as an HTTP response header:

Response Headers:
    Warning: 299 - "unrecognized format \"int32\""
Enter fullscreen mode Exit fullscreen mode

A 299 warning header is generated by kube-apiserver, not printed locally by kubectl. That single line tells you upgrading or downgrading the CLI will do nothing, because the behavior lives in the control plane. This matches the 1.35 release note, which files the fix under "Kube-apiserver."

3. Confirm it's a false positive, not a real typo

The check itself is legitimate: it exists to catch format typos like format: itn32. The bug is that 1.34.0 applied it to non-string types. Per the CRD documentation, int32, int64, float, and double are documented, supported formats, so a warning on any of those four attached to a type: integer or type: number field is the regression, not a mistake. Issue #133880 is the upstream confirmation.

A rule of thumb you can apply while scanning output:

  • Warning on int32/int64/float/double under type: integer/number is a false positive, ignore it.
  • Warning on a type: string field with a genuinely unknown format (format: emial) is real, fix your schema.

4. Apply the real fix: patch the control plane

The fix (PR #133896) restricts the unknown-format warning to type: string properties, so integer and number formats stop warning. It merged to master under the v1.35 milestone and was cherry-picked to release-1.34 (PR #133901, merged 2025-09-05).

On a self-managed cluster, upgrade the control plane to a 1.34 patch that includes the cherry-pick, or to 1.35.0+:

# self-managed / kubeadm example, upgrade the control-plane node
kubeadm upgrade plan
kubeadm upgrade apply v1.35.0
Enter fullscreen mode Exit fullscreen mode

Verify the served version moved:

kubectl version -o json | jq -r '.serverVersion.gitVersion'
Enter fullscreen mode Exit fullscreen mode

5. If you can't upgrade yet, filter, don't rewrite

On a managed cluster you are stuck on the provider's control-plane version until they roll the patch. Do not edit vendored CRDs to drop format: int32; you will silently weaken validation and create drift you have to unwind later. Filter the noise at the point of apply so real warnings still surface:

# keep every line EXCEPT the four known false positives
helm upgrade --install monitoring prometheus-community/kube-prometheus-stack \
  2> >(grep -vE 'unrecognized format "(int32|int64|float|double)"' >&2)
Enter fullscreen mode Exit fullscreen mode

This suppresses only the four documented-format false positives and lets a genuine type: string typo through untouched.

Verify it works

Re-apply the same CRD after the control plane is patched:

kubectl apply -f int32-crd.yaml -v=8 2>&1 | grep -i 'unrecognized format' || echo "clean"
Enter fullscreen mode Exit fullscreen mode

Expected output on a fixed control plane:

clean
Enter fullscreen mode Exit fullscreen mode

No 299 header, no terminal warning. If you still see it, your serverVersion from step 4 has not actually moved, and the client version is irrelevant here.

Where the warning comes from 

flowchart TD
    A["kubectl apply -f crd.yaml"] --> B["kube-apiserver\nvalidates CRD OpenAPI schema"]
    B --> C{"format on a\nstring property?"}
    C -->|"string, unknown format\n(real typo)"| D["Warning: 299\nunrecognized format"]
    C -->|"integer/number in 1.34.0\n(the regression)"| D
    C -->|"integer/number on\npatched apiserver"| E["no warning"]
    D --> F["kubectl prints the\nserver Warning header"]
Enter fullscreen mode Exit fullscreen mode

Common pitfalls

  • "Just update kubectl." The warning is a server response header (step 2). A newer or older CLI changes nothing. This is the single most common wrong answer in the wild.
  • Editing the operator's CRDs to remove format: int32. You are patching a false positive by degrading real schema validation, and your change gets clobbered on the next chart upgrade. Filter at apply time instead (step 5).
  • Assuming every warning in the batch is the same bug. On 1.34, kube-prometheus-stack installs also emit Warning: spec.SessionAffinity is ignored for headless services (issue #6108). That one is unrelated to formats: it flags a sessionAffinity set on a clusterIP: None Service and is a real, if harmless, config smell. Only the four numeric-format warnings are the regression.
  • CI gates that fail on any stderr. If your pipeline treats warning output as failure, a control-plane bump you don't control (managed cluster auto-patch) can flip a job red or green with no change on your side. Pin the filter from step 5 into the pipeline until you are on a fixed control plane, then remove it.
  • Chasing it as a Cilium or cert-manager bug. Both projects got issues filed against them (Cilium #41826) for warnings that were never theirs to fix. If the format is one of the four numeric ones, close it and point at the apiserver.

FAQ

Is Warning: unrecognized format "int32" breaking my CRD install?
No. It's a non-blocking warning; the CRD is still created and validated normally. The only cost is noise.

Which Kubernetes version fixes it?
kube-apiserver 1.35.0 ships the fix, and it was cherry-picked to the 1.34 patch line (PR #133896 / #133901, merged 2025-09-05). Upgrade the control plane, not kubectl.

Do I need to change my CRD YAML?
No. int32, int64, float, and double are documented, supported formats. Removing them only weakens validation.

I'm on EKS/GKE/AKS and can't pick the patch, what do I do?
Filter the four false-positive strings at apply time (step 5) and wait for your provider to roll a fixed 1.34 patch. Confirm with kubectl version -o json.

How do I tell this apart from a real format typo?
Real typos warn on type: string fields with an unknown format. The regression warns on type: integer/number fields using one of the four numeric formats. Check the field's type.

Wrap-up

Warning: unrecognized format "int32" on Kubernetes 1.34 is a kube-apiserver false positive. Prove it's server-side with -v=8, separate it from a genuine format typo and from the unrelated SessionAffinity warning, then either patch the control plane to a fixed 1.34 point release (or 1.35.0+) or filter the four numeric formats until you can. Fold it into your 1.34/1.35 upgrade checklist alongside other version-pinned gotchas, including the Ingress-NGINX to Gateway API migration, where the same trap bites: the docs still describe the pre-change behavior. The discipline that saves you on all of them is the same, check the served version, not the client.

Sources

Originally published at indragustiprasetya.com

Top comments (0)