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.


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
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 
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)
mutatingwebhookconfigurations (
validatingwebhookconfigurations (
customresourcedefinitions (
apiservices (

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



Red Hat — Software engineer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store