api groups

You can view the named API groups in minikube using several kubectl commands:

List All API Groups

kubectl api-resources

This shows all available resources organized by API group, including the group name, version, and resource types.

View API Groups Only

kubectl api-versions

This displays just the API groups and their versions in a clean list format.

Get Detailed API Group Information

kubectl get apiservices

This shows the API services registered in the cluster, including custom API servers.

Explore Specific API Groups

To see what resources are available in a specific API group:

# For apps API group
kubectl api-resources --api-group=apps
 
# For networking API group  
kubectl api-resources --api-group=networking.k8s.io
 
# For core/legacy API group (empty string)
kubectl api-resources --api-group=""

View API Group Details via Raw API

# List all API groups
kubectl get --raw /api
 
# List specific API group versions
kubectl get --raw /apis/apps
 
# Get detailed info about a specific version
kubectl get --raw /apis/apps/v1

Find namespaced resources

 k api-resources --namespaced=true

 k api-resources --namespaced=false

In Kubernetes, there are two main types of API groups:

1. Named API Groups

These have a specific name and are versioned. Examples:

• apps/v1 (Deployments, DaemonSets, ReplicaSets)
• networking.k8s.io/v1 (NetworkPolicies, Ingress)
• rbac.authorization.k8s.io/v1 (Role, RoleBinding, ClusterRole)
• storage.k8s.io/v1 (StorageClass, VolumeAttachment)
• batch/v1 (Job, CronJob)

2. Core API Group (Legacy Group)

This is the unnamed or core API group that contains the original Kubernetes resources. It’s accessed directly without a group name:

• API path: /api/v1 (not /apis/...)
• Resources include:
  • v1 (Pods, Services, ConfigMaps, Secrets, PersistentVolumes, Nodes, Namespaces, etc.)

Key Differences

Aspect	Core API Group	Named API Groups
API Path	/api/v1	/apis/<group>/<version>
Group Name	None (empty string)	Specific name
Examples	Pod, Service, ConfigMap	Deployment, Ingress, Job
When Created	Original Kubernetes	Added later for organization

View Each Type

# Core API group resources (the "other" type)
kubectl api-resources --api-group=""
 
# Named API groups (exclude core)
kubectl api-resources --api-group="" --invert-match
 
# Or see the difference in API paths:
kubectl get --raw /api/v1        # Core group
kubectl get --raw /apis          # Named groups

The core API group exists for backward compatibility and contains the fundamental Kubernetes objects that were part of the original API design.

---

Instructor: Before we head into authorization it is necessary to understand about API groups in Kubernetes.

But first, what is the Kubernetes API?

We learned about the Kube API server.

Whatever operations we have done so far with the cluster,

we’ve been interacting with the API server one way or the other, either through the Kube control utility or directly via REST.

Say we want to check the version

we can access the API server at the master notes address followed by the port, which is 6-4-4-3, by default, and the API version. It returns the version.

Similarly, to get a list of pods you would access the URL api/v1/pods.

API Categories

Our focus in this lecture is about these API pods the version, and the API.

The Kubernetes API is grouped into multiple

such groups based on their purpose,

such as one for APIs, one for health, one for metrics and logs, et cetera.

The version API is for viewing the version of the cluster, as we just saw. The Metrics and Health API are used to monitor the health of the cluster. The logs are used for integrating with third-party logging applications.

In this video, we will focus on the APIs responsible for the cluster functionality. These APIs are categorized into two; the core group and the named group.

The core group is where all core functionality exists, such as name, spaces, pods, replication controllers,

events and points, nodes, bindings, persistent volumes,

persistent volume claims, conflict maps,

secrets, services, et cetera.

The named group APIs are more organized and going forward, all the newer features

are going to be made available through these named groups.

It has groups under it for apps,

extensions, networking, storage,

authentication, authorization, et cetera.

Shown here are just a few. Within apps, you have deployments,

replica sets, stateful sets.

Within networking, you have network policies.

Certificates have these certificate signing requests

that we talked about earlier in the section.

So the ones at the top are API groups, and the ones at the bottom are resources in those groups.

Each resource in this has a set

of actions associated with them;

Things that you can do with these resources,

such as list the deployments,

get information about one of these deployments,

create a deployment, delete a deployment,

update a deployment, watch a deployment, et cetera. These are known as verbs.

Check Api groups

The Kubernetes API reference page can tell you what the API group is for each object; select an object, and the first section in the documentation page shows it’s group details, v1 core is just v1.

You can also view these on your Kubernetes cluster. Access your Kube API server at port 6-4-4-3 without any path

and it will list you the available API groups.

And then, within the named API groups

it returns all the supported resource groups.

Kubectl proxy

A quick note on accessing the cluster API like that.

If you were to access the API directly through cURL as shown here, then you will not be allowed access except for certain APIs like version, as you have not specified any authentication mechanisms.

So you have to authenticate to the API using your certificate files by passing them in the command line like this.

An alternate option is to start a Kube control proxy client.

The Kube control proxy command launches a proxy service locally on port 8-0-0-1

and uses credentials and certificates

from your Kube config file to access the cluster.

That way, you don’t have to specify

those in the cURL command.

Now you can access the Kube control proxy service at port 8-0-0-1 and the proxy will use the credentials

from Kube config file to forward

your request to the Kube API server.

This will list all available APIs at root.

So here are two terms that kind of sound the same; The Kube proxy and Kube control proxy.

Well, they’re not the same.

We discussed about Kube proxy earlier this course.

It is used to enable connectivity

between pods and services across

different nodes in the cluster.

We discuss about Kube proxy in much more detail

later in this course.

Whereas Kube control proxy is an ACTP proxy service

created by Kube control utility

to access the Kube API server.

So what to take away from this?

summary

All resources in Kubernetes are grouped

into different API groups.

At the top level,

you have core API group and named API group.

Under the named API group, you have one for each section.

Under these API groups, you have the different resources

and each resource has a set of associated

actions known as verbs.

In the next section on authorization,

we can see how we use these

to allow or deny access to users.

Well, that’s it for this lecture.

I will see you in the next.