Welcome to this informative session where you'll pick up insights on how to use Kubernetes Custom Resource Definitions (CRDs) for your custom resources. Kubernetes, a popular open-source platform, has transformed the way that complex software systems are configured and managed. The platform's pivotal feature is its ability to declaratively manage services, which are defined as resources. While Kubernetes ships with a broad array of resource types, such as Pods and Services, there may be cases where you need to define your custom resources. That's where Kubernetes Custom Resource Definitions (CRDs) come in handy. In this article, we will delve into what CRDs are, how they work, and provide an example of how to create and manage them.
Before you can effectively use Kubernetes Custom Resource Definitions, you need to have a precise understanding of what they are. Custom Resource Definitions (CRDs) are a potent feature in Kubernetes that allows developers to create their custom resources, extending the Kubernetes API. Simply put, CRDs are a built-in API that has been stabilised into the Kubernetes project, granting you the capability to create object instances as you would for any other Kubernetes resource.
The CRD object defines a new, unique resource kind that functions similarly to the standard resource types provided by Kubernetes. When you create a new CRD, the Kubernetes API server starts to serve the new resource type immediately. You can use kubectl
to interact with this new resource type, just like you would with any built-in resources.
Now that we have a basic understanding of Kubernetes Custom Resource Definitions, the next task is to learn how to create them. Here is an example to guide you.
Let's say you want to create a CRD for a resource type called "Example," with the version "v1". Your CRD specification (spec) might look like this:
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: examples.my.domain
spec:
group: my.domain
versions:
- name: v1
served: true
storage: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
string:
type: string
scope: Namespaced
names:
plural: examples
singular: example
kind: Example
In the metadata
section, the name
field holds a unique string that identifies our CRD. The spec
section defines the details of the resource type. group
is the name of the API group that the resource belongs to. The versions
field specifies the API versions that will be served with this resource type. name
is the version name, served
indicates if the version is served through the API, and storage
shows if it is stored in etcd.
Once you have successfully created your Custom Resource Definition, the next step is managing it. The kubectl
command-line tool is your primary utility for interacting with Kubernetes clusters, including custom resources.
To create an instance of the new "Example" resource type, you might use a command like kubectl apply -f my-example.yaml
. This command tells Kubernetes to create an object from the specifications in the "my-example.yaml" file.
To view all instances of your custom resource, you can use the kubectl get
command, followed by the plural form of your resource type. In this case, you would run kubectl get examples
.
It's inevitable that you need to upgrade your Custom Resource Definitions (CRDs) at some point. Kubernetes provides a straightforward way to handle this.
Firstly, you need to understand that any changes to the spec
section of a CRD, such as adding new fields or changing existing ones, will require a new API version
. For instance, if you have a v1
version of a CRD and you want to make changes to it, you would need to create a v2
version.
To create a new version, you can update your CRD manifest with the new version and apply it using kubectl apply -f updated-crd.yaml
. Kubernetes will automatically handle the storage version and convert existing objects to the new version when they are retrieved.
However, remember to set the storage
flag to true
for the new version and false
for the old version. This ensures that all new objects are stored in the new version format.
Remember, this guide serves as a starting point to your journey in managing Kubernetes Custom Resource Definitions.
kind: CustomResourceDefinition
and apiVersion: apiextensions.k8s.io/v1
to Extend the Kubernetes APIKubernetes Custom Resource Definitions (CRDs) offer us the ability to extend the Kubernetes API. They establish a new, unique resource kind, like the built-in resource types in Kubernetes. But, creating your custom resource kind needs a clear understanding of two YAML fields: kind: CustomResourceDefinition
and apiVersion: apiextensions.k8s.io/v1
.
The kind: CustomResourceDefinition
specifies that the resource type we are creating is a CRD. The apiVersion: apiextensions.k8s.io/v1
field conveys that our CRD is using version v1 of the apiextensions.k8s.io
group. This group is responsible for defining the CRD type.
When creating a CRD, your kind
and apiVersion
fields will remain constant. Your focus should be on the metadata
and spec
portions of your YAML. In the metadata
field, name
is a unique string that identifies your CRD. The spec
field defines your custom resources' details, including group
(the API group that the resource belongs to), versions
(API versions that will be served with this resource type), and names
(the different forms of your resource type).
Your custom resource is also made up of object properties. These properties can be a string, integer, or even another object. Kubernetes uses the OpenAPIV3Schema to define these properties. In our stable example, we used type: object
to indicate that our spec
is an object, and within that object, we have another property string
with type: string
.
Once you've created a CRD, the Kubernetes API server will immediately start to serve the new type object. Your next interaction could be with the kubectl apply
command to create an instance of your new custom resource in your Kubernetes cluster.
Kubernetes Custom Resource Definitions (CRDs) provide you with the power to extend the Kubernetes API to meet your specific needs. They give you a way to define your own custom resources, effectively allowing you to treat Kubernetes as a platform on top of which you can build your own abstractions.
To make the most out of CRDs, you need to understand their structure, how to create them, manage them, and eventually upgrade them. This involves knowing details such as apiVersion, kind, object properties, and more.
Remember, the kubectl apply
command is your primary utility for creating and managing your custom resources in your Kubernetes cluster. Don’t forget to use the kubectl get
command to view all instances of your custom resources. Upgrading CRDs is an inevitable part of their lifecycle, and Kubernetes makes it quite straightforward by allowing you to create a new version, update your CRD manifest, and apply it.
This article has served as your starting point in understanding and managing Kubernetes Custom Resource Definitions. As you continue to explore this versatile tool, you'll discover other ways to leverage it to create more complex and customized solutions. Always remember, the power to extend and customize your Kubernetes API lies within your grasp with CRDs.