content_image/845788.jpg
<img src='content_image/845788.jpg'>

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. 

apiVersion : monitoring.coreos.com/v1 kind : Prometheus metadata : name : prometheus spec : serviceMonitorSelector : matchLabels : team : frontend resources : requests : memory : 400Mi 

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. 

## Controller and Operator Classification 

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: 

Installation CRDs 

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. 

