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.
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:
- description: Size of a cluster
schema:#.....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
kubectl get hinlamdb and
kubectl get all will both shows the resources:
kubectl get can combine with
categories to let your Spark Joy!
Pod there is some extra interface such as
pod/exec , similar for
replicaset there are
Where are these extra interface? In K8S term, it’s called
MySQL kind has a properties called
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
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
All the source code has been published in my github repo.
Software is never done, there are plenty of topics available for further dive deep:
- Versioning and conversion — How to deal with version upgrade, forward-backward compatibility and scheme changes of CRD with zero downtime
- 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