Let me tell you a little secret about Kubernetes. If you ask nicely, it can tell you a lot about the resources you might be trying to create.

Don't get me wrong. Documentation is invaluable. Internet search engines are the gateway to all knowledge. But sometimes you don't even realize that the answer is already at your fingertips. Let me show you how to uncover it.

But first, some context

With Kubernetes, you create resources (Pods, Replica Sets, and Deployments, oh my!) using a Resource Definition. The definition has a specific structure, with certain key/value pairs of information (like, name: myResource, for example), where the values can also be maps or lists and so on... You get the picture.

Resources are the life-blood of Kubernetes. They are so vital that Kubernetes 1.7 introduced Custom Resource Definitions (CRDs). You could now create your own types of resources! Extend Kubernetes. The ecosystem went to town and created an explosion of tooling that you can only navigate with a magnifying glass and a pack of Tylenol.

Let's jump to the part where you picked a tool and installed it into your cluster. Now what?

Step 1: Go wide - CRD reconnaissance

This is one of the most useful commands I know, shown here assuming the tool you installed is something called cert-manager.

$ kubectl api-resources --output name | grep cert-manager

challenges.acme.cert-manager.io
orders.acme.cert-manager.io
certificaterequests.cert-manager.io
certificates.cert-manager.io
clusterissuers.cert-manager.io
issuers.cert-manager.io

As you can see, this little fellow lists all the resources you could create for this tool. Nifty, eh? (Tip: remove --output name for more useful info).

Step 2: Go deep - CRD structure

So you decide to create a ClusterIssuer (second-to-last on the list above). What do you type into your configuration file?

Check the docs. Kidding! Ask Kubernetes first :) Here's how:

$ kubectl explain clusterissuer

I have limited space here, so suffice it to say, the response will return the top-level fields you would use. Tack on additional fields to get deeper into any particular branch:

$ kubectl explain clusterissuer.spec

$ kubectl explain clusterissuer.spec.acme.privateKeySecretRef

Almost perfect

Truth be told, the documentation embedded into the resources is only as good as the creators made it. At that point, it's time to search the docs and the internet. But with kubectl explain in your back pocket, you'll have a much better idea of what you're looking for.