Chapter 4. Using Custom Resources
In this chapter we introduce you to custom resources (CR), one of the central extension mechanisms used throughout the Kubernetes ecosystem.
Custom resources are used for small, in-house configuration objects without any corresponding controller logic—purely declaratively defined. But custom resources also play a central role for many serious development projects on top of Kubernetes that want to offer a Kubernetes-native API experience. Examples are service meshes such as Istio, Linkerd 2.0, and AWS App Mesh, all of which have custom resources at their heart.
Remember “A Motivational Example” from Chapter 1? At its core, it has a CR that looks like this:
apiVersion:cnat.programming-kubernetes.info/v1alpha1kind:Atmetadata:name:example-atspec:schedule:"2019-07-03T02:00:00Z"status:phase:"pending"
Custom resources are available in every Kubernetes cluster since version 1.7. They are stored in the same etcd instance as the main Kubernetes API resources and served by the same Kubernetes API server. As shown in Figure 4-1, requests fall back to the apiextensions-apiserver, which serves the resources defined via CRDs, if they are neither of the following:
-
Handled by aggregated API servers (see Chapter 8).
-
Native Kubernetes resources.
Figure 4-1. The API Extensions API server inside the Kubernetes API server
A CustomResourceDefinition ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access