It is just a way of grouping k8s objects. As objects get added to k8s, they are added in a specific group.

core API group is v1, so every time you see apiVersion: v1, such as Pod object, it is core API group. replicaSet, Service ConfigMap, Node, secrets, etc. are v1 too. These are the main object k8s works with, that have been almost from the very beginning, and are solid (In my own words).

Objects can be moved from one group to another depending on their maturity. Deployments, for example, are now in apps/v1 group, but they used to be in extensions/v1beta1. I, personally, have yaml files with the old group, that when I try to create, I get an error from the server. I think there was a period, when both apps/v1 and extentions/v1beta1 were valid. Not sure about this though.

K8s is an extensible platform, so you can also create your own objects through CustomResourceDefinition, and put them in a custom groups. This is the case of Ingress Controllers, Meshes, etc. Istio, for example creates bunch of objects, such as Gateway, VirtualService, DestinationRule, etc. Once you create this CDRs, you can get them with a normal kubectl get gateway, for example.

batch/v1 is for Jobs. I think there are no more objects in batch/v1. CronJobs are batch/v1beta1.

HorizontalPodAutoscaler is in autoscaling/v1.

Now, you don't really need to know these objects and their groups by heart. As the other answer says, you can always do kubectl explain OBJECT to know to which groups belongs an object. So a normal workflow for creating RBAC rules would be:

1. What object do I want to manipulate the access control? -> Say jobs
2. kubectl explain jobs -> And from here I will get that jobs are batch/v1
3. I will create an RBAC rule for batch.

The verbs are self explanatory.

Note that the group is only the first part; batch, extensions, "" (as v1 has nothing), etc.

There is more information about RBAC (like nonResourceURLs, for the paths that exposes api-server), but I think this should be enough to make a picture of how apiGroups work. Hope it helps.

kubectl explain clusterrole.rules will provide the detail explanation.

FIELDS:
   apiGroups    <[]string> -required-
     APIGroups is the name of the APIGroup that contains the resources. If this
     field is empty, then both kubernetes and origin API groups are assumed.
     That means that if an action is requested against one of the enumerated
     resources in either the kubernetes or the origin API group, the request
     will be allowed

Extensions is deprecated apiGroup, where unorganized resources used to live , currently, resources are moving to specific group. for instance DaemonSet, Deployment, StatefulSet, and ReplicaSet will migrate to apps group.api-deprecations-in-1-16/

here is the naming convention

The named groups are at REST path /apis/$GROUP_NAME/$VERSION, and use apiVersion: $GROUP_NAME/$VERSION (e.g. apiVersion: batch/v1).

The core group, often referred to as the legacy group, is at the REST path /api/v1 and uses apiVersion: v1.

Full list of supported API groups can be seen in Kubernetes API reference.

Batch is another group in k8s which consist cronjob and job resources.

Verb these are actions such as list, get, etc Verb-on-resources

you can list all of the resources and their group with the following command kubectl api-resources