Demo Status Scale Printer Columns Short Names

Previously we had a working WebApp custom resource: CRD, schema, validation, and a controller. Functionally it worked, but it didn’t behave like a first-class Kubernetes resource:

kubectl get wa showed only NAME and AGE.
kubectl scale wa failed.
A regular kubectl apply could overwrite .status because the API server wasn’t preventing writes to it.

Below is the minimal CRD we started from:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: webapps.webapp.kodekloud.com
spec:
  group: webapp.kodekloud.com
  scope: Namespaced
  names:
    plural: webapps
    singular: webapp
    kind: WebApp
    listKind: WebAppList
    shortNames: [wa]
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object

In this guide we add four CRD fields that make your WebApp resource behave like a built-in workload:

Enable the status subresource so only the /status endpoint (typically controllers) can update .status.
Enable the scale subresource so kubectl scale and HPAs can target the CR.
Add additionalPrinterColumns so kubectl get wa shows meaningful columns.
Add categories: [all] so tools that honor categories treat your CR as a top-level workload.

No controller code changes or rebuilds are required — the API server enforces these behaviors based purely on the CRD.

Quick overview: What each CRD field does

CRD Field	Purpose	Effect
`schema` includes `status`	Prevents server-side pruning of `.status`	Controllers can write status; ordinary writes will not persist status fields
`subresources.status`	Exposes `/status` endpoint	Only `/status` updates `.status` (prevents accidental writes via `apply`)
`subresources.scale`	Exposes `/scale` endpoint	`kubectl scale` and HPAs can update `.spec.replicas` and read `.status.readyReplicas`
`additionalPrinterColumns`	Customize `kubectl get` output	Shows meaningful columns like Image, Replicas, Ready, Port, Age
`names.categories`	Categorize the CR	Tools (and `kubectl api-resources --categories=all`) include it in tooling groups

Step 1 — Teach the schema about `.status` and tighten `.spec` validation

Add a status object to the OpenAPI schema so the API server does not prune it. Also make spec validation explicit (required fields, types and ranges):

# fragment: spec.versions[0].schema.openAPIV3Schema
type: object
properties:
  spec:
    type: object
    required: [image, replicas]
    properties:
      image:
        type: string
      replicas:
        type: integer
        minimum: 1
        maximum: 10
      port:
        type: integer
        default: 8080
  status:
    type: object
    properties:
      readyReplicas:
        type: integer
      labelSelector:
        type: string

This schema change ensures:

The API server preserves .status (it won’t be removed by pruning).
Clients get clear validation errors for missing or invalid spec fields.

Step 2 — Enable `/status` and add the `scale` subresource

Turn on the /status endpoint by adding an empty status: {} under subresources. Add the scale block and point it to the JSONPaths for desired and observed replicas and for the label selector:

# fragment: spec.versions[0].subresources
subresources:
  status: {}
  scale:
    specReplicasPath: .spec.replicas
    statusReplicasPath: .status.readyReplicas
    labelSelectorPath: .status.labelSelector

With this in place:

kubectl scale wa <name> --replicas=<n> is routed to the scale subresource and updates .spec.replicas.
HorizontalPodAutoscalers (HPAs) that target this resource can read replicas and update the scale endpoint.

Enabling the status subresource prevents ordinary apply/update requests from modifying .status. Only the /status endpoint (used by controllers) may change status fields.

Step 3 — Add additional printer columns for `kubectl get`

Define columns so kubectl get wa displays useful information. Each column needs name, type, and a jsonPath. Use priority: 1 to hide less important columns unless -o wide is requested:

# fragment: spec.versions[0].additionalPrinterColumns
additionalPrinterColumns:
  - name: Image
    type: string
    jsonPath: .spec.image
    priority: 1
  - name: Replicas
    type: integer
    jsonPath: .spec.replicas
  - name: Ready
    type: integer
    jsonPath: .status.readyReplicas
  - name: Port
    type: integer
    jsonPath: .spec.port
  - name: Age
    type: date
    jsonPath: .metadata.creationTimestamp

These columns make kubectl get wa feel like a native resource listing (Image, Replicas, Ready, Port, Age).

Step 4 — Add `categories: [all]`

Add categories: [all] under spec.names so tools that respect categories (and kubectl api-resources --categories=all) include the resource among top-level workload types:

# fragment: spec.names
names:
  plural: webapps
  singular: webapp
  kind: WebApp
  listKind: WebAppList
  shortNames: [wa]
  categories: [all]

Note: kubectl get all is a hard-coded convenience command and will not list CRDs even if they declare categories: [all]. The category is still useful for other tooling and kubectl api-resources --categories=all.

kubectl get all will not list your CRs even if categories: [all] is set. Use kubectl api-resources --categories=all or kubectl get webapps / kubectl get wa to view your resources.

Final consolidated CRD (relevant fragments)

Below is a consolidated view showing the key fields you should include. Fill in the remaining CRD metadata as appropriate for your project.

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: webapps.webapp.kodekloud.com
spec:
  group: webapp.kodekloud.com
  scope: Namespaced
  names:
    plural: webapps
    singular: webapp
    kind: WebApp
    listKind: WebAppList
    shortNames: [wa]
    categories: [all]
  versions:
    - name: v1
      served: true
      storage: true
      subresources:
        status: {}
        scale:
          specReplicasPath: .spec.replicas
          statusReplicasPath: .status.readyReplicas
          labelSelectorPath: .status.labelSelector
      additionalPrinterColumns:
        - name: Image
          type: string
          jsonPath: .spec.image
          priority: 1
        - name: Replicas
          type: integer
          jsonPath: .spec.replicas
        - name: Ready
          type: integer
          jsonPath: .status.readyReplicas
        - name: Port
          type: integer
          jsonPath: .spec.port
        - name: Age
          type: date
          jsonPath: .metadata.creationTimestamp
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              required: [image, replicas]
              properties:
                image:
                  type: string
                replicas:
                  type: integer
                  minimum: 1
                  maximum: 10
                port:
                  type: integer
                  default: 8080
            status:
              type: object
              properties:
                readyReplicas:
                  type: integer
                labelSelector:
                  type: string

Apply the CRD

No API server restart is required — changes to CRDs are picked up immediately.

$ kubectl apply -f webapp-crd.yaml
customresourcedefinition.apiextensions.k8s.io/webapps.webapp.kodekloud.com configured

After applying:

kubectl get wa will show the extra columns you defined. (The Image column may be hidden unless you use -o wide because it has priority: 1.)
kubectl scale wa <name> --replicas=<n> updates .spec.replicas via the scale subresource.
Regular kubectl apply / kubectl update attempts that include .status will see .status fields dropped — only /status updates persist status.

Validate category registration

$ kubectl api-resources --categories=all | grep -E 'NAME|webapp'
NAME       SHORTNAMES   APIVERSION                 NAMESPACED   KIND
webapps    wa           webapp.kodekloud.com/v1    true         WebApp

Summary

By adding these CRD fields:

schema for status and spec validation
subresources.status
subresources.scale
additionalPrinterColumns
names.categories: [all]

you make your custom resource behave like a first-class Kubernetes workload. All of the enforcement is handled by the API server from the CRD itself — you do not need to change or rebuild the controller. References:

Kubebuilder can generate these CRD fields automatically from Go marker comments on your types.

Introduction to Operator Fundamentals

Custom Resource Definitions Deep Dive

Kubebuilder Scaffolding

Building The WebApp Operator Core Reconcile

Running Testing Debugging Locally

Status Conditions Events

Finalizers And Cleanup

Validation Webhooks And CEL Policies

Packaging And Distribution

Alternative Approaches Operator SDK Helm Operator

Consuming Popular Operators

Production Readiness Testing Wrap Up

Demo Status Scale Printer Columns Short Names

Quick overview: What each CRD field does

Step 1 — Teach the schema about `.status` and tighten `.spec` validation

Step 2 — Enable `/status` and add the `scale` subresource

Step 3 — Add additional printer columns for `kubectl get`

Step 4 — Add `categories: [all]`

Final consolidated CRD (relevant fragments)

Apply the CRD

Validate category registration

Summary

Watch Video

Practice Lab

​Quick overview: What each CRD field does

​Step 1 — Teach the schema about .status and tighten .spec validation

​Step 2 — Enable /status and add the scale subresource

​Step 3 — Add additional printer columns for kubectl get

​Step 4 — Add categories: [all]

​Final consolidated CRD (relevant fragments)

​Apply the CRD

​Validate category registration

​Summary

Watch Video

Practice Lab

Quick overview: What each CRD field does

Step 1 — Teach the schema about `.status` and tighten `.spec` validation

Step 2 — Enable `/status` and add the `scale` subresource

Step 3 — Add additional printer columns for `kubectl get`

Step 4 — Add `categories: [all]`

Final consolidated CRD (relevant fragments)

Apply the CRD

Validate category registration

Summary