Spec and status

Learn CRD spec and status fields.

Spec and status

A well-designed custom resource follows the spec (what the user wants) and status (what the controller reports) split, like built-in types. When subresources.status is enabled in the CRD, the status is updated only through the /status subresource; the user's apply can't overwrite the status:

    - name: v1
      subresources:
        status: {}

# written by the controller
status:
  sonYedek: "2026-11-03T03:00:12Z"
  durum: Basarili
  conditions:
    - type: Ready
      status: "True"

The scale subresource

subresources.scale adds kubectl scale and HPA support to a custom resource; it says which fields represent the replica count:

      subresources:
        status: {}
        scale:
          specReplicasPath: .spec.kopya
          statusReplicasPath: .status.kopya

$ kubectl scale veritabani/ana --replicas=3

Exercise Add the subresources

Write a CRD version's subresources section (starting with subresources:): status: {}; under scale, specReplicasPath: .spec.kopya and statusReplicasPath: .status.kopya.

Show example solution

subresources:
  status: {}
  scale:
    specReplicasPath: .spec.kopya
    statusReplicasPath: .status.kopya

Test yourself

With the status subresource enabled, what happens when the spec changes?
- The object is recreated
- metadata.generation increases; it doesn't when the status changes
- Nothing
- The status is deleted
Show answer

metadata.generation increases; it doesn't when the status changes — The controller reports whether it's done by comparing generation with observedGeneration.

Enable the status subresource.

      subresources:
        ____: {}

Show answer

      subresources:
        status: {}

Match.

spec

The user writes
status

The controller writes
subresources.status

Separate update path
subresources.scale

kubectl scale support

Next lesson: Validation

We Are Enhancing Your Experience

Cookie Preferences

Strictly Necessary Cookies

Analytical Cookies