The Truth about “kubectl get all”

When I started, a few years ago, working with Kubernetes and its inseperable kubectl, I found the kubectl get all command in some documentation. Because I knew very few resources at that time, it seemed logical to me that this command would return all the resources.

Except, perhaps, configmaps and secrets?

Later, I discovered that the Kubernetes API handles way more resources, and that the kubectl get all command didn’t return all the resources, but only a subset of them. For a long time, I was sure that the command was returning the resources defining workloads. Plus the Services!

But I didn’t have any way to verify this assertion.

Categories

When you define a new resource with a CustomResourceDefinition (CRD) resource, you can define a spec.names.categories field, described by the documentation as “categories is a list of grouped resources this custom resource belongs to (e.g. ‘all’). This is published in API discovery documents, and used by clients to support invocations like kubectl get all.”

Let’s examine the Discovery API. For example using the Discovery client of the client-go library (for Go).

The Discovery client provides a ServerPreferredResources method, returning the supported resources with the version preferred by the server.

This method returns the resources as an array of APIResource values. The APIResource structure is defined as this, and contains the Categories field we have found in the CRD structure.

// from k8s.io/apimachinery/pkg/apis/meta/v1
type APIResource struct {
 Name string
 SingularName string
 Namespaced bool
 Group string
 Version string
 Kind string
 Verbs Verbs
 ShortNames []string
 // categories is a list of the grouped resources this resource belongs to (e.g. 'all')
 Categories []string
 StorageVersionHash string
}

So, using the ServerPreferredResources method, and filtering on which resources belong to the all category, we can find which resources are returned using kubectl get all.

You can look at the Go program I have written, kubectl-categories, which does exactly that. The program calls the ServerPreferredResources from the Discovery client of the client-go library, and then regroups resources by categories.

$ ./kubectl-categories 
all:
  pods (v1)
  replicationcontrollers (v1)
  services (v1)
  daemonsets (apps/v1)
  deployments (apps/v1)
  replicasets (apps/v1)
  statefulsets (apps/v1)
  horizontalpodautoscalers (autoscaling/v1)
  cronjobs (batch/v1)
  jobs (batch/v1)
api-extensions:
  mutatingwebhookconfigurations (admissionregistration.k8s.io/v1)
  validatingwebhookconfigurations (admissionregistration.k8s.io/v1)
  customresourcedefinitions (apiextensions.k8s.io/v1)
  apiservices (apiregistration.k8s.io/v1)

The Bonus Track

Not only do we get the list of resources returned by kubectl get all, but we also discover there exists another native category, api-extensions!

The command kubectl get api-extensions will return the list of “extensions” installed in the Kubernetes API: CRDs, diverse webhooks and APIServices.

More about the Kubernetes API

You can learn more about the Kubernetes API and its differents clients in my book Kubernetes Programming with Go: Programming Kubernetes Clients and Operators Using Go and the Kubernetes API