API Groups

An API group is a collection of resources that are logically related to each other. For example, Deployments, ReplicaSets, and DaemonSets all belong to the apps API group: apps/v1.

Note

You will learn about Deployments, ReplicaSets, and DaemonSets in detail in Chapter 7, Kubernetes Controllers. In fact, this chapter will talk about many API resources that you will encounter in later chapters.

The --api-group flag can be used to scope the output to a specific API group, as we will see in the following sections. Let's take a closer look at the various API groups in the following sections.

Core Group

This is also called the legacy group. It contains objects such as pods, services, nodes, and namespaces. The URL path for these is /api/v1, and nothing other than the version is specified in the apiVersion field. For example, consider the following screenshot where we are getting information about a pod:

Figure 4.25: API group of a pod

As you can see here, the apiVersion: v1 field indicates that this resource belongs to the core group.

Resources showing a blank entry in the kubectl api-resources command output are part of the core group. You can also specify an empty argument flag (--api-group='') to only display the core group resources, as follows:

kubectl api-resources --api-group=''

You should see an output as follows:

Figure 4.26: Listing out the resources in the core API group

Named Group

This group includes objects for whom the request URL is in the /apis/$NAME/$VERSION format. Unlike the core group, named groups contain the group name in the URL. For example, let's consider the following screenshot where we have information about a Deployment:

Figure 4.27: The API group of a Deployment

As you can see, the highlighted field showing apiVersion: apps/v1 indicates that this resource belongs to the apps API group.

You can also specify the --api-group='<NamedGroup Name>' flag to display the resources in that specified named group. For example, let's list out the resources under the apps API group by using the following command:

kubectl api-resources --api-group='apps'

This should give the following response:

Figure 4.28: Listing out the resources in the apps API group

All of these resources in the preceding screenshot are clubbed together because they are part of the apps named group, which we specified in our query command.

As another example, let's look at the rbac.authorization.k8s.io API group, which has resources to determine authorization policies. We can look at the resources in that group by using the following command:

kubectl api-resources --api-group='rbac.authorization.k8s.io'

You should see the following response:

Figure 4.29: Listing out the resources in the rbac.authorization.k8s.io API group

System-Wide

This group consists of system-wide API endpoints, such as /version, /healthz, /logs, and /metrics. For example, let's consider the output of the following command:

kubectl version --short --v=6

This should give an output similar to this:

Figure 4.30: Request URL for the kubectl version command

As you can see in this screenshot, when you run kubectl --version, this goes to the /version special entity, as seen in the GET request URL.