<p>When an application needs to call events API to get all events of its cluster, as a programmer I may define a role like this:</p>
<pre><code>apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [&quot;&quot;] # &quot;&quot; indicates the core API group
  resources: [&quot;events&quot;]
  verbs: [&quot;list&quot;]

</code></pre>
<p>What makes me confusing is the <code>apiGroups</code> part, I can use &quot;events.k8s.io&quot;, or simply &quot;&quot;, or &quot;events.k8s.io&quot; and &quot;&quot; both...</p>
<p>What is this apiGroups thing? I tried to read official documentation but all I found is this:</p>
<pre><code>API groups make it easier to extend the Kubernetes API. The API group is specified in a REST path and in the apiVersion field of a serialized object.

There are several API groups in Kubernetes:

The core (also called legacy) group is found at REST path /api/v1. The core group is not specified as part of the apiVersion field, for example, apiVersion: v1.

The named groups are at REST path /apis/$GROUP_NAME/$VERSION and use apiVersion: $GROUP_NAME/$VERSION (for example, apiVersion: batch/v1). You can find the full list of supported API groups in the Kubernetes API reference.

</code></pre>
<p>This doesn't help me understand it... Why there are named groups and core groups, why I can use &quot;&quot; and  &quot;events.k8s.io&quot; together?</p>
<p>If my resource is <code>events</code>, why do I need to explicitly tell K8s that there is an API group named &quot;events.k8s.io&quot; as if the <code>events</code> in &quot;events.k8s.io&quot; and <code>events</code> in resources are two different things...
This question had been haunting me for days😭</p>

<blockquote>
<p>Why there are named groups and core groups</p>
</blockquote>
<p>The reason is historical. Kubernetes first considered some resources part of a core group, meaning the core of Kubernetes is constituted by these resources (resources in the core group includes Pods, Events).</p>
<p>The purposes of the named API groups (or namespaces) (such as <code>events.k8s.io</code>) is to group resources by thematic. You'll have <code>networking.k8s.io</code> for resources related to networking.<br />
The &quot;core&quot; resources were considered such an integral part of Kubernetes that they did not need a group (I'm simplifying).</p>
<blockquote>
<p>why I can use &quot;&quot; and &quot;events.k8s.io&quot; together?</p>
</blockquote>
<blockquote>
<p>If my resource is events, why do I need to explicitly tell K8s that there is an API group named &quot;events.k8s.io&quot; as if the events in &quot;events.k8s.io&quot; and events in resources are two different things...</p>
</blockquote>
<p>The API is not exactly the same. In the <a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#event-v1-events-k8s-io" rel="nofollow noreferrer">API reference</a> you can see that in the <code>events.k8s.io</code> you can see some field staring with <code>deprecated</code> which are <code>deprecated field(s) assuring backward compatibility with core.v1 Event type</code>. So depending on which endpoint you use, the API semantic is not exactly the same (but Kubernetes has mechanisms to translate from one version to the other). Since some tools might rely on the core <code>v1</code> version  and not yet have migrated to <code>events.k8s.io/v1</code>, both need to exists.</p>
<p>There has been other &quot;group migration&quot; of that sort, notably from the <code>extensions</code> group to other group (<code>Ingress</code> migrated to <code>networking.k8s.io</code>, <code>Deployment</code> to <code>apps</code>)</p>
