Consider, a client wants to watch weather reports in a scalable cloud-native way in Kubernetes. We are expected to extend the Kubernetes API so that the client and further future applications natively use weather report resources. We want to create CustomResourceDefinitions and deploy them to the cluster to check their effects, and use newly defined resources to create extended objects.

Let's begin by implementing the following steps:

1. Deploy the custom resource definition with kubectl with the following command:

kubectl apply -f k8s-operator-example/deploy/crd.yaml

Custom resource definitions are Kubernetes resources that enable the dynamic registration of new custom resources. An example custom resource for WeatherReport can be defined as in the k8s-operator-example/deploy/crd.yaml file, which is shown as follows:

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
      name: weatherreports.k8s.packt.com
spec:
      group: k8s.packt.com
      names:
            kind: WeatherReport
            listKind: WeatherReportList
             plural: weatherreports
             singular: weatherreport
scope: Namespaced
version: v1

Like all other Kubernetes resources, CRD has API version, kind, metadata, and specification groups. In addition, the specification of CRD includes the definition for the new custom resource. For WeatherReport, a REST endpoint will be created under k8s.packt.com with the version of v1, and their plural and singular forms will be used within clients.

2. Check the custom resources deployed to the cluster with the following command:
   

 kubectl get crd

You will get the following output:

As shown in the preceding screenshot, the weather report CRD is defined with the plural name and group name.

3. Check the REST endpoints of the API server for new custom resources:

kubectl proxy &
curl -s localhost:8001 |grep packt 

You will get the following output:

New endpoints are created, which shows that the Kubernetes API server is already extended to work with our new custom resource, weatherreports.

4. Check the weather report instances from Kubernetes clients such as kubectl:

kubectl get weatherreports

You will get the following output:

Although the output of No resources found looks like an indication of an error, it shows us that there are no live instances of the weatherreports resource as expected. It shows us that, without any further configuration other than creating a CustomResourceDefinition, the Kubernetes API server is extended with new endpoints and clients are ready to work with the new custom resource.

After defining the custom resource, it is now possible to create, update, and delete resources with the WeatherReport. An example of WeatherReport can be defined, as in the k8s-operator-example/deploy/cr.yaml file:

apiVersion: "k8s.packt.com/v1"
kind: WeatherReport
metadata:
      name: amsterdam-daily
spec:
     city: Amsterdam
     days: 1

The WeatherReport resource has the same structure, with built-in resources and consists of API version, kind, metadata, and specification. In this example, the specif cation indicates that this resource is for the weather report for Amsterdam city and for the last 1 day.

5. Deploy the weather report example with the following command:
   

 kubectl apply -f k8s-operator-example/deploy/cr.yaml

6. Check for the newly created weather reports with the following command:

kubectl get weatherreports

You'll see the following output:

7. Use the following commands for cleaning up:
   

kubectl delete -f k8s-operator-example/deploy/cr.yaml
kubectl delete -f k8s-operator-example/deploy/crd.yaml