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"

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