Kubernetes Custom Resource Definition — Implement in Java — Part 2

Usability for you custom resource definition, image credit: https://images.app.goo.gl/LwJXA6HaXEcnbQcG9

In part 1, I’ve shared the basics for generating CRD and how to do validation, in this blog, I will walk you through some longer term consideration, in which Java SDK could provide.

We will jump into some fine control of CRD that make your end-user live better — Especially for guru using command line.

Print Column

The READY ,STATUS , RESTARTS , AGE etc are column that kubectl prints when you do a kubectl get <kind> , for example:

But how does the kubectl knows which column or even where is the information of that column came from?

The answer is additionalPrinterColumns property when you define the CRD:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
name: mysqls.database.hinlam.io
group: database.hinlam.io
- hinlamdb
- all
kind: MySQL
plural: mysqls
- ms
singular: mysql
scope: Namespaced
- additionalPrinterColumns:
- description: Size of a cluster
jsonPath: .spec.cluster-size
name: ClusterSize
type: integer
name: v1alpha1
#.....Skip for brevity...

Categories provide a convenience way to group various Kind into same kubectl get command.

For example if you have CRD that has stated categories of hinlamdb and all :

Then kubectl get hinlamdb and kubectl get all will both shows the resources:

So kubectl get can combine with categories to let your Spark Joy!

For Pod there is some extra interface such as pod/log and pod/exec , similar for replicaset there are replicaset/status and replicaset/scale .

Where are these extra interface? In K8S term, it’s called SubResource.

Remember our MySQL kind has a properties called clusterSize ?

kubectl scale command is just a way to update your record of intent the number of replica.

Since we have projected the “replica” => our YAML’s .spec.clusterSize , so the scale command will update the value of .spec.clusterSize

Example of subresource

You can see how defaulting works in the doc.

Simply speaking: You do not need to specific the “ClusterSize” in your own resource YAML unless you have different values.


Although this is a short blog post on usability of CRD, it reveals fundamental building blocks and design of Kubernetes and interaction with kubectl .

All the source code has been published in my github repo.

What’s next?

Software is never done, there are plenty of topics available for further dive deep:

  1. Versioning and conversion — How to deal with version upgrade, forward-backward compatibility and scheme changes of CRD with zero downtime
  2. API Aggregation and CRD for complex use cases

If you have any ideas/questions/anything you want to correct me, please feel free to drop me a feedback.

Definitely still learning a lot on the journey!

Inferencing my Kubernetes knowledge from my posterior study

Hin Lam

Machine Learning; Cloud Native App; Cloud; Connect: https://www.linkedin.com/in/hin-lam/