Lab Solution Apply A Cr And Explore

This lesson is short and focused: applying a Custom Resource (CR) is the simpler half of the operator pattern, but it’s useful to understand how the API server exposes and validates CRs and how to inspect them with kubectl. Below I walk through the typical steps to apply a Widget CR and explore it using various kubectl commands.

Setup

The lab platform pre-applied the Widget Custom Resource Definition (CRD) from the previous lesson and provided a starter YAML file in your lab folder.
The CRD enforces:
- a color pattern (six-digit hex),
- a size enum,
- and exposes additional printer columns and a short name for convenience.
The starter YAML includes a placeholder color of "#000000" — replace that with any valid 6-digit hex color (keep the quotes so YAML treats # as a literal, not a comment).

Open the starter file in your editor and update the color value. Example starter resource (edit the color as needed):

apiVersion: training.kodekloud.com/v1
kind: Widget
metadata:
  name: my-widget
  namespace: widget-demo
spec:
  size: medium
  # Replace the color below with any valid 6-digit hex color (keep the quotes).
  color: "#4287f5"
  replicas: 3

Always quote a hex color in YAML (for example: "#4287f5"). Without quotes, # begins a comment and the value will be parsed incorrectly.

Apply the CR:

kubectl apply -f ~/labs/widget-explore.yaml

Expected apply output:

widget.training.kodekloud.com/my-widget created

That confirmation indicates the CRD schema validated your fields (the color matched the pattern and size: medium is in the enum). Below are common ways to inspect a CR with kubectl. Each method serves different uses: quick overviews, scripting, full object inspection, or troubleshooting.

Method	Command	Purpose / Example output
Table view with printer columns	`kubectl -n widget-demo get widgets`	Quick, human-readable table. Example: `NAME SIZE COLOR` `my-widget medium #4287f5`
Short name	`kubectl -n widget-demo get wg`	Uses the CRD short name (`wg`) for fewer keystrokes. Output is the same table as above.
Full object (YAML)	`kubectl -n widget-demo get widget my-widget -o yaml`	Inspect the complete resource including metadata populated by the API server.
jsonpath (single field)	`kubectl -n widget-demo get widget my-widget -o jsonpath='{.spec.color}' && echo`	Machine-friendly single-field extraction; good for scripts. Example output: `#4287f5`
describe	`kubectl -n widget-demo describe widget my-widget`	Human-readable breakdown with an Events section for troubleshooting. Useful when a controller later adds events.

1) kubectl get (table view with additional printer columns)

The CRD added Additional Printer Columns for size and color, so kubectl get shows those fields directly:

kubectl -n widget-demo get widgets

Example output:

NAME        SIZE   COLOR
my-widget   medium #4287f5

These columns make custom resources feel like first-class Kubernetes types by surfacing key fields without inspecting the full YAML.

2) Short name (fewer keystrokes)

The CRD defined a short name wg, so you can use it instead of the full plural:

kubectl -n widget-demo get wg

Output (identical to the previous):

NAME        SIZE   COLOR
my-widget   medium #4287f5

Short names are configured in the CRD’s spec.names.shortNames and are convenient for interactive work and scripts.

3) Full object (YAML)

To inspect the full object, including server-populated metadata:

kubectl -n widget-demo get widget my-widget -o yaml

Example (abridged to relevant parts):

apiVersion: training.kodekloud.com/v1
kind: Widget
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"training.kodekloud.com/v1","kind":"Widget","metadata":{"annotations":{},"name":"my-widget","namespace":"widget-demo"},"spec":{"color":"#4287f5","replicas":3,"size":"medium"}}
  creationTimestamp: "2026-05-27T14:03:21Z"
  generation: 1
  name: my-widget
  namespace: widget-demo
  resourceVersion: "241462"
  uid: bde801f3-ff1b-4a54-9e80-cde78f04676e
spec:
  color: '#4287f5'
  replicas: 3
  size: medium

Note the API server populated standard metadata fields (creationTimestamp, uid, resourceVersion, generation). Because this lab is CR-only (no controller installed), there is no status block yet — that will appear when a controller reconciles the CR and updates status.

4) jsonpath (machine-friendly single-field extraction)

For scripts or one-liners, jsonpath extracts a single field cleanly. Example — get only the color:

kubectl -n widget-demo get widget my-widget -o jsonpath='{.spec.color}' && echo

Output:

#4287f5

This pattern is useful in shell scripts where you need a single value with no extra parsing.

5) describe (human-readable breakdown and events)

kubectl describe provides a friendly field-by-field summary and an Events section at the bottom:

kubectl -n widget-demo describe widget my-widget

Example output (abridged):

Name:         my-widget
Namespace:    widget-demo
Labels:       <none>
Annotations:  <none>
API Version:  training.kodekloud.com/v1
Kind:         Widget
Metadata:
  Creation Timestamp:  2026-05-27T14:03:21Z
  Generation:          1
  Resource Version:    241462
  UID:                 bde801f3-ff1b-4a54-9e80-cde78f04676e
Spec:
  Color:      #4287f5
  Replicas:   3
  Size:       medium
Events:      <none>

When you later implement the controller that reconciles Widget resources, events from each reconcile or error will appear here — making describe the first place to look when something goes wrong.

Extra: kubectl explain (auto-generated documentation)

kubectl explain reads the CRD’s OpenAPI v3 schema and displays field descriptions you included in the CRD. This effectively becomes auto-generated documentation for your CR API. Examples:

kubectl explain widget.spec
kubectl explain widget.spec.color

Sample output for widget.spec.color:

GROUP: training.kodekloud.com
KIND: Widget
VERSION: v1
FIELD: color <string>
DESCRIPTION:
<empty>

If you add description fields to your CRD schema, they will appear here. Including descriptions in the CRD is valuable because kubectl explain surfaces them to users and scripts.

This lab contains only the CRD and CR (no controller). The API server validates and stores the object, but no controller will reconcile it or populate status until you implement one.

Wrap-up

This walkthrough demonstrates the consumer side of the operator pattern:

The CRD defines the shape, validation, and documentation for the resource.
The API server treats custom resources like built-ins (populating metadata and enforcing schema).
kubectl provides familiar tooling (get with printer columns, short names, describe, jsonpath, explain) to interact with CRs.

Next step: implement a controller that watches and reconciles Widget resources to observe status updates and events.

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

Lab Solution Apply A Cr And Explore

Setup

Five ways to view the same Widget

1) kubectl get (table view with additional printer columns)

2) Short name (fewer keystrokes)

3) Full object (YAML)

4) jsonpath (machine-friendly single-field extraction)

5) describe (human-readable breakdown and events)

Extra: kubectl explain (auto-generated documentation)

Wrap-up

Links and References

Watch Video

​Setup

​Five ways to view the same Widget

​1) kubectl get (table view with additional printer columns)

​2) Short name (fewer keystrokes)

​3) Full object (YAML)

​4) jsonpath (machine-friendly single-field extraction)

​5) describe (human-readable breakdown and events)

​Extra: kubectl explain (auto-generated documentation)

​Wrap-up

​Links and References

Watch Video

Setup

Five ways to view the same Widget

1) kubectl get (table view with additional printer columns)

2) Short name (fewer keystrokes)

3) Full object (YAML)

4) jsonpath (machine-friendly single-field extraction)

5) describe (human-readable breakdown and events)

Extra: kubectl explain (auto-generated documentation)

Wrap-up

Links and References