Under the 🔬 with Kubernetes

Ever wanted to know a field in your Kubernetes yaml definition, but found it ridiculously difficult to find out what it means or even how to use it 😥?

kubectl is to the rescue!

To get started we can familiarise ourselves with what API resources we have available to use. To do this we can run kubectl api-resources, looking at the output of this command we can start to paint a picture of what resources our cluster is composed of.

Let’s take the deployment resource as our first example. Interestingly we can see that multiple definitions exist for this resource, once for the API Group extensions and one for apps. We will find out why this is the case later on 🤯!

So how do we write a yaml definition for this deployment? It’s possible to get examples for the Kubernetes documentation — personally I always find this too difficult to navigate, instead, it is possible to interrogate the API server’s OpenAPI specification using kubectl.

The command in question is kubectl explain, so let’s give this a whirl 😜!

$ kubectl explain deployment

This will show us all of the keys that are available to use at the top level.

GROUP:      apps
KIND:       Deployment
VERSION:    v1

DESCRIPTION:
    Deployment enables declarative updates for Pods and ReplicaSets.
    
FIELDS:
  apiVersion	<string>
    APIVersion defines the versioned schema of this representation of an object.
    Servers should convert recognized schemas to the latest internal value, and
    may reject unrecognized values. More info:
    https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

  kind	<string>
    Kind is a string value representing the REST resource this object
    represents. Servers may infer this from the endpoint the client submits
    requests to. Cannot be updated. In CamelCase. More info:
    https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

  metadata	<ObjectMeta>
    Standard object metadata. More info:
    https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

  spec	<DeploymentSpec>
    Specification of the desired behavior of the Deployment.

  status	<DeploymentStatus>
    Most recently observed status of the Deployment.

If you really want to dive deep you can add a “recursive” parameter!

kubectl explain deployment --recursive

But I will omit the output so you can check it out yourself! (Hint: the output is longer than this post 😈)