statusReplicasPath : .status.replicas  labelSelectorPath : .status.labelSelector  JSON path to the number of declared replicas JSON path to the number of active replicas JSON path to a label selector to query for the number of active replicas Once we define a CRD, we can easily create such a resource, as shown in Example 23-3. The  metadata:  section has the same format and validation rules as any other Kuber‐ netes resource. The  spec:  contains the CRD-specific content, and Kubernetes vali‐ dates against the given validation rule from the CRD. Custom resources alone are not of much use without an active component to act on them. To give them some meaning, we need again our well-known  Controller , which watches the lifecycle of these resources and acts according to the declarations found within the resources. Before we dive into writing our  Operator , let’s look at a few kinds of classifications for Controllers ,  Operators , and especially CRDs. Based on the  Operator ’s action, broadly the classifications are as follows: Meant for installing and operating applications on the Kubernetes platform. Typ‐ ical examples are the Prometheus CRDs, which we can use for installing and managing Prometheus itself. 192  |  Chapter 23: Operator Installation CRDs Controller and Operator Classification Example 23-3. A Prometheus custom resource apiVersion : monitoring.coreos.com/v1 kind : Prometheus metadata : name : prometheus spec : serviceMonitorSelector : matchLabels : team : frontend resources : requests : memory : 400Mi