Introduction

There is no single static page that fully answers this question for every cluster. Kubernetes has built-in resource types documented by the project, but your actual cluster can also expose custom resources through CRDs. The practical answer is to use two sources together: the official API reference for built-in objects and your cluster's own discovery commands for what is actually installed.

Start With the Official API Reference

For built-in Kubernetes resources, the authoritative source is the official API reference. That is where you will find object schemas, fields, versions, and examples for resources such as Pod, Deployment, Service, StatefulSet, and many others.

This matters because the available fields depend on API version. Looking at a blog post or old YAML snippet is often how people end up using deprecated resources.

If you want to inspect a resource directly from the command line, kubectl explain is the fastest path:

kubectl explain deployment
kubectl explain deployment.spec
kubectl explain service.spec.ports

That gives you the schema as understood by your current client and server combination.

Use kubectl api-resources for the Real Cluster View

The official docs tell you what Kubernetes defines. Your cluster tells you what is actually available. The command for that is kubectl api-resources.

kubectl api-resources
kubectl api-resources --namespaced=true
kubectl api-resources --namespaced=false

This command lists the supported API resources on the server, including short names, API groups, whether they are namespaced, and the object kind. It is the quickest way to answer questions like these:

• does this cluster serve Ingress resources
• which group owns HorizontalPodAutoscaler
• is a resource namespaced or cluster-scoped

If the cluster has operators installed, their custom resources will appear here too.

Do Not Forget Custom Resources

This is where the phrase "complete list" gets tricky. A vanilla Kubernetes release has a finite set of built-in objects, but many real clusters add CRDs for tools such as cert-manager, Argo CD, Prometheus operators, and service meshes.

To see those extensions, list the custom resource definitions:

kubectl get crds

If you see a resource in kubectl api-resources but not in the core docs you expected, it is often coming from a CRD.

A concrete example helps. This is a built-in object:

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: demo
5spec:
6  replicas: 1
7  selector:
8    matchLabels:
9      app: demo
10  template:
11    metadata:
12      labels:
13        app: demo
14    spec:
15      containers:
16        - name: web
17          image: nginx:1.27
18          ports:
19            - containerPort: 80

But a cluster running an operator may also have kinds such as Certificate, Application, or Prometheus, and those are not part of the core built-in list.

Objects, Resources, and Versions

People often mix up object kind, resource name, and API version. They are related, but not identical.

• 'kind is the object type, such as Deployment'
• the resource name is what kubectl works with, such as deployments
• 'apiVersion tells Kubernetes which API group and version define that object'

That distinction matters when reading documentation. A list of kinds is not the same thing as a list of served resources, and neither one is complete without version context.

Common Pitfalls

A common mistake is assuming the Kubernetes website alone reflects everything in your cluster. It does not account for installed CRDs.

Another mistake is copying YAML for deprecated APIs. Always confirm the current version with kubectl api-resources or kubectl explain before applying manifests.

Developers also sometimes search for a "master list" without noting the cluster version. Kubernetes resources evolve, so the right answer always depends partly on which version you are running.

Summary

• Use the official Kubernetes API reference for built-in object documentation.
• Use kubectl api-resources to see what your cluster actually serves.
• Use kubectl explain to inspect the schema of a specific resource.
• Use kubectl get crds to discover custom resources added by operators.
• There is no universal complete list without considering cluster version and installed extensions.