Watch the API Server Actually Reject

This lab runs on a real API server

A CRD is something that "lends capabilities the API server already has to my type." Those capabilities are schema validation · defaults · RBAC · auditing · watch.

But a fake cluster does not have those capabilities. It accepted whatever you put in, so you could not see bad values being rejected, nor defaults being filled in. You understand the contract only by being rejected.

It takes about 2 minutes to start up the first time.

Goal

You design a platform API to hand to developers, and check that it really acts as a fence.

Steps

1. Create the CRD and save the evidence that the API server accepts it in /root/cnpa/crd.txt.
2. Save the evidence that the schema rejects bad values in /root/cnpa/validate.txt.
3. Save the evidence that defaults are filled in in /root/cnpa/defaults.txt.
4. Add output columns so that kubectl get looks useful, and save the result in /root/cnpa/columns.txt.
5. Decide what developers can do with RBAC and save it in /root/cnpa/rbac.txt.
6. Build a resource fence with a quota and save it in /root/cnpa/quota.txt.
7. Calculate the DORA metrics from the deployment ledger and save them in /root/cnpa/dora.txt.
8. In /root/cnpa/report.md, write the three lines crd_kind=, rejected=yes, and deploy_freq= along with an explanation.

Notes

• kubectl explain reads the CRD's schema to you. That is why you do not have to write separate documentation.
• Keep the rejection message as it is. It is the evidence of the contract.
• Common mistake: adding x-kubernetes-preserve-unknown-fields: true. It switches off both pruning and validation entirely.
• Common mistake: using additionalProperties: false. You cannot use it together with properties, and there is no need to.
• Common mistake: filling in defaults in a controller. If the API server fills them in, they show up right away in kubectl get -o yaml.

Register my type with the API

Create the CRD and save the evidence that the API server accepts it in /root/cnpa/crd.txt.

You need three things: group, names, and versions. Take a look at served and storage too.

You know the contract only by being rejected

Save the evidence that the schema rejects bad values in /root/cnpa/validate.txt.

Try leaving out a required field, try a wrong type, and try putting in a field that does not exist.

The API server fills in the missing values

Save the evidence that defaults are filled in in /root/cnpa/defaults.txt.

If you put default: in the schema, it is filled in at storage time. Check with kubectl get -o yaml.

kubectl get has to look useful to be used

Add output columns so that kubectl get looks useful, and save the result in /root/cnpa/columns.txt.

Put additionalPrinterColumns under versions.

Decide what developers can do

Decide what developers can do with RBAC and save it in /root/cnpa/rbac.txt.

A CRD gets RBAC exactly like any other resource. Check with kubectl auth can-i --as.

A fence around resources

Build a resource fence with a quota and save it in /root/cnpa/quota.txt.

ResourceQuota limits the total across the whole namespace, and LimitRange sets the defaults and upper bounds for individual Pods.

Metrics diverge in the calculation

Calculate the DORA metrics from the deployment ledger and save them in /root/cnpa/dora.txt.

Calculate the four metrics yourself from the deployment ledger. It is not the definition but what you count that changes the answer.

What did you learn

In /root/cnpa/report.md, write the three lines crd_kind=, rejected=yes, and deploy_freq= along with an explanation.

Write the three lines crd_kind=, rejected=yes, and deploy_freq= along with an explanation.