Application CRDs In contrast, these are used to represent an application-specific domain concept. This kind of CRD allows applications deep integration with Kubernetes, which involves combining Kubernetes with an application-specific domain behavior. For example, the ServiceMonitor CRD is used by the Prometheus operator to register specific Kubernetes Services for being scraped by a Prometheus server. The Prometheus operator takes care of adapting the Prometheus’ server configu‐ ration accordingly. Note that an  Operator  can act on different kinds of CRDs as the Prometheus operator does in this case. The boundary between these two categories of CRDs is blurry. In our categorization of  Controller  and  Operator , an  Operator  is-a  Controller  that uses CRDs. 1  However, even this distinction is a bit fuzzy as there are variations in between. One example is a controller, which uses a ConfigMap as a kind of replacement for a CRD. This approach makes sense in scenarios where default Kubernetes resources are not enough, but creating CRDs is not feasible either. In this case, ConfigMap is an excellent middle ground, allowing encapsulation of domain logic within the content of a ConfigMap. An advantage of using a plain ConfigMap is that you don’t need to have the cluster-admin rights you need when registering a CRD. In certain cluster setups, it is just not possible for you to register such a CRD (e.g., like when running on public clusters like OpenShift Online). However, you can still use the concept of  Observe-Analyze-Act  when you replace a CRD with a plain ConfigMap that you use as your domain-specific configuration. The drawback is that you don’t get essential tool support like  kubectl get  for CRDs; you have no validation on the API Server level, and no support for API versioning. Also, you don’t have much influence on how you model the  status:  field of a Con‐ figMap, whereas for a CRD you are free to define your status model as you wish. Another advantage of CRDs is that you have a fine-grained permission model based on the kind of CRD, which you can tune individually. This kind of RBAC security is not possible when all your domain configuration is encapsulated in ConfigMaps, as all ConfigMaps in a namespace share the same permission setup. From an implementation point of view, it matters whether we implement a controller by restricting its usage to vanilla Kubernetes objects or whether we have custom 1 is-a emphasizes the inheritance relationship between  Operator  and  Controller , that an  Operator  has all charac‐ teristics of a  Controller  plus a bit more Solution  |  193